[OSM-dev] OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto

ndrw6 at redhazel.co.uk ndrw6 at redhazel.co.uk
Mon May 25 14:45:11 UTC 2020

On 25/05/2020 01:34, Paul Norman via dev wrote:
> 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 think we will need fairly heavy pre-processing (filtering and 
simplification/generalization) of data before they hit the tile and the 
client. Carto is doing some of it already, even though data stay on the 
server side at all times. With the client-side rendering this is much 
more important for three reason - real time rendering, network traffic, 
limited resources on client side.

Some ideas:

- Tiles should contains only objects to be rendered, so all the 
filtering currently done in Carto should be applied at the tile 
construction time.

- Currently Carto produces a lot of data that are later filtered out in 
Mapnik (via spatial occlusion) - this also should be brought back to a 
tiling script.

- Tiles should be split into layers (similar to layers in Carto). Then 
the user would have an option to select layers they are interested in 
(think language versions, POIs). With more, smaller tiles there is also 
a potential for distributing the server side load more uniformly.

- For z5-z12 we will need some kind of polygon 
generalization/simplification. For example, at z7 I can see all landuses 
in England, with some towns occupying only a couple of px but but still 
being comprised of hundreds of landuse polygons. I'm not talking about 
anything fancy, but merging anything sub-1px into "pixel rectangles" 
could go a long way. (Edit: I see you are already doing it - I can see 
some simplified landuse polygons when zooming in further).

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

Do we need minutely updates for vector tiles? Sure, that's a nice 
feature to have but with client-side rendering any performance issues 
will be directly exposed to the users. And performance is a big issue in 
most client-side rendering solutions. If we can keep the current raster 
backend with minutely updates for mapping feedback, I have no problem 
with hourly or daily updates for the vector version. We would need a 
raster option for browsers/devices not supporting WebGL anyway.


More information about the dev mailing list