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

[Christoph Hormann]

On Monday 25 May 2020, Paul Norman via dev wrote:
> https://github.com/pnorman/openstreetmap-cartographic.

In general this looks like a good approach to evaluate where the 
practical issues are without being bogged down by bloated legacy tools 
(well - except for the client side of course).

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

Yes, i think this style as is is a good demonstration that the current 
approach used universally in the industry (and that is used in 
ST_AsMVT() as well) of performing per feature lossy vector geometry 
compression (usually in combination with way_area filtering) is a dead 
end.  You can see that nicely if you overzoom the demo map:

http://imagico.de/files/screenshot_cartographic.png
http://imagico.de/files/screenshot_carto.png

This creates a lot more artefacts and noise in the rendering than the 
AGG rendering issues in Mapnik typically do even at the resolution it 
is intended for - including counterproductively adding a lot of high 
frequency noise in many cases.

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

I think this is a point that cannot be overstated.  Mapbox GL JSON (or 
FWIW JSON in general) in contrast to CartoCSS is a software developer 
centered format and not a cartographer centered format.  Many 
mainstream low sophistication users of client side vector tile 
frameworks focus exclusively on interactive editors and not working on 
the code level - which as you explained is not an option for a 
cooperative community project or for styles with a higher level of 
sophistication.

Just re-casting the JSON data structures in a different format easier to 
edit by hand, suitable for comments and leading to well readable diffs 
is IMO not enough for a truly cartographer centered approach.  But this 
is definitely a hard problem because there are so many in parts 
opposite requirements.

Having a reference renderer that does not build on an extremely complex 
and platform dependent framework (a.k.a. web browser) would be 
important for style development - i think Joseph also hinted in that 
direction.  It would also be important for things like automated tests 
etc.

One other thing to keep in mind - OSM-Carto uses polygon fill patterns a 
lot for differentiating different types of polygons.  While it is in 
principle possible to show fill patterns in continuous zooming in an 
ergonomic fashion i have so far never seen maps in the wild doing that.  
This would be something to consider if you want to create a style 
similar in the richness of landcover rendering to OSM-Carto.

-- 
Christoph Hormann
http://www.imagico.de/