I am excited to announce that the tile.ourmap.us community vector tile server now runs with continuous updates, with full planet updates approximately every 10 hours. I had previously introduced this server in June, offering it as a resource for hobbyists developing their own vector-based maps using OpenMapTiles. Additionally, I’ve managed to reduce operational costs. The service now runs at a rate of less than $2 per month, a significant drop from the $20 per month I had earlier highlighted.
This server also powers the OpenStreetMap Americana project. Consequently, the Americana map will receive 2-3 updates daily. This frequency aids developers designing shields for recently added route relations, and mappers focusing on uniquely American cartographic features like expressways and toll roads which don’t show up on other maps.
Additionally, I’ve integrated an RSS feed that relays planet build statuses. This is linked to the Slack channel #ourmap-tile-renderer. Each time a new build starts or finishes, the server broadcasts a message with a link to the live render feed.
The low cost of this project has been possible due to recent technological advancements by protomaps creator @bdon and planetiler creator @Mike_Barry. I transitioned from mbtiles to the pmtiles format and shifted from an AWS EFS+EC2 setup to an s3+Lambda+CloudFront framework. For those interested in the technical nitty-gritty, I delve into the details in my recent diary entry.
My new rendering server is literally an old laptop I had collecting dust. It tirelessly generates planet builds and uploads them to the cloud. This is possible thanks to recent improvements in planetiler which allows it to build the planet on modest hardware. The only trade-off is a longer build duration.
I hope this project and the links I’ve shared helps everyone get a clearer picture of how vector tile rendering and hosting work. Readily-available and affordable vector tile recipes help hobbyists and community projects focus more on the stuff that matters – digital cartography – and less on being an IT shop or cloud expert. It’s never been this cheap and easy to get started with vector tiles.
I remember waiting for the default Mapnik layer’s rerender every Wednesday, and making do with Tiles@home’s unpolished Osmarender tiles in the meantime. I also remember how OSM suddenly seemed like a different, more real project the moment the Mapnik layer started updating more frequently. As an old-timer, I view this as a similar kind of step change, especially when working on route relations, busways, disputed boundaries, and other things that don’t show up in more conventional rendering stacks. Thanks for literally bringing back Tiles@home!
You omitted the most important detail of all: what’s the server’s name, and what’s the backstory behind that name?
What @Minh_Nguyen is alluding to is our Slack discussion in which we named the server “route66.” This is partly a tribute to Americana in the traditional sense but also a nod to the old-school practice of hosting a production service on a personal laptop. Such a move is reminiscent of what a hobbyist might undertake, emphasizing the project’s origins — a group of enthusiasts piecing together the services that define the project.
Beyond the nostalgia of our early days, it’s noteworthy that the real Route 66 was eventually replaced by the Interstate Highway System. Similarly, I hope our makeshift living room laptop setup will be replaced by robust production servers and services. Our current practice of rendering and swapping entire planet files is clearly a transitional phase towards a future with more frequent updates. I eagerly anticipate the day when someone can demonstrate and document the process for genuine, minutely vector tile updates. It would be exciting to see industry partners continue to contribute computational resources for community rendering projects and advance the vector space. After all, this type of open-source exploration benefits companies and app developers as much as it does the individual hobbyist.
When I tried to customize my own vector tile style, I noticed that some of the POI is missing. Turns out that, there is “poi rank” system that determine the visibility of the POI. Meanwhile I also noticed that some OSM tags are completely unranked, which makes them not visible at all in this vector map.
Where can I find the documentation regarding this POI rank?
It’d be really nice if that was added as a project at taginfo so that people can see what what tags and values are processed (and what they are processed as).
In the meantime, OSM Americana maintains a reasonably complete taginfo project file that should give a sense of what’s supported by OpenMapTiles. Compiling this file required reverse-engineering OMT’s poorly documented tag mapping. If you see something that renders but isn’t listed, please file a bug report.
This is a nice project. Unfortunately for me I am still “forced” to make my own since the default zoom levels are inadequate for me. In smaller zooms there are a lot of missing data, ranging from water to paths and tracks and my main mode of use is hiking, biking (and related stuff like drinking_water, even for springs).
Since upstream make its of decision what to include and what not I wouldn’t try to enforce my point of view on them, but their data basically missing everything I need below z14.
(My EU is not updated right now, but the Hunagrian part gets daily updates.)
You would need to create an AWS account. Then, install AWS cli tools and configure it for your account. At the command line, this should look something like aws s3 cp s3://osmus-tile/planet.pmtiles <local location>. Note that you will be billed for this at their standard rate, which I believe is 9 cents per GB. That’s about US $7.00 or so for downloading the planet file. I believe AWS also gives you the first 100Gb of egress for free, so in theory this would be a free download if you don’t do it more than once per month. Make sure your internet connection is stable if you choose this route
You could also render it yourself using the scripts on OSMUS’s tileserver utility.
You could also stand up your own AWS Lambda and CDN to connect to the bucket that OSMUS provides and therefore not have to ever touch the planet file.
I’m far from being an expert on AWS billing, but wouldn’t it be the bucket owner paying for the transfer bandwidth, even if a different user is the one making the request, unless the bucket is marked as “requester pays”? (In which case I think you’d need to add a flag to the copy request to indicate that you’re willing to be the one paying.)
I’ve managed to build a MapLibre protocol that proxies between two pmtiles source : mine for France, another one (French public street view panoramax.fr’s) for the reste of the world.
This is a very good option for me, since building france.osm.pbf to pmtiles is doable in a few minutes, so I can personnalise the tiles 90 % of my users will use while assuring no discontinuities abroad.
Was quite tricky because of oceans not being included in the French pmtiles extract : I had to add a land.pmtiles.
Sharing this here as I think some other projects would have the same needs: )