gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.54k stars 823 forks source link

Inconsistent initial zoom level for built-up areas and different landcover types #3980

Open jeisenbe opened 4 years ago

jeisenbe commented 4 years ago

Expected behavior

Actual behavior

Links and screenshots illustrating the problem

Moscow, z8: https://www.openstreetmap.org/#map=8/55.710/37.614

Moscow, z7:

jeisenbe commented 4 years ago

It should be easy enough to agree on solving the issues with landuse=railway, man_made=wastewater_plant and man_made=water_works, by rendering them the same as landuse=industrial at low zoom level (that is, with the @built-up-lowzoom color and the same initial zoom level).

What requires discussion is how to solve the issue with different initial zoom levels for built-up areas and other landcover.

1) Change built-up areas (e.g. landuse=commercial) to render in @built-up=lowzoom color as soon as z5

2) a) Step 1: Change all landcover areas to render from z8 only - this was the previous rendering rule, before PR #3458 one year ago. Note that this PR did not really get consensus, see https://github.com/gravitystorm/openstreetmap-carto/pull/3458#issuecomment-439605346 b) Step 2: Use a method similar to the French fork (generating a background raster image for low zoom, eg z3 to z9, based on z10 or z12 data) to show landcover at all zoom level with less rendering artifacts than currently.

I would prefer option 2 in the long-term, but I'm willing to do either option right now to fix the currently inconsistent rendering.

imagico commented 4 years ago

Any work on landcover rendering at the low zoom levels should also take into account #3534.

Also relates to #3670

jeisenbe commented 4 years ago

Would you support 1. or 2. above? The link to #3534 (Slow rendering on low zoom ) suggests going for option 2, perhaps.

imagico commented 4 years ago

I would very much support not having a zoom level cutoff in landcover rendering but the technical constraints of our toolchain make it somewhere between hard and impossible to do this in reasonable quality and efficiently.

2a seems fine to me, 1 would require a look at performance (i.e. solving #3534) and 2b as usual is a larger endeavor that is hard to do with volunteer work.

jeisenbe commented 4 years ago

A third option would be even more technically complex but might provide the best visual results and flexibility:

  1. Render low zoom landcover and water areas with a different renderer optimized for handling small polygons, then combine this with the current tiles for mid and high zoom levels. This solution has been demonstrated - http://blog.imagico.de/on-basic-small-scale-landcover-rendering/ - "the landcover and water areas are rendered using a supersampling approach" - but I believe it is not ready for deployment without a good deal of work, and adding an additional rendering application to the tool chain would be a major change to this style.