2024: The year of the OpenStreetMap vector maps
blog.openstreetmap.org
blog.openstreetmap.org
What worries me for this new effort is that Paul Norman is one of the two remaining Carto sometimes-active maintainers who refuse to merge contributed PRs or even provide alternative minimal support for features like highway=busway, leading to awkward gaps on the baseline map shown on openstreetmap.org.
I would love to be surprised in a positive way about this new effort, but I'm not holding my hopes up. Thankfully OpenStreetMap can be thoroughly useful in apps like OsmAnd and OrganicMaps, and the tile-based Tracestrack Topo layer on openstreetmap.org is getting quite decent:
Honestly of the maintainers imagico is the one I'd say is impossible to reason with.
While I can understand that being a maintainer for a project like Carto can be taxing due to the high amount of feature requests which are often not suitable for the general purpose map, lack usage, or are otherwise unclear in their definition, I find that the way Carto has been maintained for the past few years has been harmful to the OpenStreetMap project in general.
I think Christopher Hormann (imagico), despite his contributions in the past, is actively harming OpenStreetMap with his maintainership and (lack of) actions. Although to be fair the OpenStreetMap Foundation shares some of the blame here by shrugging 'not our problem' when the state of the default layer on openstreetmap.org is, repeatedly, pointed out, and letting this state of affairs persist. The typical response of 'Oh, OpenStreetMap is a do-ocracy, haha, if you want to change this, just create your own layer!' does not befit a project which has achieved so much as OpenStreetMap.
(once again: very little knowledge of OSM, so maybe that's overly naive)
Most people with the knowledge and capacity to do this have spent their energy on other initiatives not hosted directly on openstreetmap.org instead (like OpenStreetMap Americana destined for the US chapter's OSM website), or contributing to OsmAnd or OrganicMaps.
Anyone from Mozilla/Firefox here?
[1] https://community.openstreetmap.org/t/idea-ask-mozilla-for-o...
I have OsmAnd ( https://github.com/osmandapp/OsmAnd ) on my phone, download the basemaps, download my (small) country data (both sourced from open street maps), and with an app + ~1GB of data, I get the maps and full navigation within my country, POIs, etc., and can add other countries when needed.
Is there something similar for a PC? I can download data from open street maps, but then I need postgres, postgis, a tile server and styles and apache running just to generate the tiles. Is there anything portable (short of running osmand in an android virtualbox) for offline navigation on a linux pc? QGIS can display vectors, but I wasn't able to easily style the data... navigation is a no-go there too. anything else?
I would still want to to know if I can selfhost something of similar, low complexity in my home network.
Completely free, too.
As an aside, you can likely run OsmAnd in a container without having to use Virtualbox at all.
A few word of caution:
- the app was a bit buggy (but usable)
- might not be well optimized in terms of amount of http requests sent, so some map providers don't like it [1]
A quick look suggests that it has some support for osm data but you would need to check more closely or use other sources.
https://github.com/rinigus/pure-maps/ (makes use of OSM Scout Server)
Here's a vector map I built with it of Half Moon Bay California https://simonw.github.io/hmb-map/
The blog post is very light on details. My intuition is that this is primarily focused on powering the map on osm.org in service of people who edit OSM getting to see faster updates. This would be in keeping with their current raster tiles, which are not meant for use in "real" applications.
There are enough technical challenges in rolling out vector tiles with minutely updates for editors on OSM -- in my opinion, they should solve it for OSM first before thinking about committing to a specific schema for public use by other apps.
Still, anything that incentivizes innovation on vector tiles is pretty exciting. One option that could be interesting: provide "fat" builds of tiles that have every feature, and create tooling to do something akin to treeshaking so people can simplify the resulting tiles to only contain the features they need for their use case.
The nice people at https://download.geofabrik.de provide daily country-level OpenStreetMap extracts in the Shortbread schema, which is the same schema that we are going to use for our live tiles.
But also, it turns out that there's a question of how that data is generated. There's a certain schema of what sorts of things show up in the browser, perhaps with styles giving options for how to display them. But which raw OSM data you decide to include, and which visual element it corresponds to, is up to the producer of that data. So thinking of Organic Maps and OsmAnd, I bet they choose slighly different things and probably change it over time.
Protomaps, mentioned elsewhere in this thread, is awesome for self hosting vector maps. The way it works is that you upload a single large pbf (protobuf) file with all map content and then use lambda functions to extract vector tiles from there. Put a CDN in front of it and you have cheap map hosting. Amazing stuff. I met Brandon Liu, the person that built this, some time ago at a meetup. Well worth checking out his stuff.
There's also https://demo.f4map.com/#lat=47.5933049&lon=12.1748491&zoom=1..., which is a 3D rendering engine filled with openstreetmap data. Pretty nice stuff and be sure to fiddle with the options to change the time of day, turn on the moving ships, etc.
Although it's lagging behind. Four is almost finished but you only see cranes here: https://demo.f4map.com/#lat=50.1121791&lon=8.6738090&zoom=18...
You can do so if you know more, go to https://www.openstreetmap.org/way/592118388 and click the 'Edit' button. The currently available 'best' aerial imagery shows the foundations being built.
However, running pm-tiles at build/deploy time for the whole world is a bit expensive and time consuming. The point of using lambda functions is to run it on demand for just the tiles that are needed and then cache the results via a CDN.
I haven't spent a lot of time looking into it. But the last time I looked at commonly-used vector tile formats, the one I found was clunky to generate/parse.
(And/or, maybe I just missed the right one. Please correct me if there is something out there that is clean and simple -- and has common library support.)
If you want to distribute sets of tiles to people, PMTiles is the best container format as you can just throw the file on hosting that supports HTTP Range requests (e.g. S3) and add the appropriate plugins to your client library. If you have to support clients which can't do the range requests from pmtiles, you can throw a thin layer in front of it to turn HTTP z/x/y requests into the pmtiles range requests.
There are no good file formats for distributing minutely updates of tiles but there's no need for this. If you are keeping your tiles up to date up to the minute you have a reasonable internet connection and you can just download individual tiles instead.
I just browsed the spec again (https://github.com/mapbox/vector-tile-spec/tree/master/2.1) -- I didn't have as bad of a reaction as I did the first time I looked at it.
I guess the idea of using (Google) protobufs for the "packaging" and then a super tight, custom, byte-encoded format for drawing commands seems... weird to me. But, honestly, it probably makes sense.
IMHO maintaining a large number of files on disk (be it 16m or 1.5b) should be a non-starter (not to mention that zipping them to slightly reduce the count removes one of the benefits of having them in the first place). A database makes sense - as does SOC between generation and distribution if it brings benefit - but immediately writing off SQLite because of write performance[1]? Similarly the arguments against pmtiles feel outdated and ignorant of the developing nature of the protocol (appreciate it's a 2yo post!).
OSM deciding on a format here has potential to significantly shape things to come. Hopefully Paul has progressed his thinking a bit since this was written.
The situation Paul is addressing is one unique to OpenStreetMap itself, which is minute-level updates of a global scale tileset. This is a use case pmtiles is designed explicitly not to address, where using a database is a better fit.
Which is to say, distribution of OSM data feels like a large part of the process. Of course there are various bottlenecks / considerations around edits / writes, but in practice surely reads are the bigger vector. I wonder how many OSM-external use cases rely on "minutely" updates or need the full fidelity of the raw data source. Feels like there is a solid case for providing less frequent (hourly, daily?) official updates via official "single-file" formats that could be widely distributed to the benefit of all, and e.g. allow OSM to loosen up their hot-linking policies and ensure continued investment in the chosen protocols.
But mainly I was questioning how a somewhat proven format like SQLite, with its many benefits (interoperability, distribution, etc.), would be so easily dropped from consideration without even a test having been run. Just my thoughts of course!
The key distinction is "official" - the only "official" data product of OpenStreetMap are its XML and PBF data dumps at planet.openstreetmap.org. The frequently-updated tiles you see on osm.org are "quasi-official", they're created by a separate project called OpenStreetMap Carto. These tiles have a special status within the OSM ecosystem for historical reasons; by virtue of OSM being map data, it should probably show something for human eyeballs on the website.
The design goals of OSM Carto are to show feedback to map editors; the linked vector tiles project is intended as a successor, or at least complement, to OSM Carto. The consumption of the tiles by third-party sites is a side-effect tolerated by OSMF; the general consensus within OSM seems to be that a consumable tile service for third parties is outside the scope of the project.
Definitely not in a position to question the status quo, let alone the OSM community consensus. Other than to say that - even if the focus is currently on internal software / editors alone - it still feels like a massive opportunity. And one that aligns with a number of strategic goals of OSMF[1], specifically around efforts to grow the community, extend the core developer base (and more) ... by fostering a closer relationship between OSM data-derived products / the wider (non-editor) community.
Let it be known I love scope creep.
I'm assuming the requirement is not really to build a single .mbtiles file, but to have some way for a process to serve the correct tile when given a z/x/y tuple.
That's the challenge with the osm.org feedback map, you need to quickly update the small fraction of tiles that very recently changed, while hopefully not processing the remainder.
[1] https://apps.apple.com/us/app/organic-maps-offline-hike-bike...
I’m back on Google Maps as the POI data in Apple Maps is unfortunately very incomplete (Opening times, reviews, new restaurants etc.) even in bigger cities like Berlin.
It's a very cost-effective solution as CloudFront has a 1TB/Month free tier, compared to hosted solutions.
What you're saying is that government data is good, which OpenStreetMap has taken. But that data doesn't update very frequently.
The idea is that you can update it yourself?
And I did get it working! But it was not near as cool as it could be because of two dramatic events:
OSM Foundation violated the trust (nice way to put it) of a participant, OSMBuildings.org, in the search for sponsorship [3] (four years ago, such lost progress :( ) The other is that LeafletJS’s developer is Ukrainian and can’t advance his project [4].
Please consider those two issues when contemplating donating to OSM due to this press release. While I applaud OSM abstractly, it exists because of a massive amounts of public contributions of IP, not because of $$ from a commercial sponsor.
[1] https://github.com/neomantra/go-openchargemap [2] https://github.com/neomantra/go-openchargemap/blob/main/exam... [3] https://medium.com/@osmbuildings/why-were-not-going-to-suppo... [4] https://leafletjs.com/
The OSM Buildings folks called themselves "OSM Buildings", using the OSM trademark. They offered a commercial service. The OSMF was OK with this. It seems the OSMF is OK with a lot of things -- including permitting Cesium to use the OSM mark in their own commercial project.
Live and let live, may a thousand flowers bloom, etc.
Rather than reflect on the fact that their name was not really theirs, but relied on the goodwill of the OSM mark, the OSM Buildings folks decided to ragequit and shut down their project, dramatically claiming that their name was "seized by a multimillion dollar company"?
The whole thing is bizarre to me.
I had come back to temper my response because for sure this is great work by the tech team.
Given that, it seems pretty reasonable to me that the OSMF's stance was basically: your name is your problem, if you think someone is infringing on it, it's up to you to enforce it.
The OSMF runs on a shoestring budget - something like $400,000/year, vs Wikimedia Foundation, which runs on $170,000,000/year. It would be a real shame if a potential donor thought this particular instance was a reason not to donate to the OSMF.
I don't believe the OSM Foundation has ever been involved in Leaflet development, as Leaflet development was supported in the past by commercial vendors of OSM data like CloudMade and Mapbox.
I literally had cloned and was fixing OSMBuildings.org because, among other things, it wasn't clamping values correctly [1] -- it's why my charging markers are white. But I felt conflicted doing that. I was happy with what I spiked with OSMBuildings and started exploring commercial services like MapBox and a few other OSS projects.
Operating projects and companies and organizations is not easy. It sucks what happened there. I'm not a hater and actually looked to Patreon or similar Paul Norman -- and maybe the 'vector tiles' earmark literally means that? But, I'm not happy with that previous behavior of the organization...
So it's great the OSM Vector Tile service will be dramatically improved...
If any of us start doing something interesting with, will we get jacked up like OSMBuildings? Is that the stewardship of this donations? That's the rub.
We never asked osmbuildings to stop using the name. We’ve never granted exclusive trademark permission to anyone - if you wanted to launch a product called “neomantra OSM buildings”, we’d find it cool.
If you start an interesting project, pick a non-generic name.
But it is a lot of data that's very hard to keep updated.
Not sure what you mean by this?
Are you suggesting you can't support the project of a Ukrainian, or that the Ukrainian developer is unable to support their own project due to the war? Keeping in mind that Leaflet is a well established, open source project with any number of maintainers / contributors and (while no doubt an impossible time for a family from Kyiv) @mourner's contribution graph [1] remains remarkably healthy.