<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Nov 17, 2018 at 6:29 AM Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>> wrote:<br></div><div>[longish observation blaming OSM Carto for the fact that people</div><div>were coming to map bays as areas...]</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>In my case, OSM Carto had very little to do with it.</div><div><br></div><div>As I discussed in earlier messages, my motivation is that I render a fair number of maps, moslty for my own use and my friends, on actual dead-trees paper (or more often Tyvek, which I suppose you could call 'dead-dinosaurs paper'). I do want my maps to show the names of significant geographic features that appear on them, even if the region of interest of the paper map includes only a small portion of a large feature. I could not figure out a way to do that without defining area features as areas. Doing so runs afoul of Christoph's pronouncement that no area features should be mapped as areas unless every metre of a border was field-verifiable. </div><div><br></div><div>I found that pronouncement quite disturbing, since I live in a region where there are significant administrative regions whose borders are indefinite. (I recognize that there's a cultural difference here: the chaotic American approach to such matters is, "we'll survey it if it ever becomes important enough that someone will pay for the survey." Where is the precise boundary in the swamps of the St. Regis River basin? Nobody much cares. The county line is surveyed and monumented where people do care.) If that pronouncement were carried out to the letter, a couple of counties in my part of the world would have to be reduced to nodes.</div><div><br></div><div>In the case of an ugly dark-blue patch over the Gulf of Bothnia or the Bay of Biscay, I'd definitely have directed my annoyance at the renderer. When I've done my own rendering, I've never distinguished inland from ocean waters by colour - precisely because it unduly emphasizes the arbitrary lines between them, which occur at every river mouth, estuary, and yes, bay.</div><div><br></div><div>Whether OSM-Carto encourages, discourages or is neutral toward the style in question is something that is of no concern to me. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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>I have found that when anyone is advancing an argument with the word 'just' in it, that the word is demanding a suspension of disbelief, and the position would be more accurately stated without it. Deferring the discussion of data processing to a later paragraph, let me translate. _He went through that difficult and time-consuming exercise to place a label._ Can you see how that sounds different? It is not an arrogant assertion that your assessment of the importance of the task is more valid than his. It leaves open the possibility that the presence of the label was important enough to him that it was worth going through that work to allow for it.</div><div><br></div><div>Objects in the real world have names. One of the functions of a map is to inform its users of the names of the objects that it displays. Surely maps have many other functions, but connecting the displayed objects to human language and the human sense of orientation is one of them. It is hard to find a map, anywhere, that does not have labels for named objects because that is a critically important part of what a map does.</div><div><br></div><div>In my particular use case, a node label would be useless to me. I do render large-scale maps that often contain a small piece of a much larger objects. Having a node with the object's name somewhere far beyond the boundaries of the region of interest is worthless to me. That is why I favour carrying area features as areas rather than nodes, always. (It also gives a more sophisticated renderer than Mapnik many more options for resolving conflicting labels.)</div><div><br></div><div>Maps from before the OSM era did this pretty much universally.  Returning to my Jamaica Bay example, <a href="https://caltopo.com/l/EQA0" target="_blank" style="font-size:13px;text-decoration-line:none;font-family:arial,helvetica,clean,sans-serif">https://caltopo.com/l/EQA0</a> shows the meeting point of four sheets in the old USGS 7.5-minute topographic series. You'll see that all four of the sheets have labeled 'JAMAICA BAY', even though the quadrangle to the northwest has only a little triangle of it in one corner and the one to the southwest has only a narrow strip along its eastern margin. That's because it is a locally important feature - and assigning it a name truly is important. It is the feature that dominates the landscape of those who live by it. If I were to be producing almost any map of that area by hand methods, the ocean, the bay and the airport are surely the first three features I'd sketch in, and the labels I would least want to lose.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is only a matter of time until they start labelling natural=sea<br>
polygons and people then create relations with 100,000 members for the<br>
Atlantic.<br></blockquote><div><br></div><div>Here, I think, lies the crux of the issue - the sheer size of features like the Gulf of Bothinia overwhelms the toolchain.</div><div><br></div><div>I surely recognize that the technological limitations are significant, and that we may need to surrender some of our wants because of what the technology allows for. If querying for the Gulf of Bothnia overwhelms the server, and at the current level of development that cannot be fixed, or if many people who are processing the data are using tools that cannot cope with it, then restrictions are reasonable. I'm even charitable enough to surmise that your motivation for the revert (which you yourself admit was badly handled) was that you saw the situation as an emergency - surely data that are severely damaging the ability of OSM to function have to be corrected sooner than later!</div><div><br></div><div>But in that case, let's simply treat it as a practical, technological limitation - which opens up the possibility that as our tools and techniques improve, the limitation can be lifted. I'd entirely accept a guideline along the lines of, "multipolygons that encompass more than W km² of land area, have borders longer than X km, comprise more than Y ways or require more than Z nodes for their representation should be created only in extraordinary circumstances, with advance discussion on the mailing lists". Such a guideline would engender very little conflict, particularly if the specific difficulties are identified, so that the clever technologists in our midst could begin to think about how to address them. </div><div><br></div><div>"I'm sorry, you can't have that right now because today's technology has trouble with it," acknowledges the user's wants. "You shouldn't even want that!" - which is what I have heard repeatedly in this thread - is guaranteed to elicit only the reaction of, "Who are you to tell me what I want?"</div><div> </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, 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>Broken coastline is broken coastline irrespective of whether it is part of another waterbody or not. Moreover, a multipolygon that encompasses a small stretch of coastline will not see any adverse impact from a broken coastline a thousand miles away - those ways don't participate in the multipolygon in question.</div><div><br></div><div>I surely agree that breaking the coastline is a recurring problem - and you have most likely cleaned it up more than anyone here.</div><div><br></div><div>Part of the problem stems from our expansive definition of 'coastline' - which is done in an effort to make the blue background that is the default for the map cover as much of the world as possible.</div><div><br></div><div>I know that in my first couple of years as a mapper, I identified a number of problems with various bits and pieces of shoreline in Long Island's inland waters - including Jamaica Bay. I also left them unfixed - because the best advice that I got was that changing the coastline was for wizards only, that doing so was impossible to validate, and that the slightest mistake would break it worldwide and bring the wrath of the whole community down on my head. In the specific case of Jamaica Bay, I'd be much happier if none of it was 'coastline'. It's part of the ocean only to avoid having an arbitrary, indefinite line across its mouth, or to avoid having renderers like Frederik's distractingly assign it a different colour. It is surely different from the ocean. It is brackish, having less than half the salinity of the ocean. It is slack water except in the worst of storms, while the ocean side of the peninsula often has pounding surf even in fair weather. The locals think of it as an inland water. Nevertheless, current guidelines insist that it must be 'coastline'.</div><div><br></div><div>I suspect that most of the recurrent annoyance of 'broken coastline' stems from just such areas of complex topology in the estuarine environment, and that the real solution is to work on how to model such areas so that local changes can be made without global effects. But that's probably a discussion for another day. Ultimately, the answer may be to generalize the World Ocean and move it a small distance offshore, allowing the near-shore environment to be made up of local objects.</div><div><br></div><div>But that's all speculation - I don't have enough experience with mapping at small scales to comment. Most of the paper maps that I've done are at scales like 1:31680 or 1:25000 (depending on whether the main map scale is in SI or Imperial measure) I'm sure that a global map, or even a 'one in a million' map, has a different set of issues that I fail to comprehend.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Summing up, my opinion is<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(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>I care very little about what OSM-Carto may or may not have decided to do,  but still want to have area features represented as areas for my own renderings, which have nothing to do with OSM Carto. I consider this argument a colossal distraction.</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>I have presented my own problem, which is related to the same features, but a different problem. It appears to demand the same solution. Christoph's answer to my question about an alternative technical approach was, in effect, a request that I hire him to develop one, rather than to recommend a course of action for my own development.</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>Indefinite boundaries are a fact of life. Every river has an indefinite mouth. Several townships and counties in my part of the world have indefinite portions of their borders. Refusing to map the definite borders because of the existence of the indefinite borders is not a viable solution.</div><div><br></div><div>As far as 'huge polygons that will often break' go, perhaps there is a technological solution here. 'osm2pgsql' already has two modes for its treatment of the coastline: import it, or presume that it will be rendered from another source and leave it out of the database. Perhaps 'huge multipolygon' could be modeled with another type of relation, or with some tag on the multipolygon relation indicating "this is a multipolygon that exceeds the size guidelines?" 'osm2pgsql' could then, by default, exclude these features when bringing the relations into the rendering database. That would allow people like Daniel or me, who would like to experiment with labelling and modelling this sort of feature, to work with OSM data independently of OSM-Carto and not fear disrupting everyone else's rendering. If we ever want to have bays, straits, seas, and so on treated in any other form than labels painted in their middle, then we need some space to work in! Local .osm or shapefiles can get you only so far - eventually, you need to try working with the real data.</div><div><br></div><div>North American mappers have already been pursuing this approach in creating relations with 'route=road network=* ref=*' to model our numbered highways, which typically belong to three or four overlaid networks and have many route concurrences. We recognize that the main OSM renderer will never support these - the idea has been conclusively rejected - but have hopes of developing a continent-scale rendering for our own use that will render these in a usable fashion. In the meantime, our relations appear not to interfere with OSM Carto, and our experimentation proceeds.</div><div><br></div><div>I certainly hope that the project will continue to have some pathway that is open to new things, and will continue to dispute the argument that "nothing can ever be done for the first time." </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.</blockquote><div><br></div><div>As I said, I am willing charitably to assume that you saw the situation as an emergency because of tool breakage. </div></div></div>