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/ _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
