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