Limit natural labels rendering to z4+

[kocio-pl]

There are several natural tags that can be rendered pretty early, like bays, capes or islands. No island shows its label earlier than z4, so it makes sense to limit also other natural objects to this. Currently Baffin Bay stands out (it's the only label on z2+), which makes it a practical problem to solve:

Please be aware that it's highly controversial problem discussed (currently there is a try to define peninsulas: https://github.com/gravitystorm/openstreetmap-carto/issues/788#issuecomment-453248593) and I don't think we can resolve it in the single ticket, because the root causes are much deeper. I just like to make an upper limit as a fix to create some balance for labels.

If you are interested in more details why it's so heated debate, here is a diary entry from @imagico who presents this problem as the opponent of rendering such areas at all:

https://www.openstreetmap.org/user/imagico/diary/47432

[imagico]

No amount of zoom level threshold tuning will solve this.

I stated my position on this in https://github.com/gravitystorm/openstreetmap-carto/pull/2700#issuecomment-317236118

This would mean removing way_area logic from all features that are rendered label only. That AFAIK is currently:

• natural=bay
• natural=strait
• shop=mall
• natural=cape

tourism=attraction was removed in #3603. shop=mall is a legacy case that is not really that significant practically (see #2702). The other three were all added during the last year.

Note it is not really a heated debate, it is just a point where this style has during the past year moved most strongly from mapper support towards active mapper steering - maybe unintentionally originally but the effect is still the same. Adjusting zoom level thresholds would just tune the mapper steering into a different direction, it would not remove it.

[kocio-pl]

No amount of zoom level threshold tuning will solve this.

Please follow the rationale with the scope clearly defined (what I mean by "this" which is to be solved here and what is "that" which is not to be solved here).

[imagico]

Then i rephrase: This issue is not something i consider worth solving because it would only (poorly) hide the real problem, which is using way_area for making prominent rendering decisions on features without giving the mapper feedback on the geometry in question and thereby creating counterproductive mapping incentives (that is using the polygon geometry essentially to manually specify way_area).

[kocio-pl]

Note it is not really a heated debate

I beg to differ, this is how the discussion looked like (and the comment above just illustrates the heat):

https://lists.openstreetmap.org/pipermail/tagging/2018-November/thread.html#40911

[matkoniecz]

Hopefully I will not give anybody ideas but in part I worry that z1/z2/z3 labels make easy to make large-scale vandalism that will take long to fix due to rendering delays (that is partial reason for reporting #3705).

[matthijsmelissen]

@imagico also wrote a blog about this recently.

[imagico]

I don't think the incentive for z0-z3 is so much larger than for the higher zoom levels. And any label that turns up at z2/z3 will also be visible at z4 with the current logic.

The problem is not so much true vandalism but well meaning but misguided label drawing. Everyone who draws one of these bay/strait polygons thinks they are doing a good deed by labeling an important feature and they feel confirmed in this belief by this style.

[imagico]

What i wrote about the wider topic is:

https://www.openstreetmap.org/user/imagico/diary/47432 (which is already linked to above)

https://www.openstreetmap.org/user/imagico/diary/43957

http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/

[Adamant36]

Everyone who draws one of these bay/strait polygons thinks they are doing a good deed by labeling an important feature and they feel confirmed in this belief by this style.

I don't know if id say its because they think their doing a good deed. Its just that things with names in real life tend to get named on the map. I don't see what's so shocking or bad about that, or why it has to be about personal motivations of people doing it.

I'm pretty sure people doing it aren't "confirmed in their belief" by this style either, but who cares if they are? I remember that when we added rendering for natural=cape in November that all them already had names even though they weren't being rendered yet. Rendering them had nothing to do with it. Remember, correlation does not imply causation.

[matkoniecz]

but who cares if they are?

If we consider such tagging as undesirable - it is due goals of this style. See https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose ("important feedback mechanism for mappers to validate their edits")

[Adamant36]

If we consider such tagging as undesirable - it is due goals of this style. See https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose ("important feedback mechanism for mappers to validate their edits")

I don't think people personal beliefs about what they are doing is mentioned anywhere in cartography file. Maybe I missed it though. The important thing is if rendering the name is actually causing a feedback mechanism or whatever in this case. Why the person is doing it or what is in their heads aside from that isn't important IMHO.

Personally, I don't think rendering of names leads to more tagging of names. If something has a name people will tag it with one. If not, people won't. Just as many none rendered objects have names as ones that do (accounting for the fact that most popular tags are rendered). That's my conclusion based on the evidence. I've combed through hundreds of objects not rendered yet and spent many hours looking at the name values in Taginfo. From what I've seen, name rendering doesn't act as a feedback loop for more name tagging (or its so small an effect it doesn't matter). Except as a side function of just tagging that object more in general due to it being rendered.

I've also messaged plenty of users who miss used the name tag. None of them did it as a "good deed" to anyone or due to nefarious intent. 99% of the time it's just pure ignorance of the naming conventions.

[imagico]

@Adamant36 - you clearly have not understood the issue here - this is about incentivizing drawing of non-verifiable geometries, not about name tags.

The influence of labeling natural=strait/bay/cape here based on way_area on mapping trends is beyond any doubt. If you don't see that you are not looking closely enough (or as said before looking for the wrong thing). If your personal opinion is that this development is positive and desirable to support that is fine. But this style has a different responsibility.

[Adamant36]

"you clearly have not understood the issue here - this is about incentivizing drawing of non-verifiable geometries, not about name tags."

In relation to the label no? The issue title says "label" in it and word "label" is used in multiple message mention "labels." You even say its about labels in your message after saying its not about labels. Even the yellow category label at the top says "text." but if you say its just about "non-verifiable geometries" though, my bad. I guess.

(to me it seems like you brought up "non-verifiable geometries" after the fact/original as a side thing, that know one really responded to and didn't go anywhere. As evidenced by the issue still being open with the "text" label and the title being the same, but that could just be me).

"your personal opinion is that this development is positive and desirable to support that is fine"

No where did I say it was my opinion that the "development," whatever that means, is positive or fine. I just said your assumption about my its an issue was wrong and that you shouldn't falsely ascribe the internal motivations of mappers to things or use them as metrics for decisions. Last time checked cartography and computer programming are both sciences. How you work with them should be based on more then your probably false opinions about people's feelings, your own feelings, or "just because."

For instance matkoniecz's whole "I'm going to close this issue and refuse to talk about it because its controversial" thing (which btw is actually what makes it controversial in the first place in a lot of cases). Is completely antithetical to that. So is a lot of ways I see you rationalize things. Considering your suppose to be the "wise old sage" here, a lot of what you say is nonsensical and lacking in evidence to support it.

I'm not insulting you by saying that. Your clearly an intelligent person. That's just my observation from the conversations we have had and the messages of yours in other discussion that didn't involve me that I've read. Its highly possible to that your just such a different intellectual plain then me that its like a cave man trying to read Marx's Capital. Who knows). I'm not a moderator and I can be a little "wordy?" sometimes. so I can see why you and matkoniecz would be inclined to talk down to me from your obviously superior positions (sarcasm), like I'm an irritating fly that keeps landing on your expensive, obviously well earned steak or something. Anyway..I say it all in jest and respect, maybe. That's the important thing, I think. I should probably shut up now and go clean my room, bucko.

[matkoniecz]

Personally, I don't think rendering of names leads to more tagging of names.

In my experience that it is not true. Rendering something typically increases popularity of tagging this.

At least this is common belief of many people (see landcover discussion).

[imagico]

For better understanding maybe: The name is what mappers enter into a name tag of a feature, a label is a rendering of names in the map. Many of the recently added free form bay/strait polygon drawings (including the one this issue was opened about - see here) are not newly mapped names, the names had already been mapped a long time ago. Rendering labels in this style or rendering them more prominently does encourage mapping things with names. But that is not the issue here. The issue is basing the label styling and starting zoom level on way_area without giving the mapper feedback on the mapped geometry which steers mappers to draw non-verifiable free form labeling geometries.

[Adamant36]

In my experience that it is not true. Rendering something typically increases popularity of tagging this.

I think that's true in cases where the tag is the main thing being rendered, like with landuse areas, but not with names. Since its a tag that's always added on to other main tags. So the increase in rendering of it would only be proportional to the increase in mapping of whatever its the secondary tag to. There's a lot of tags out there that have been rendered for a while though that don't have name tags when they could. So I don't even think that's really true. Who knows though.

Ultimately there isn't a good way to tell most of this stuff. OSM is kind of its own unique thing. Which is one of the reasons I keep going off about being more evidence based so much. I don't think the normal conventions of cartography or how people normally use maps apply to it in a lot of cases. So I feel like it needs a different/higher standard or something. Normal things would probably apply in the case of landcover rendering (btw, I fully understand why both of you don't want to support it. I just feel like its short sighted. It's not my intention to be a jerk about it though. So I apologize if I come off that way).

@imagico, that makes more sense. Thanks for the extra explanation.

[kocio-pl]

In my experience that it is not true. Rendering something typically increases popularity of tagging this.

I think our experience is not enough here. There are examples where rendering (or not rendering) has no visible impact on the amount of some objects. It would be good if somebody made an analysis of at least few different cases - I suspect there is some more complex pattern involved and I hope we could discover it.

Please also notice that this ticket is only about making labels rendering more balanced. The veryfyabiity stuff is even more complex and deserves separate ticket - or rather discussion on the Tagging list, because the source lies there, not in how do we render things. For example coastline problems are similar, because it's about areas with some undefined borders - see for example latest example here: https://github.com/gravitystorm/openstreetmap-carto/issues/3695#issuecomment-469850258. But there are a lot more questionable tags when it comes to veryfyabiity - like population tag which we use, borders (there is no line on the ground in many cases and we extrapolate it from points or simply use 3rd party administration data) or names of places in different languages (how do you verify Vienna name in farsi other than using 3rd party sources other than locals?).

I also still wait to hear the answer about how one can verify bay/ocean/continent/etc. nodes (if "a middle" - of what area and why derivative is more exact than original shape? if "where you want to see labels" - it's completely non veryfiable):

https://www.openstreetmap.org/user/imagico/diary/47432#comment43843

But anyway this ticket in no way makes veryfyabiity problem better or worse, because skipping few first, the most visible zoom levels does not really hide anything, does it?

[jeisenbe]

OK, so @kocio-pl would like to be able to show labels for large marginal marine features (eg bays, gulfs, bights, etc) at a reasonable zoom level, sooner than z15 (which would work for the smallest bays). And he'd also like to see labels for larger straights sooner.

@imagico is opposed to showing labels based on way_area (the size of an OSM polygon) for features that do not have an area rendering, because it does not give good feedback to mapper about the area. And in the case of bays, marginal seas, straights and capes, the limit on at least one side is not verifiable. Also, the creation of large multipolygons is not good with the current editors and tools.

What is a compromise solution that you can both agree upon, so that we can reach a consensus?

The options that I can think of, in order of simple to complex:

1) Easy: Go back to rendering bays and straights just based on the nodes or polygon center, ignoring way_area.

2) Fairly easy: a) For straights: tag straights as linear ways, and use the length of the way to decide on the orientation and size / zoom level of the label (I think this is a reasonable idea) b) Tag bays with a size=, width= or length= tag, use this to determine the zoom level and labels size (This might be controversial, and would require more work from mappers than just placing a node)

3) Harder: Create full multipolygons for all straights, bays, seas, etc. This is difficult to manage with the current tools and difficult to maintain, and many of the lines drawn would not be verifiable.

4) Harder: Create preprocessed data based on the nodes plus the nearby coastline, as @imagico suggested in the tagging mailing list discussion. This sounds technically possible, but I'm not able to do it. Perhaps @imagico was considering showing a demonstration? Or someone else could create a datafile.

5) Hardest: Develop a new data type that allows mapping fuzzy areas without resorting to huge multipolygons. For example, it was suggested that a peninsula or bay could be defined by just 2 nodes one the coastline. Or some other sort of "fuzzy" data structure might be possible (I don't know much about this theory).

[jeisenbe]

Another idea: Use areas from Wikidata; see new issue #3720

[imagico]

Thanks for the summary. I think that is fairly accurate.

Regarding 2a - that would have exactly the same problems as polygon labeling based on way_area. It would none the less be a huge step forward from the current strait rendering to render straits on linear ways in some form since this has for a long time been established and verifiable tagging for many long, narrow and curved straits (in particular of the submerged fjord or river type - like https://www.openstreetmap.org/way/163242449) while mapping straits with polygons had no significant use outside Scandinavia until this style started rendering them.

Regarding 4 - visual demonstration can be found in http://maps.imagico.de/#map=3/80.644/56.205&lang=en&l=dark&r=fj. I have no publishable code for that though. But this is no rocket science. I have explained the basic idea several times, for example in https://lists.openstreetmap.org/pipermail/tagging/2018-November/040925.html

[kocio-pl]

From all the given propositions only 5 sounds mostly good for me (solves part of the problem without hiding that there is a deeper problem), the rest omits some serious, general problems OSM has with water. The more I think about them, the worse it looks.

Verifiability is good when it is on the ground objects. Roads, buildings, shops - that is mostly easy. The name is visible, the shape is rather clear - so far so good. There are some natural objects that you can see the areas more or less (no such clear line), but it's harder with names (forests/woods, fields).

Water has blurry edges and carries no visible name most of the time. The pond is easy to draw, but this is quite rare that water is isolated and may have a pole with a name. By definition water is liquid, which is the source of many problems:

• There is no clear, verifiable border between lake and the river that runs into/out of it. We just ignore it (because most of the time it's visible only at small scale, which gives false sense of security).
• We use way_area for river banks, which is even worse than bays, because there is no 1:1 feature/tag correspondence - we just ignore violating this rule and chop them into virtual pieces to have nice water rendering on higher zoom levels.
• There is no clear border for wide river estuary going into the sea or the ocean. We just ignore it and draw arbitrary line.
• There is no clear line for coastline, the difference between inner waters and "world ocean" is not given. We just do it to make it easier to work with data and rendering.
• There is no clear definition what sea, bay or gulf is. Names can suggest the type, but it can be different in different language.
• There are no visible names for many water areas.
• The lines have the same problem as nodes - there are some objects that have no real "ends", so it depends on someone defining it. This is trying to follow the rivers tagging, but with not so well defined borders, it would be just nice for labels rendering (hinting the general direction).
• Nodes might be first approximation for small water areas, for big ones they are simply abusing proper generalization (even on the global scale you can see they are not points) - they are just hiding the problem with water areas and are less verifiable than areas (see next item).
• There can be multiple nodes for water areas, and you can't say which is right, because "the middle" can be defined in multiple ways for non-trivial geometrical shapes and there is always some area borders you have to start with.

Not only this is very wide and general problem, but also I see no easy way to fix this. Defining fuzzy areas means saying it loud, which would give OSM water data more credibility than currently, so data consumers can make conscious decisions (any preprocessing takes it away - it's a black box one has to trust blindly). Still the problem of the best approximations remains - the way it can be verified is totally unknown, but maybe some common rules can be developed.

Some of these problems will become apparent when we will change the river color. It may be considered a gain to show this problem stronger than currently (apart from better rivers visibility). It is not only a bay or strait problem, anyway.

(Still we are discussing some other things than this ticket is about. I understand how easy it evolves into discussing similar problems, but limiting rendering natural labels is much simpler idea and it's for all the natural tags, not only for water.)

[imagico]

I would like to try keeping the discussion focused on what this project can and should do. The views of verifiability expressed by @kocio-pl do not represent the consensus of either the OSM community or the maintainers here but this does not really matter for the decisions on this issue. There are a number of clear misunderstandings in what you wrote i would gladly explain - but not here.

Back on topic - i have not commented on option 5 because it is not really an option but wishful thinking. It is a classic case of trying to suggest technical solutions to a social problem - the social problem being the desire of mappers to record non-verifiable data. That is not going to work. The idea for mappers to develop mapping and tagging concepts for better defined recording of the verifiable aspects of limited verifiability features is not necessarily bad but it is (a) not really necessary for maritime features like bays and straits because we already have a precise and consistently used concept of mapping the coastlines and (b) not really of use for style developers because we still would need pre-processing to derive importance rating and labeling geometry hints from this kind of data just as we would need to do right now if we don't want mappers to hand paint the labels for us.

My suggestion of how to proceed: Go with option 1, in addition render straits mapped with linear ways to remove the incentive to use polygons instead and then discuss and develop a solution for importance rating those features using the coastline data (and possibly derive further labeling hints - though this would be purely optional and you could even say this is not even desirable because it would raise the bar for polygon labeling in this style in general)

That would mean rolling back large parts of #3144, #3438 and #3452 - which i doubt will get consensus. But it should of course be noted that these changes were merged without consensus in the first place. Moving away from a consensus position is easy, moving back to it is much harder.

[jeisenbe]

I've opened a PR to fix the rendering of capes. Since the proposal for natural=peninsula has been approved, it is now clear that natural=cape is restricted to the extreme point of a headland or cape.

I would be happy to submit PRs to fix the issues with bays and straights. Adding the rendering for straits mapped as linear ways should be non-controversial, so that's next on the list.

However, I'm not sure what's to be done about bays.

My impression is that @kocio-pl wants this style to display bays at appropriate zoom levels and with appropriately label size and position, so mapping as polygons is a means to this end. Is this correct?

If this is the case, then I think it would be possible to reach consensus if we can determine label position and size based on a script that uses the coastline and nodes. This script would also make it possible to render seas (and peninsulas?) at the proper zoom levels, in addition to bays.

Unfortunately, I am not capable of writing such a script myself.

@imagico, would you have the time to develop such a script if we can agree in advance to try it?

[Adamant36]

@imagico, I'm not sure what your issue is specifically with natural rendering. You would agree that they are actual things that have names etc right?

While I agree that in cases where they are mapped as areas, the specific boundaries of the area might be fuzzy or mapped "arbitrarily" in some cases (which there's really no way to verify if they are or how what percentage it is), that could go a lot of things that are rendered, both natural and otherwise, and it just seems like the trade off of name rendering.

For instance 99% of landuse is isn't mapped by "real world" or "verifiable" means, but its still worth rendering it. I've never been clear on where mapping of coasts should end and beach mapping should be start. There's a hundreds of thousands of instances of leisure=park that aren't mapped according to their actual areas. That doesn't stop any of those tags from not being rendered. I don't see anyone beating the war drums (so to speak) to have rendering for those removed either. Sometimes you have sacrifice in area to gain in another. I'm not sure what the particular animus with the rendering of tags you mentioned is. Except @kocio-pl did them "without consensus."

I'll mention as a side that the only reason @kocio-pl rendered them without consensus was because either none of the moderators where active in the project at the time or only participated in specific things that wasn't those issues. It wasn't out of any intent to act unilaterally on his part though and I know on the cape issue, which I did, we discussed the pros and cons of rendering it before time. We just decided rendering the name was worth the trade off. Its fine if you disagree, but it was a "best option at the time" type of thing, and I don't see why it can't be improved on. Instead of reverted outright, which there isn't a argument for. There's always going to be trade offs to however you render them though.

[imagico]

@imagico, would you have the time to develop such a script if we can agree in advance to try it?

Apart from it being not possible to make such agreement - changes by me would be subject to open deliberation just like those from anyone else - i currently have a fairly long list of data processes to work on and this is not really something to jump the line here. This is something i would like to see so i will probably look at it when i have the time (and i don't know when that would be) but in general i think it is important that this style does not depend on techniques that can only be developed and maintained by a single person. So my previous encouragement for others to develop an interest in this field stands.

@Adamant36 - i won't get into yet another discussion on verifiability here because that would not lead us anywhere. I have discussed this on many occasions and am open to further discussions of this in an appropriate venue but should also add (without pointing in particular at you) that it is important for that to (a) familiarize yourself with previous discussion to not repeat the same arguments over and over again and (b) not use terms like "fuzzy" without having a reasonably stringent idea what you mean with them.

I have explained in depth - here and under the links provided above - why the way_area based rendering decisions for features rendered label only are in general highly problematic.

The reason why the more recent additions of such (bay, strait and cape) were merged without consensus was because at the time the changes were made this was not a requirement. There is no blame for doing so per se in stating this fact. It is though IMO a good example why a development models where maintainers can freely make design decisions completely independent of each other cannot work in the long term.

[jeisenbe]

Mappers are still being encouraged to add giant multipolygons or roughly drawn areas as natural=bay and natural=strait to get large gulfs to render as soon as z3:

z3

z4

It is very strange to show these "bays" at z4 when the larger seas are not rendered. Eg the Mediterranean Sea, Cora Sea & Arafura Sea, South China Sea and Arabian Sea are missing in the images above (z4).

I don't think any water area labels should be shown before z5, when the largest lakes are first labeled, unless seas are shown.

[imagico]

Note from a perspective of map design without taking the mapper feedback issues into account there is nothing wrong with labeling Baffin Bay (and Fram Strait possibly - those are the only two cases i would think there to be, hope no one gets any ideas for drawing another labeling polygon now) in a Mercator map at z2 or Drake Passage and Hudson Bay at z3.

As mentioned above already removing the labels from z2, z3 and possibly z4 would just partly hide the problem, it would not solve the counterproductive mapping incentives that needlessly absorb countless work hours of mappers that could much more productively be invested elsewhere.

[jeisenbe]

@kocio-pl - is there a compromise that you would be willing to consider about this issue?

The problem is that we don't label place=sea or place=ocean, which would otherwise shown at z2, so the natural=bay and natural=strait features look out of place. But we are not going to be able to reach consensus about rendering place=sea and place=ocean in the same way as the current bay/strait area rendering, which depends on way_area - instead someone needs to design a way to label oceans and seas at lower zoom levels based on nodes as well as areas.

So in the short-term, we need to fix this cartographic problem by not rendering bays and straits at zoom levels where seas should be shown. (Later, in the long-term, we could show large bays, straits and seas with the same code, if someone is able to develop it)

Would you be willing to have bays and straits only rendered from z10 when mapped as areas? That would be a reasonable limit, since it's where we end the name labels for many features, and most seas should render at z9, z8 or below based on my previous tests.

This would remove the incentive for mappers to add natural=bay tags to large seas (like Baffin Bay) and would remove the early, out-of-place labels for sea-sized gulfs, straits and bays (like Hudson Bay, Strait of Magellan, etc), but would not entirely remove way_area based rendering at mid-high and high zoom levels.

[kocio-pl]

I don't remember all the details now, unfortunately. However I probably wrote somewhere that the guiding principle should be to see the water label when still seeing the land, because of two things:

• I don't see how people are about to see them at all (other than searching through the waters, which seems unlikely)
• you seem to be trying to define what the sea/bay/lake really is, which I think is not the proper place to do that; that is a problem we have with Aral sea/lake for a long time (if it's a lake, the name would be visible quite early, if it's a sea, it would not be visible at all); I think we should just give feedback

Zoom level choice is secondary to that and as long as the whole water area can be seen with label, I consider it to be be good enough.

What do you think about that?

[jeisenbe]

you seem to be trying to define what the sea/bay/lake

On the contrary I think we should not push mappers to use one tag over the other. So we should not render only a certain tag at low zoom levels. Mappers should get the same rendering by tagging the Gulf of Mexico as a place=sea with a node or a natural=bay with a relation. They should not feel compelled to add natural=strait to the Irish Sea to get it to render.

Since we don't render place=sea yet, this is a problem when we show natural=bay and natural=strait labels at low zoom levels.

Also as mentioned above https://github.com/gravitystorm/openstreetmap-carto/issues/3634#issuecomment-469683712 - low zoom levels from z0 to z9 are only rendered once a month, so any mistakes take a long time to correct. Limiting the rendering to z10 and higher avoids this problem.

[kocio-pl]

Limiting the rendering to z10 and higher avoids this problem.

I gave you my guiding rule and said that zoom level is secondary, so I thought it's clear that I want to hear how does z(whatever) work with this rule, not how it relates to some other problems. Not because this is not interesting or important, but this way we can find faster the level that we can further discuss problems. Let's start with easy things, please. There is plenty of time to complicate them later.

Also pushing big objects below certain level is not the way to go for avoiding rendering problems - there were some country names and Lake Victoria shape (in the last days or weeks) being broken and they should still be there, exactly because they are big.

[kocio-pl]

The problem is that we don't label place=sea or place=ocean, which would otherwise shown at z2, so the natural=bay and natural=strait features look out of place.

We also don't do rendering of continent labels, but that does not make smaller land labels wrong.

Please check the scope of this ticket - this was to limit all natural places labels. This is just a general limit for now (until oceans and continents labels will get there, if ever). More strict limits for certain natural objects are possible and for current water labels it's what I agree, that we can push them even further (if they obey some basic rules).

[imagico]

Another thought based on what i wrote in https://github.com/gravitystorm/openstreetmap-carto/issues/2278#issuecomment-573598164 - it is worth considering to remove the rendering of labels on bay and strait polygons completely because meanwhile it can quite clearly be said that the name tag is no more consistently used on these. It has become a fairly wild mixture of compound label strings in different formats and non-verifiable choices of languages - largely due to our counterproductive influence. Semantic usefulness of this data is near zero.

[jeisenbe]

remove the rendering of labels on bay and strait polygons completely

So, only render the label for nodes (and linear ways)?

[imagico]

So, only render the label for nodes (and linear ways)?

I have not had a more detailed look at the node name data but probably it is all right so keeping them could be an option. But my point was more that (due to our counterproductive influence) bay and strait names tagged on polygons are no more mapped consistently and this is getting worse every day so the responsible thing to do would be stopping this rendering independent of the issue of the way_area logic discussed otherwise here.

If we can't find consensus on that removing all rendering of bay and strait names would be also acceptable IMO. That would not be desirable but better than further damaging the data due to our inability to find agreement.

[jeisenbe]

Someone just added this to the wiki page for natural=bay:

"* Large bays can be mapped as areas to to make the labels more prominent on the map"

https://wiki.openstreetmap.org/w/index.php?title=Tag%3Anatural%3Dbay&type=revision&diff=2055671&oldid=2053415

We are still encouraging mapping for the renderer by creating huge multipolygons.

[kocio-pl]

Since rendering information is included in multiple definitions I don't see it supports your point of view, and this is not a place for discussion about proper wording and formatting.

[jeisenbe]

The issue is that the wiki editor suggested this "to make the labels more prominent on the map”

“Mapping for the renderer” in this way is not a good practice

[kocio-pl]

Then again: why do you discuss the wiki wording here, not on the wiki page?

[imagico]

The edit on the wiki @jeisenbe points out represents yet another confirmation that mappers interpret the current rendering of bays and straits as an encouragement to draw labeling polygons for them to make the labels more prominent on the map. That is us steering mappers to do something against the spirit of the OpenStreetMap project.

What we are essentially doing here is abusing our influence on the mapper community to spare us the need to develop a suitable method for importance rating bays and straits that does not depend on mappers drawing non-verifiable labeling geometries. That there is no unanimous agreement among the maintainers of this style to stop doing that is embarrassing.

[kocio-pl]

I already presented the problems with nodes verifiability and the need of finding special method for working with this workaround shows how much worse it is for this goal. But let me repeat, that this is not a place for discussion about definitions, and wiki has a special space for this, which was not used this time.

[imagico]

The whataboutism of the alleged non-verifiability of node based mapping of bays and straits is something i have addressed on several occasions in the past. Be that as it may - i have also offered the solution of just removing all rendering of bays and straits for a start in https://github.com/gravitystorm/openstreetmap-carto/issues/3634#issuecomment-573631674 - this avoids the need to come to a consensus on if bays and straits mapped with nodes are something suitable for rendering here as a prerequisite for an agreement on the issue at hand.

[kocio-pl]

Not only you did not offered an explanaition for problems with nodes, but you have offered the most radical solution, which is completely deviating from what had been discussed here.

[kocio-pl]

Also please remember that you've been already warned about using judgment loaded words like "whataboutism", please consult Code of Conduct once again.

[imagico]

If you want to file a CoC complaint go ahead - but don't try to silence others criticizing you with perfectly valid arguments by threatening with the CoC.

[kocio-pl]

This is a reminder to keep away from unwelcomed behavior, not a threat (what consequence are you expecting?). If I remember this particular wording was mentioned by @jeisenbe, so this should be more neutral to you, I guess.