On 3/12/2018 9:50 AM, Kevin Kenny wrote:
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
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!).
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
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.
Tagging mailing list