[bchapuis]

Yes, there is clearly a need for a go-to solution. MapLibre and Cesium are doing a great job with their open-source renderers. Baremaps complements this by providing open infrastructure components, such as a data pipeline and a vector tile server. For instance, another missing piece in this space is an open-source IP to location solution. Our current prototype is rudimentary but demonstrates that this gap can be filled.

[pininja]

I’m a maintainer for vis.gl (deck.gl and react-map-gl), and am existed you’re focusing on infrastructure components. Open data and nav/location solver services are key for many applications, and today most options for what I’d consider “the basics” are proprietary/commercial. I’m all for paying for good work.. but I’d like to see the funds go towards bleeding edge, and see long-established solutions become open and easy to use.

[bchapuis]

Clearly, I did some location-based pub/sub research in the past and the lack of open source infrastructure components was an important motivation for Baremaps. Today, the open source ecosystem in this area is moving fast and I think we are pretty close from a having high quality options for all the main infrastructure components (map, geocoder, reverse geocoder, ip to location, routing, TSP, etc.).

[karussell]

I see you also use some minor code from planetiler :)

How is baremaps different to it? Does baremaps also work without PostgreSQL? Or is PostgreSQL required and then it does support real time updates or similar? How long does a planet-wide import take (for vector tiles) and how much RAM does it require?

[bchapuis]

Yes, planetiler rocks and the memory mapped collections enabled us to remove our dependency to rocksdb ;)

From my perspective, planetiler started as an effort to generate vector tiles from the OpenMapTile schema as fast as possible (pbf -> mvt). By contrast, Baremaps started as an effort to create a new schema and style from the ground up. In this regard, having a database (pbf -> db <- mvt) enables to live reload changes made in the configuration files. The database has a cost, but also comes with additional advantages (updates, dynamic data, on demand generation of tiles at zoom levels 16+, etc.).

That being said, I think the two projects overlap and I hope we will find opportunities to collaborate in the future. For instance, whereas PostgreSQL is still required in Baremaps, I recently ported a lot of the ST_ function of Postgis to Apache Calcite with the intent to execute SQL on fast memory mapped collection.

https://github.com/apache/calcite/blob/main/core/src/main/ja...

A planet wide import in Postgis currently takes about 4 hours with the COPY API (easy to parallelize) followed by about 12 hours of simplification in Postgis (not easy to parallelize). I will try to publish a detailed benchmark in the future.

[karussell]

This sounds really interesting. (unfortunately I did not notice earlier that you replied)

Thanks also to the link for calcite. The import times with Postgis really sound impressive. (if you post benchmarks do not forget to include Xmx and physical available memory :) )

I'll take a brief look into all this - maybe something valueable we can learn for GraphHopper.

Can you explain what you mean with "live reload of configuration files"? I'm not that familiar with map tiles, but do you mean the configuration that e.g. house numbers should come for zoom levels 12-16 and no longer from 12-15 or something?