Photon is solid - but it comes with a very different operational profile than what I am aiming for.
Photon is built on Elasticsearch (Java) - so it tends to mean a heavier index + higher RAM/CPU expectations and more moving parts. That's fine on a beefy server, but it is a rough fit for the "drop-in appliance on small edge/on-prem boxes (amd64/arm64) + simple ops" goal.
Corviont's geocoder is intentionally "boring": a single SQLite file + an HTTP service, built from Nominatim-derived data. Fast startup, low RAM, easy to ship per-region, and it stays consistent with the rest of the stack.
That said - if there is demand for a "server-grade geocoder option" for people already comfortable running Elastic, I am not opposed to offering it as an alternative profile. The default is just optimized for constrained edge hardware and minimal moving parts.
No. When I looked at Photon and saw that it involves running Java plus an OpenSearch/Elasticsearch backend on the device, I assumed it would be heavier in terms of memory and moving parts than my setup (single SQLite file + small HTTP API).
Have you (or anyone here) actually run Photon on edge-class hardware? If you have real-world numbers, I'd be interested in seeing them. When I add house-number search, Photon might be an easier route than enhancing my current approach.
Photon is solid - but it comes with a very different operational profile than what I am aiming for.
Photon is built on Elasticsearch (Java) - so it tends to mean a heavier index + higher RAM/CPU expectations and more moving parts. That's fine on a beefy server, but it is a rough fit for the "drop-in appliance on small edge/on-prem boxes (amd64/arm64) + simple ops" goal.
Corviont's geocoder is intentionally "boring": a single SQLite file + an HTTP service, built from Nominatim-derived data. Fast startup, low RAM, easy to ship per-region, and it stays consistent with the rest of the stack.
That said - if there is demand for a "server-grade geocoder option" for people already comfortable running Elastic, I am not opposed to offering it as an alternative profile. The default is just optimized for constrained edge hardware and minimal moving parts.
Have you measured actual memory and disk requirements of a photon OpenSearch index vs your sqlite database?
No. When I looked at Photon and saw that it involves running Java plus an OpenSearch/Elasticsearch backend on the device, I assumed it would be heavier in terms of memory and moving parts than my setup (single SQLite file + small HTTP API).
Have you (or anyone here) actually run Photon on edge-class hardware? If you have real-world numbers, I'd be interested in seeing them. When I add house-number search, Photon might be an easier route than enhancing my current approach.
3 replies →