102
points
packet_mover
Joined 38 karma
- Thanks both - appreciate the clarification and the Spain datapoint.
Those numbers look pretty reasonable. I’ll keep Photon in mind and, as I get time to benchmark different approaches on a few representative regions/hardware, I’ll use the results to decide what the best way forward is - and I’ll publish the numbers when I do.
- Thanks, appreciate the context.
Bounding box input is a really interesting idea. For my product, the best use would probably be to automate the request/fulfillment flow if this ever picks up. Letting someone draw/paste a bbox makes the request unambiguous and could be automated end-to-end.
Btw, the pack build process isn’t that compute-heavy. It’s not instant, but as a rough data point: on my laptop, a small country like Austria/Slovakia is on the order of ~1 hour to build the three artifacts (tiles + routing tiles + SQLite geocoder).
- Yeah, I also ran into that when ranking geocoding results - you want to show more "important"/notable places first. In your case, one pragmatic approach could be to keep only features with wikidata or wikipedia tags (and maybe a small whitelist like natural=peak, tourism=viewpoint/attraction).
This is also why I lean on Nominatim-derived data for Corviont - it already condenses a lot of this into a single importance/ranking model. I have not tried a whole-world build though, so I am not sure how well that behaves at planet scale.
- Thank you, that's very helpful.
- 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.
- Yes - I do plan to sell Corviont, and it is worth explaining the licensing bit.
It is built on open-source components and OSM-derived data, so the obligations are mostly (a) keeping third-party software licensing/attribution intact, and (b) OSM/ODbL compliance - clear attribution, and if you distribute derived OSM databases, meeting the ODbL share-alike requirements for those database artifacts.
I am handling this via attribution in the UI/docs and a licensing reference bundled with the dataset that points to a public licensing/attribution repo containing the third-party license texts and details: http://github.com/corviont/licensing
What I am selling is the packaging + ops side: ready-to-run region packs and (eventually) a signed updater for fleets.
- I do not have published benchmarks yet (I want to collect a few real region packs first and then write this up properly).
One goal of Corviont is to avoid the on-device pain you hit with OSRM/Nominatim: the region pack is built once elsewhere, and the edge box mostly just serves prebuilt artifacts (PMTiles tiles, Valhalla routing tiles, and a SQLite geocoder index based on Nominatim).
In practice, requirements scale with region size and traffic. For larger regions the main constraint is usually SSD storage plus enough RAM headroom for routing/cache. I also picked Valhalla partly because it generally has a smaller RAM footprint than OSRM at serving time (OSRM is extremely fast but tends to be more memory-hungry).
- Yeah, house-number lookup is not there yet. The demo geocoder does place/street-level search + reverse, but house numbers need a richer address index - it's on the roadmap.
Re: a bbox "builder" repo - it's an interesting idea. I could see it going two ways: (a) you want to run a bbox builder yourself, or (b) you want a simple way to specify a bbox so the dataset pack can be produced for you.
I started with the "ship a known-good pack" approach because the build pipeline is the messy part, and I want deployed boxes to stay simple/reproducible.
For your use case, which did you mean - run the build locally, or "draw/paste a bbox and get back a ready-to-run pack"? And would bbox be OK, or do you prefer admin boundaries (country/state/city)?
- Thanks for chiming in - super helpful context.
I am trying to learn from real deployments as I design Corviont's updater for edge boxes (bandwidth caps, maintenance windows, unreliable WAN, atomic swap + rollback).
When you say transit "zones" are small enough to deploy incrementally - what is the actual artifact per zone (roughly what format), and what sizes do you typically see?
And when a transit zone dataset changes, how do you roll that out safely - do you restart/reload the backend that serves that zone, or do you bring up a new backend/version and then flip travelmux to point at it?
- 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.
- Thank you! And yes, Corviont is intentionally a stack of separable services behind one gateway - so "geocoder-only" is exactly the kind of config I want to support (skip PMTiles + Valhalla and ship only the SQLite index + reverse API).
Re: Weathergraph - thanks for the details. Since you already run whole-world reverse geocoding on a single server, that's a bit different from Corviont's current regional/fleet packaging (where you ship only the area you need to each edge/on-prem deployment). A "world geocoder-only" pack could still make sense - but it's a different distribution/update story than my default.
For your use case, do you want reverse results at the city/region/country level - or do you also need street/house number detail? That choice mostly determines how heavy a world geocoder-only pack needs to be.
- Good question. Corviont is region-focused (you package one region), not "host the whole planet". Hundreds of GB is usually the full planet at high zoom / lots of layers.
Also it’s not one giant tile DB - there are 3 datasets:
For Monaco all three are tiny - you can see the exact files here: https://github.com/corviont/monaco-demo/tree/main/data- map tiles (PMTiles) - routing tiles (Valhalla tiles) - geocoder index (SQLite)For small countries like Austria/Slovakia, each is typically hundreds of MB.
- Nice - thanks for the pointer. Headway is definitely a related "self-hosted maps stack" project.
One place Corviont is trying to differentiate is the update story for edge/fleet deployments: the goal is a signed, resumable regional dataset updater (verify manifest -> atomic swap -> reload/rollback) so boxes in the field can stay fresh without manual rebuilds or "re-download the world" updates. Headway (at least from a quick skim) looks more like "bring your own data / regenerate when needed," which is totally fine for servers, but fleets usually need something more automated.
If you've seen Headway (or similar) handle incremental/regional updates well, I'd love to learn from it - updater design is the big missing piece I'm validating demand for.
- Good point - house-number search isn't there yet in Corviont.
Right now the offline geocoder in the demo does place/street-level search + reverse, but street + house number ("Main St 12") isn't supported yet. It's explicitly on the near-term roadmap: richer geocoding output with house numbers and (optionally) street/area geometry instead of just centerpoints.
- That’s a really interesting framing - you’re basically describing hierarchical routing / "zoom-level" graphs: do the long leg on a coarse network (highways), then refine locally as you get closer to origin/destination.
FWIW, Valhalla already does a version of this: it partitions the routing graph into hierarchical tiles and runs with multiple hierarchy levels (highway / arterial / local) specifically to keep search + in-memory working set smaller on long routes: https://valhalla.github.io/valhalla/tiles/
The "quadtree tile unlock" mental model is a nice way to think about it though - if you have a favorite paper / implementation that leans harder into the tiling aspect, I’d love a pointer. I’m currently focused on packaging + offline data consistency, but routing performance on constrained edge boxes is definitely a core constraint I care about.
- More context on the angle: this is server-style offline maps for fleets/edge. You drop it on a box and multiple clients on the LAN share the same tiles + routing + geocoding over HTTP (no proprietary SDK in every app).
A key goal is consistency: tiles, routing data, and the geocoder index are built from the same extract/version for a region.
If you’ve seen Atlas/SDK approaches: this is intentionally smaller and “appliance-like” (PMTiles + Valhalla + SQLite geocoder) to be friendlier to edge hardware and simple ops.
- 2 points
If you have 1-2 concrete suggestions on what makes it feel that way (copy/layout/typography), I am happy to improve it.