[Tagging] Tagging request: missing admin_level tags

Warin 61sundowner at gmail.com
Sun Mar 11 23:24:39 UTC 2018



On 3/12/2018 9:50 AM, Kevin Kenny wrote:
> On Sun, Mar 11, 2018 at 2:18 PM, Daniel Koć <daniel at 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.

No. If I were to make a decision on which is 'more important' I will make it based on my interpretation. That may not match yours.

The renders should make the choice based on what they want to render i.e. which one is 'more important' for that map.


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

Yes.

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

As I said .. making the choice at the tagging stage means the resulting maps may all be just the same...

and that is not a good thing! This choice should be made by the map maker, not the data recorder.

As the admin boundaries are numbered in the order of importance to administrators ...
a choice can be made to use that as the rendering importance.
That is one choice that can be made now with no extra tags.
This still leaves others to chose a different order of importance without being distracted by some tag or other.




More information about the Tagging mailing list