Apache Baremaps: online maps toolkit | Hacker News Reader

Apache Baremaps: online maps toolkit

baremaps.apache.org

213 pointsl3x43 comments

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.

Here is the fullscreen demonstration for those who are interested. https://demo.baremaps.com/

As a geographer who migrated to mobile robotics and web mapping, I’ve found that there is a lack of “serious” web spatial analysis tools for in-browser work. Think the geotoolbox you get in ArcGIS or QGIS for building analytical processing pipelines for raster and vector datasets, particularly from web sources.

Lately I’ve revisited the idea and found that with wasm, SharedArrayBuffer for parallelism, and more maturing libraries, it may be possible to provide a much richer set of analytical tools.

Is this an idea you’ve explored? This would be my “if I won the lottery, what would I work on?” project.

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.

I should try Turf again. The core problem last time was that it fundamentally does not support “Simple”/ Euclidean coordinate systems. When I want to do analysis on flatland indoor maps, it does all the math wrong.

GEOS will be available in WASM sooner or later (if it isn’t already, and if the licence works for you), rust-geo (under active development, I’m one of a few core contributors who work on it) is available compiled to WASM today (you can see a demo from a core contributor at rgis.app). Those are both vector only. For a more mature product that “only” leverages JS, placemark is the state of the art, and is amazing.

I’m not a raster or EO person so I can’t speak to GDAL’s availability, but I’m dubious that the browser is a good interface for that kind of work, or for a full GIS more generally.

Watch out for software license conflicts moving the code to WASM. Some code can run on a server without triggering distribution clauses. WASM runs on the client and may count as distribution.

Assume Apache Baremaps uses an Apache license, it might be more wasm-friendly than most GIS software…

If you get a chance, it would be neat to see a brief summary article added to your website that talks about how much traffic and how Baremaps + PostGIS handled it. Info like that can be hard to come by when evaluating GIS frameworks and is really helpful!

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.

What is the library being used to display the map?

MapLibre (https://maplibre.org/) is used to render the map.

Thanks!

This is a great addition to the space. Do you plan to fill the gap left by mapbox for the open source community?

Things like map libs for mobile and the web with advanced things like 3d, navigation, elevation and the likes?

I feel like we need a go to solution that unchains away from the commercial solutions to power osm solutions across devices and use cases.

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.

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.

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

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?

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.

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?

Cool. From this I also learned about geoBoundaries https://www.geoboundaries.org/ and Turf.js https://turfjs.org/ .

What is the source of these maps? Toponyms in Crimea are shown in Russian.

We use the OpenStreetMap name attribute: https://wiki.openstreetmap.org/wiki/Key:name

Looks promising, I have published a paper about workflow systems in geospatial data processing (https://www.mdpi.com/2220-9964/11/1/20). I wonder if I can use this project to realize proposed system in my paper.

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.

When would I use Baremaps versus something like GeoServer?

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 hope your planning on going beyond what Carto does. Baremaps currently doesn't render highway=busway either, leading to awkward gaps in the map. It's an accepted tag supported in every renderer except Carto (look at OsmAnd or Organic Maps for instance), because the two or three active maintainers remaining (having lost a number of maintainers in the past two years) don't like the tag. Carto has pretty much stagnated despite its past achievements.

As the default renderer for openstreetmap.org, Carto is currently an embarrassment for OpenStreetMap.

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.

Are coordinates stored in Web Mercator?

Yes, as the tiles are created directly from Postgis, reprojecting the coordinates would take too much time.

Dear lord why would you use GeoServer for anything in 2023

What would you use instead?

Really cool! Any thought to Baremaps as an OGC API data provider for something like Pygeoapi?

https://docs.pygeoapi.io/en/stable/plugins.html

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.

Really cool!

QGIS might be another client to test against. They’ve implemented OGC API read/write support. Plus, QGIS is great for mocking up a wide range of GIS user scenarios.

Just scrolling around Israel, it seems text rendering for RTL is broken.

https://demo.baremaps.com/#12.91/32.06932/34.75969

Should be “תל אביב”, not “ביבא לת”. How do these issues even exists in 2023? Is a team building these renders not aware of RTL languages, or do they just not bother implementing it?

> "How do these issues even exists in 2023?"

Have actually tried writing something that handles languages running in different directions? It might be 2023, but the libraries... aren't great...

From my experience (not on the web), frameworks that take their Unicode support seriously fare quite well by now (nothing is perfect), while frameworks that make silly assumptions that everything is ASCII do not.

Opened an issue on GitHub for this: https://github.com/apache/incubator-baremaps/issues/679

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.

Thanks. Just verified, and OSM is correctly rendering RTL (at least Hebrew).

> How do these issues even exists in 2023?

As long as the core developpers of the new platform live and work on the US west coast, any issue non relevant to the US will be a second class citizen, mostly dealt with after the product is deemed stable.

The same way OpenAI operates in english first and other language systems will be improved "later".

It's not a jab on the devs, I realistically can't see any other approach. Just another angle where there's no free lunch and more investment is needed building systems that aren't US first if we care about non-US needs being met in a timely manner.

The main developer is based in Switzerland.

Point taken. Western Europe is already a pretty big difference in many respects (I guess that also explains Lausanne as the default position)

Reply on news.ycombinator.com