What would be the requirement for self hosted VPS if the whole planet is used? CPU, RAM, SSD?
The index for the whole planet is about 18GB, so with 16GB RAM you can have it almost fully in memory. That should give you an idea. But it also depends on how much of the planet you're actually using. For example, if you're only using several countries, even 4GB or 8GB might be enough for good performance.
Interesting, this is way more lightweight that Nominatim for example.
Is there any benefit of having it in memory vs. on the disk apart from speed obviously?
Also, since this is meant to be used with traccar server, I assume it will also make sense to fetch directly from the database vs. api request. Just a thought.
Here's a pre-processed index for the whole planet if anyone needs it:
https://traccar.nyc3.digitaloceanspaces.com/download/index.tar.gz
It is designed to be more lightweight and much more performant than Nominatim, but limited to reverse geocoding only.
Memory is much faster than disk, but for lower rates disk should also be ok.
There's no database. It uses a raw custom index files to achieve this performance. It is possible to avoid HTTP overhead in theory, but it's already pretty efficient as is.
That's amazing. I think a few overpriced operators are probably sweating now.
I'm self-hosting (t3.medium ec2 instance) traccar-geocoder using Docker Compose with India and Nepal PBF files. The server starts successfully and responds to API calls, but Curl (curl http://localhost:3000/reverse?lat=25.748&lon=85.507&key=myapikey) to the reverse endpoint returns empty address - {"address":{}}. Any idea why it could be happening.
docker-compose.yaml i used:
services:
geocoder:
image: traccar/traccar-geocoder
environment:
- PBF_URLS=https://download.geofabrik.de/asia/india-latest.osm.pbf https://download.geofabrik.de/asia/nepal-latest.osm.pbf
ports:
- "3000:3000"
volumes:
- geocoder-data:/data
volumes:
geocoder-data:
docker compose logs:
geocoder-1 | Building index...
geocoder-1 | Processing /data/pbf/india-latest.osm.pbf...
geocoder-1 | Pass 1: scanning relations...
geocoder-1 | Pass 2: processing nodes, ways, and areas...
geocoder-1 | Processed 10K admin boundaries...
geocoder-1 | Processed 20K admin boundaries...
geocoder-1 | Processed 30K admin boundaries...
geocoder-1 | Processed 40K admin boundaries...
geocoder-1 | Processed 50K admin boundaries...
geocoder-1 | Processed 60K admin boundaries...
geocoder-1 | Processing /data/pbf/nepal-latest.osm.pbf...
geocoder-1 | Pass 1: scanning relations...
geocoder-1 | Pass 2: processing nodes, ways, and areas...
geocoder-1 | Processed 70K admin boundaries...
geocoder-1 | Done reading:
geocoder-1 | 318545 street ways
geocoder-1 | 71591 address points (44317 from buildings)
geocoder-1 | 35 interpolation ways
geocoder-1 | 72980 admin/postcode boundaries (75881 polygon rings)
geocoder-1 | Resolving interpolation endpoints...
geocoder-1 | Resolved 5/35 interpolation ways
geocoder-1 | Deduplicating...
geocoder-1 | Writing index files to /data/index...
geocoder-1 | geo index: 3731946 cells (318545 ways, 71591 addrs, 35 interps)
geocoder-1 | admin index: 38021 cells, 75881 polygons
geocoder-1 | strings.bin: 3590002 bytes
geocoder-1 | Done.
geocoder-1 | Index built.
geocoder-1 | Starting server...
geocoder-1 | Loading index from /data/index...
geocoder-1 | Starting HTTP server on 0.0.0.0:3000...
It's working for me on the whole planet, so maybe another case of admin boundaries issue.
what if you do?
curl http://localhost:3000/reverse?format=json&lat=25.748&lon=85.507&key=myapikey
> curl "https://geocoder.traccar.org/reverse?lat=25.748&lon=85.507&key=MY_KEY"
{"display_name":"Bihar, India","address":{"state":"Bihar","county":"Jandaha","country":"India","country_code":"IN"}}
curl http://localhost:3000/reverse?format=json&lat=25.748&lon=85.507&key=myapikey also has same output i.e. empty.
Is there any configuration on my end to fix this, or is using the continent/planet extract the only option for now?
We don't know why it doesn't show anything. You would have to debug it if you want to know. But I don't see why not just use the whole planet. It will only load areas you need. And the files are only 18GB.
Got it, I'll switch to the whole planet extract. Thanks!
It works for me on the whole planet server:
{ "display_name": "Dam 2, Amsterdam, Nederland", "address": { "house_number": "2", "road": "Dam", "city": "Amsterdam", "state": "Noord-Holland", "country": "Nederland", "country_code": "NL" } }There must be some issue with the way parts are cut. Maybe you can try using the whole Europe extract?