Hi Frederik (and, of course, everyone else). I appreciate your expanded
explanation on this.
On Sat, Nov 17, 2018 at 11:29 AM Frederik Ramm <frede...@remote.org> wrote:
>
> So, long story short, a couple of "my" maps suddenly started to show
> ugly dark-blue patches e.g. across the bay of Biscay, or the Gulf of
> Bothnia. That's how I noticed and investigated what was happening, and I
> found that Daniel had added the Gulf of Bothnia polygon to accompany the
> newly-introduced OSM-Carto feature of rendering bay names depending on
> the size of the area.
>
An unpleasant surprise. I can understand why you wouldn't be happy. I
wasn't, and still am not happy
with the icon recently added for outdoor seating areas: it incorporates an
umbrella but most outdoor
seating areas in my part of the world are not covered. I contemplated
removing outdoor seating areas
I myself had mapped as I considered the icon to be very misleading but I
never contemplated removing
outdoor seating others had added even if I knew they were not covered.
Of course I can adapt my map styles, and have indeed done so, as I often
> have to do when mappers change their behaviour. But I was pissed off
> nonetheless; I felt that OSM-Carto is just one rendering project and
> does not (and should not) have the authority to steer what mappers do.
> There are many other people interpreting our data and they should not be
> forced to jump whenever OSM-Carto decides they want to change something.
>
There I start to part company with you. Your thinking there means we can't
ever change anything
about OSM Carto, or the way features are tagged. OSM is a dynamic, living
entity. Like all living
entities, stasis ultimately means death.
I do agree that while we should not "map for the renderer"
I would modify that a little. We shouldn't LIE for the renderer. Given
two, equally valid (documented,
accepted, supported) tagging schemes we are at liberty to choose which to
use, and our choice may
be influenced by the rendition of one or more renderers. But that's a
side-issue.
> it is good to have a central map that provides valuable feedback, and
> keeps mappers
> from, say, introducing random highway types by simply not rendering
> them.
>
I don't have a problem with "you can now have huge, named bays." Actually,
since I live a mile from
the biggest bay in Wales (Cardigan Bay) I think that's a nice feature to
have. But I wouldn't be happy
if it rendered in an ugly way. A better placement/size of the label would
be a good thing. Maybe even
a very faint (and optional, perhaps visible only on things like OpenSeaMap)
line denoting the
boundary between bay and ocean. The ugly thing you described would be
sub-optimal.
But I felt in this situation, they had overstepped their mandate,
> *especially* because they were not reacting to something that people
> were doing, but actively creating a new feature ("hey, you can now have
> huge named bays") and at the same time adding the data to OSM to
> illustrate their new feature.
>
That's a circular argument, though. Nobody is mapping something because
the carto doesn't
render it. Therefore the carto shouldn't render it because nobody is
mapping it. Therefore
nothing should ever change because we have everything we will ever need
right now and it is
perfect. That's not the case, nor will it ever be the case.
I think a better argument is to look outside of OSM and see what other maps
do. The editor
layer index gives access to several out-of-copyright maps of the area of
Cardigan Bay, and they
all label it as such, and their label placement and size depends upon the
geometry of the bay.
I think having the toolchain compute the label placement from an
(admittedly somewhat
inaccurate polygon) is better than me imagining the polygon and computing a
node position
myself. The former allows for an appropriate size of label (much as the
label on woodland
depends on the size of the woodland) whereas with a node we'd require
sub-tags such as
"bay=small" analogous to "place=hamlet"). An area allows later mappers to
see what border was
used and, if better information becomes available simply tweak it rather
than trying to guess how
the node position was determined. Just plonking a node down is the
ultimate in lossy compression
of information.
> Another pet peeve of mine is a dislike of what I call "relation mania",
> where we have land boundaries that can easily be part of 20 different
> relations on different admin levels and other boundary types. It's bad
> enough on land, and makes editing harder for everyone; when I saw the
> Gulf of Bothnia polygon (which *already* is large enough for the web
> site to time out when you want to show the history) I thought: Is this
> *really* necessary if all you want is a nice label written on the sea?
>
I agree that there seems to be a tendency to be over-enthusiastic about
relations where a simple
polygon seems (to me) to be adequate. But that's probably because I don't
understand the reasons
for using relations in this sort of situation well enough.
And let's be totally clear here: A nice label on the sea is all that
> Daniel wanted.
I cannot say that is a bad thing. A few months ago I added an L-shaped car
park and the "P" symbol
wasn't placed within the boundary of the car park but at the centre of the
hull surrounding it. That turned
out to be a known bug in the carto which was subsequently fixed. It is
good to have labels and icons that
are placed, and sized, sensibly.
> He's not a maritime scientist who for some reason needs
> the exact extent of Bothninan Bay - he went through the time-consuming
> exercise of combining more than 1600 coastline pieces into one huge
> polygon which is difficult to handle for data processors and editors
> alike JUST TO PLACE A LABEL.
>
And here you come to the type of argument I would accept. If it's breaking
the toolchain then
something has to be changed. As an interim, emergency fix, maybe even
removing the problematic
object. But I don't go as far as saying "We should never do that" but "If
we do that, we should do it
properly in a way that doesn't break things."
> If you are not interested in labels, then this is wrong because of the
> side effects.
>
You haven't convinced me that the side-effects could not be suppressed.
But that's from my lofty
viewpoint atop Mt Dunning-Kruger.
> If you *are* interested in labels, then this is wrong because (a) it
> means that you have to go through this huge exercise just to place a
> label,
Erm, no. You don't HAVE to do it that way. You could just place a node.
You MAY do it that way
if you feel the result justifies the effort. You can use a node to
represent a POI if you're in a hurry
but can use an area if you have a little more time. Stepwise refinement is
a good thing.
> and (b) the label will vanish as soon as someone breaks the
> polygon by e.g. creating a small self-intersection along one of the 1600
> coastline bits. It will probably be gone more often that it is there.
>
Is this because it was done via relations rather than by a simple area?
The sort of area somebody (might
have been you) pointed out as flawed because it was a trapezoid that didn't
touch the coast at any
point? I saw it as a rough approximation that could be improved at a later
date, but others saw it as
an offence against humanity. Everything we map is an approximation to
reality, an approximation that
may later be improved upon with more effort.
> (1) the OSM-Carto project and Daniel have overstepped their mandate as
> the maintainers of our style, and should have sought a wider consensus
> on this before acting;
>
Can you point me to a documented definition of their mandate and how this
action contravenes it?
(2) the decision they have made is not a good solution for the
> cartographic problem they wanted to solve;
>
If so, what is a better one? Note that I do NOT consider me drawing
imaginary borders in my head
and performing complex calculations so I can place a node to be a better
solution.
(3) the decision they have made will lead to people creating huge
> polygons that will often break, make coastline editing harder, and have
> at least one totally made-up edge.
>
Many bays are defined by end-points at the land/ocean boundary. Cardigan
Bay extends from
Bardsey Island to Strumble Head. A straight line joining the two is a
first approximation. Even
if you didn't know those defined points, eyeballing it would give you
something very similar. That
first approximation could be refined later from knowledge of currents
and/or depths, since a bay
provides shelter from currents in the wider ocean.
(4) Frederik has been an utter dick to try and start the discussion by
> deleting the Bothany Bay polygon, instead of simply raising it here. It
> was wrong, I'm sorry.
>
>From another post to this thread, it appears that you and Daniel have a bit
of history of disagreements.
Maybe you should have discussed it with other members of the DWG instead of
taking unilateral
action. Thanks for apologising, though.
--
Paul
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
