[OSM-dev] OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto
joseph.eisenberg at gmail.com
Mon May 25 05:26:58 UTC 2020
Thank you for making this, it looks like a lot of work!
These client-side vector tiles at z8? (
My laptop (2015 Macbook Pro, 16 GB RAM, 2.2 GHz Intel Core i7) appears to
use some effort to show areas with a large amount of data,
For example if I view England + Wales on z8 and then move over to the
Netherlands and then to Germany, at z7 and z8,
CPU usage goes up to >100% for a time, and there is a noticeable delay.
Perhaps part of this is a delay in serving the tiles?
It would be nice to see a demonstration of this applied server-side to
produce raster tiles. Are there any samples of that yet?
– Joseph Eisenberg
On Sun, May 24, 2020 at 5:37 PM Paul Norman via dev <dev at openstreetmap.org>
> I've been working on a new project, OpenStreetMap Cartographic. This is
> a client-side rendering based on OpenStreetMap Carto. This is an
> ambitious project, as OpenStreetMap Carto is an extremely complex style
> which shows a large number of features. The technical choices I'm making
> are designed so the style is capable of handling the load of osm.org
> with minutely updates.
> I've put up a world-wide demo at
> using data from 2020-03-16, and you can view the code at
> Incomplete parts
> Only zoom 0 to 8 has been implemented so far. I started at zoom 0 and am
> working my way down.
> Admin boundaries are not implemented. OpenStreetMap Carto uses
> Mapnik-specific tricks to deduplicate the rendering of these. I know how
> I can do this, but it requires the changes I intend to make with the flex
> Landuse, vegetation, and other natural features are not rendered until
> zoom 7. This is the scale of OpenStreetMap Carto zoom 8, and these
> features first appear at zoom 5. There are numerous problems with
> unprocessed OpenStreetMap data at these scales. OpenStreetMap Carto gets
> a result that looks acceptable but is poor at conveying information by
> tweaking Mapnik image rasterizing options. I'm looking for better options
> here involving preprocessed data, but haven't found any.
> I'm still investigating how to best distribute sprites.
> The technology choices are designed to be suitable for a replacement for
> tile.osm.org. This means minutely updates, high traffic, high reliability,
> and multiple servers. Tilekiln, the vector tile generator, supports all
> of these. It's designed to better share the rendering results among
> multiple servers, a significant flaw with renderd + mod_tile and the
> standard filesystem storage. It uses PostGIS' ST_AsMVT, which is very
> fast with PostGIS 3.0. On my home system it generates z0-z8 in under
> 40 minutes.
> Often forgotten is the development requirements. The style needs to
> support multiple developers working on similar areas, git merge conflicts
> while maintaining an easy development workflow. I'm still figuring this
> out. Mapbox GL styles are written in JSON and most of the tools
> overwrite any formatting. This means there's no way to add comments to
> lines of codes. Comments are a requirement for a style like this, so
> I'm investigating minimal pre-processing options. The downside to this
> will make it harder to use with existing GUI editors like Fresco or
> The goal of this project isn't to do big cartography changes yet, but
> client-side rendering opens up new tools. The biggest immediate change
> is zoom is continuous, no longer an integer or fixed value. This means
> parameters like sizes can smoothly change as you zoom in and out,
> specified by their start and end size instead of having to specify each
> Want to help?
> Have a look at https://github.com/pnorman/openstreetmap-cartographic and
> have a go at setting it up and generating your own map. If you have
> issues, open an issue or pull request. Or, because OpenStreetMap
> Cartographic uses Tilekiln have a look at
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev