I like how you packed only the necessities - tiles for maps, routing, and geocoding index in in sqlite. I checked the monaco deployment and missed lookup with street number, as someone else also pointed out.

Why not create a "builder" repo, where people could generate their own local datasets by a bounding box?

▲

packet_mover 4 days ago | parent | next [-]

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)?

▲

t0mk 4 days ago | parent [-]

I would prefer to run the build locally/myself, and to specify either a bounding box with lon and lat, or a country. The output would be data files and/or docker images with data. But as sibling comment said, if you plan to sell it, I understand it makes less sense to offer building logic.

I get why you created the monaco pack, it's a nice demo and fast to download and run. I would rather choose a big city where potential users live (london, nyc, the bay,?), but maybe there are technicalities that make that more complex.

Drawing box on a map in browser and generating the tiles, routing and geocoding db sounds quite heavy for backend compute. There was a project wiht a website that could generate a tileset (pmtiles file?) from box drawn on a map, but I can't find it now. There was a limit to the box size and if it was over some threshold, you had to have premium, or contact sales, or sth, I thought it was protomaps, but no tool like that there now.

Anyway really nice idea, I will follow your progress for sure!

	▲	packet_mover 3 days ago \| parent [-]
		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).

▲

mike_d 4 days ago | parent | prev [-]

> Why not create a "builder" repo, where people could generate their own local datasets by a bounding box?

If you read the bottom of the page they plan to sell it. Not sure how that works when all the software/data is open.

	▲	packet_mover 4 days ago \| parent [-]
		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.