Really cool project! I tried it a couple of weeks ago with an Anthropic API key and will give it another shot.
Could you share a bit more about how you handle code summarization? Is it mostly about retaining method signatures so the LLM gets a high-level sense of the project? In Java, could this work with dependencies too, like source JARs?
More generally, how’s it been working with Java for this kind of project? Does limited GPU access ever get in the way of summarization or analysis (Jlama)?
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.
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.
We recently attended the OGC/Apache Code Sprint at Camptocamp and improved our experimental support for Collection, Conformance, Tiles and Styles. In the future I would also like to expose the attributes and geometries of the database with the Feature API. We havn't yet tested our implementations with an external client and Pygeoapi would demonstrate interoperability very well.
Unfortunately, I don't gather statistics on the demonstration server. I believe that the in-memory caffeine cache (https://github.com/ben-manes/caffeine) saved me.
Thank you for reporting this problem, I created an issue on GitHub to track it. The root cause is probably located in our tileset or style (not in the renderer). Right now, we use the OpenStreetMap name attribute in our tiles and most of our tests are performed in central europe.
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.).
Have you tried Turf.js? It goes pretty far when it comes to in-browser spatial analysis. Baremaps is more about the server side of web mapping. We currently use MapLibre for rendering the vector tiles we produce in the browser and plan to support 3d tiles in the future.
Thank you for describing this issue, I created an issue on GitHub to track it. The fact that OpenStreetMap Carto is used in the OpenStreetMap documentation greatly accelerated our styling process (e.g. https://wiki.openstreetmap.org/wiki/Map_features). That being said, it is a loose port, and I hope we will soon be able to provide other derivatives, such as a positron style.
Nice, thank you for the pointer. Our workflow uses a DAG and the format is loosly inspired by GitHub actions and AWS data pipeline. This is an area we seek to improve, so no not hesitate to reach out on GitHub or by email.
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.
Hi, author here, I just noticed that Baremaps was submitted to HN. Our demo runs on PostGIS, and I'm surprised it's holding up under the load. I'm happy to answer questions.
Hi, author here, Baremaps aims to create an open and easily extensible vector map, inspired by OpenStreetMap Carto. The goal is to provide a high-quality base map for the planet. Since we use PostGIS as a storage backend, you can extend it with your own layers and data.
I will mention Baremaps [1] and its OpenStreetMap demo [2]. Baremaps can be used to import data in Postgis and serve vector tiles efficiently. Its developer mode, featuring live reload capabilities, makes it easy to customize vector tiles and integrate third-party datasets into the base map.