Limit natural labels rendering to z4+ #3634
Comments
|
No amount of zoom level threshold tuning will solve this. I stated my position on this in #2700 (comment) This would mean removing way_area logic from all features that are rendered label only. That AFAIK is currently:
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. |
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). |
|
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). |
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 |
|
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). |
|
@imagico also wrote a blog about this recently. |
|
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. |
|
What i wrote about the wider topic is: https://www.openstreetmap.org/user/imagico/diary/47432 https://www.openstreetmap.org/user/imagico/diary/43957 http://blog.imagico.de/verifiability-and-the-wikipediarization-of-openstreetmap/ |
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. |
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. |
|
@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. |
|
"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. |
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 |
|
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. |
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. |
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: #3695 (comment). 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? |
|
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:
|
|
Another idea: Use areas from Wikidata; see new issue #3720 |
|
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 |
|
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:
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 |
|
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. |
|
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. |
|
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. |
|
@kocio-pl - is there a compromise that you would be willing to consider about this issue? The problem is that we don't label 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 |
|
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:
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? |
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 Since we don't render Also as mentioned above #3634 (comment) - 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. |
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. |
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
added
the
consensus needed
|
Another thought based on what i wrote in #2278 (comment) - 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. |
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. |
|
Someone just added this to the wiki page for "* Large bays can be mapped as areas to to make the labels more prominent on the map" We are still encouraging mapping for the renderer by creating huge multipolygons. |
|
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. |
|
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 |
|
Then again: why do you discuss the wiki wording here, not on the wiki page? |
|
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. |
|
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. |
|
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 #3634 (comment) - 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. |
|
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. |
|
Also please remember that you've been already warned about using judgment loaded words like "whataboutism", please consult Code of Conduct once again. |
|
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. |
|
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. |
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: #788 (comment)) 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
The text was updated successfully, but these errors were encountered: