Bay/Strait area labelling leads mappers to create huge polygons

[woodpeck]

I am writing to ask the osm-carto developer community to either

• stop rendering on-sea water labels at all
• or stop rendering all water labels on zoom levels below 12
• or introduce a way to place large labels without drawing large polygons

As you know, what osm-carto renders drives what people map. Stuff that doesn't get rendered will be mapped less.

But current rendering rules start rendering the names of large water bodies at zoom level 3, which has led people to create tremendous amount of huge on-sea water areas in the last three years. We meanwhile have 470 "bays", "seas", and "straits" with over 100 members each; 42 with over 1,000 members each, and 6 with over 5,000 members. (The "Labrador Sea" relation - #13850357 - has over 10,000.) A total of 400,000 ways are members of such bay, sea, and strait relations.

The outer limits of these relations are often pure guesswork, and the inner (land-side) limits simply follow the coastline.

OpenStreetMap is not good at handling giant multipolygons like this. Every time someone makes a minor edit to the coastline and splits a way in the course of doing so, a new version of the giant multipolygon needs to be uploaded to the server and checked for integrity, causing unnecessary bandwidth use and unnecessary load on the servers. Anyone trying to extract a sub-section of the data can easily be burdened with a water polygon three times the data volume of what they originally requested. And this is not even beginning to discuss the problems that users and editors have in dealing with these polygons, and how easily they break.

It is not without reason that we have chosen to forgo multipolygons for the sea, instead opting for the well-known "natural=coastline" method. But as things stand, we are not far away from some helpful mapper thinking to themselves, my, why is Baffin Bay visible on zoom level 3 but not the Atlantic Ocean? Let me quickly create a multipolygon for that.

The overwhelming motivation for mappers to create these huge, unwieldy, wasteful, and non-verifiable polygons is that they want to see water areas labeled, and the only way to get there (with current osm-carto rules) is to create these polygons that make life harder for everyone involved.

I implore the osm-carto developers to find a way to stop this madness. I have outlined some ideas above; maybe there are others. But as things are, someone will soon create an Atlantic Ocean polygon "because it renders in a nice big font". Please understand that osm-carto is not "just a map style" - your decisions massively impact what people map. And in this particular department, this has been to the detriment of our data usability and editability.

I am pretty sure @imagico has blogged about this in the past but I can't seem to find it at the moment.

[imagico]

Related to #3634 - where past discussion on the matter can be found. Including references to my past analysis of the mapping incentives by rendering labels based on way_area without visible feedback on the polygon geometry in #3634 (comment).

For clarity - we currently render natural=bay and natural=strait polygons this way, we don't render place=sea/place=ocean features (#2278). #3634 is about limiting that rendering to z4 and above (currently it is at z0 and above) - a change for which there is clearly no consensus because it does not solve the problem.

Of the three ideas how to solve this problem:

• stop rendering on-sea water labels at all
• or stop rendering all water labels on zoom levels below 12
• or introduce a way to place large labels without drawing large polygons

the first two would be strait away to implement (and as already said i would support any of them). The third is more work, it would either require introducing new data preprocessing or changing the database schema to have the coastline data in the database (and introduce a method to importance rate bays and straits based on analysis with the help of the coastline data). Developing either of these in a solid way would be a significant amount of work (though still very little compared to the amount of mapper work currently wasted in drawing and maintenance of the labeling polygons every year).

In addition to the problems mentioned by @woodpeck there is the additional issue i mentioned in #3634 (comment) - that a huge fraction of the bays and straits mapped with polygons do not have an actual name in the name tag any more but an arbitrarily composed labeling string. So even if you'd be willing to ignore all the problems mentioned above the current rendering of bay and strait polygons would still be massively against the goals of this style because we render labels based on a tag that - for those features - is used in a highly inconsistent fashion for something other than recording a name.

@mboeringa - please keep the discussion on topic - discussion on ideas on how mapping in OSM should change does not belong here.

[jeisenbe]

I tried to fix this with #3750 but unfortunately after a long discussion there was only input from @imagico and @kocio-pl among the maintainers at the time. Two of us agreed that this is a problem that needs to be solved, but the PR was closed due to lack of consensus. Perhaps we can re-consider this now?

[jeisenbe]

In #3977 (comment) Adamant36 wrote:

as someone who was involved in a lot of the discussion around, and a supporter of, rendering bays and straights it would probably be best to roll back both. As there's clearly been unintended consequences to rendering them. I don't think "the community" necessarily supported #3438 and #3144 at the time either. So that shouldn't be an issue.

[imagico]

Please no re-enactment of discussions we have had plenty of times already - here and on other venues, just follow the links given above.

Beyond that what the best way is to record verifiable information about bays and straits and more in general, how verifiable local knowledge about the geographic reality can be documented in data form in a way that is scalable and low maintenance, is also fundamentally off-topic here. These are important questions and your comments illustrate various common misconceptions and fallacies in that domain - but that is a discussion for a different place, not here.

Also keep in mind no one has suggested to stop selectively rendering bays and straits mapped with polygons while continuing to render them when mapped in other ways. What is being discussed is to stop the massive nudging of mappers towards creating massive unmaintainable labeling polygons for bays and straits by rendering different representations of bays and straits with equal determination (which is what #3750 is about).

[HolgerJeromin]

Can this issue be closed with merged #3750?