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