On Sun, Mar 11, 2018 at 2:18 PM, Daniel Koć <daniel@koć.pl> wrote: > 3. The OSM community (as a whole) is blinded by the sound of term > "tagging for rendering". I think it gave rendering pretty bad publicity, > while in fact this is a tagging (!) problem and is about making up false > data for some purpose. The most common case seems to be making the data > to look on the particular map as the mappers like it to have, but still > it doesn't make rendering something bad. > > 4. While osm-carto is just one renderer of OSM data, it is the one I'm > aware of which gives any feedback about rendering problems. More than > this: IIRC, this is also the only one consumer project which gives the > feedback to data community. I treat it as a valuable source of > information what could be missing or broken with our data models. After > all rendering maps is a pretty common way of consuming GIS data.
A fair number of users here - including me - render our own maps, and are giving feedback based on our own experience with trying to render them. I know that in discussions on 'tagging' I try to hide the fact that wanting to render something is driving my opinion, because of the widespread misinterpretation of the 'tagging for the renderer' slogan. The meaning of the slogan is that you shouldn't tag an object as what it is not, simply to make it render prettily on the default renderer. On the other hand, discussing how to distinguish one sort of object from another, when the motivation is to be able to render them differently on a custom map, is a tagging question - and I've had such questions dismissed as 'tagging for the renderer.' It isn't 'tagging for the renderer' when it's an assertion that "two objects tagged exactly alike cannot be distinguished by any conceivable renderer!" As it happens, osm-carto is reporting an issue that I've encountered independently. Using the currently favoured model where administrative regions are multipolygons, tagged "boundary=administrative admin_level=N", it is easy to extract the edges and draw along them. However, it is much less straightforward to recognize that a way is common to multiple administrative regions, either because the regions are contiguous, or because regions at different admin_levels are sharing the same boundary. In a typical renderer, this difficulty leads to overdrawing the boundary. Particularly for textured boundaries (various sorts of dash patterns, for instance), overdrawing leads to illegible maps. I'm sure that this difficulty is part of what motivates the OSM-Carto group to be requesting that all ways that participate in admin boundaries be tagged with the "most important" boundary in which they appear. This tagging gives an easy route to displaying the border unambiguously - drive the renderer from the ways and not the relations. Nevertheless, easy is not always right. This tagging of the ways violates the principle of "Don't Repeat Yourself." Any time that you have the same data in two places in a data model, you open the opportunity for those two places to get out of sync. I think this is a particular case where the political problem needs a technical solution. I have not yet been clever enough to invent a method in the PostGIS-Mapnik pipeline to identify ways that participate in administrative boundary relations, select the "most important" boundary and display each way only once, no matter how many relations use it. This is, of course, what is needed for a good many rendering problems, where the definition of "most important" may be specific to a particular renderer. If we had skeleton code showing how such a thing would operate, I'm sure that the OSM-Carto team could adapt to it, (and so could I, on the maps that I render!). I think the problem of making the actual rendering connection is technically deep enough to cause people to request infelicitous tagging to work around it. If the underlying problem can be solved, then the tagging problem goes away. _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
