-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
iD is forcing retaging from landuse=reservoir to natural=water+water=reservoir #6589
Comments
See #5591, where a discussion took place on this topic. The conclusion was that having a ton of different tags for water features makes it harder to use osm data, and that putting them all under |
Well, why is iD deciding which tags are "better"? Shouldn't OpenStreetMap community decide (by tagging, by numbers)? Me and many other mappers were not participating in #5591 as I do not use iD. I'm here just because now I have more work fixing such mistaggings made by iD. Removing such "advices" from iD would be much more friendly way of solving this than other options. |
What about the older tagging system for |
Yes, original scheme with landuse=basin, landuse=reservoir, waterway=riverbank is good - it allows us tagging everything we want. New scheme has no advantages just one major disadvantage - introduction of duplicate tagging and therefore corresponding havoc for both editors and consumers. There can be millions of arguments about semantics of keys and values and it will never lead to a consensus (this can be seen from numerous attempts to "solve" forest tagging, which has only led to introduction of even more new tags), so going into that I think is pointless. New water scheme is still less popular (according to tagwatch). Even with iD forcing users to use one way of tagging from the very beginning, while JOSM (most data is created with JOSM) allows both schemes. |
Here are the advantages I see: I agree with you about the disadvantage, but that's one of the things iD is trying to solve. iD didn't create this be tagging scheme, nor did it create the "havoc." It can, however, fix the "havoc" by gradually phasing out the old scheme. I think that one other very minor disadvantage with the new scheme is that two tags are needed, instead of one, but that shouldn't be too much of an issue. |
|
I tag a lot of water bodies and I'm mixed on this. To me the landuse tag is good for tagging the actual land that contains the water, but there should still natural=water tag for the actual body of water. Otherwise, it just seems like your splitting the streams up that go into and out of the water in a weird way and there's no way to add intermittent to it. I do think the landuse tag is useful for showing the landuse of the area though. So, I don't know 🤷♂ |
I do not see how it is "easier" to learn? It is possible to tag everything as natural=water WITHOUT adding water=*** (using original OpenStreetMap water scheme). Then people who map more, who know more would come and change it to whatever is better (maybe even having some equivalent to highway=road would be good but it is a different topic). And this is how it has worked from the very beginning and still works today, even with iD ;-) It is more consistent with iD, not with OpenStreetMap. That is a big difference. No it is not easier to use data when creating maps. landuse=basin has a very different usage and even different topology rules comparing to natural=water. Even landuse=reservoir has different usage. Same with waterway=riverbank. Well unless you're just skimming on cartography and do not care about scale, legibility etc. Regarding "fixing the havoc". By pushing the new scheme iD is actually helping to create a precedent to introduce other duplicate tagging schemes in the future, because this would show that it works. |
It is hard to describe using In this specific case, in my opinion Though it is apparently necessary to exclude |
However most people who map have a different opinion even with iD taking sides from the very beginning of its existence and not allowing original OpenStreetMap water tagging schema. (JOSM allows both schemas). Note that if iD would not be taking sides then fair solution would be for iD to allow using both schemes: original OpenStreetMap and the new one. I'm not asking for that. I'm asking for a minimum - stop pushing people to change tagging to the tagging preferred by iD, not by OpenStreetMap community. Old water tagging scheme is already used in a lot of places: maps/cartography rules, data analysis, QA etc. New scheme should have some very serious benefits to justify such a drastic change for such a widely-used tag (which would be almost equal to change of "highway" to something more semantically correct one). |
Is there some evidence that it is actually iD vs OSM community (like with some validator decisions that were rolled back)? I see no evidence at https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir or https://wiki.openstreetmap.org/wiki/Tag:water%3Dreservoir that one version is strictly preferred and usage count difference is not very large, around 200k vs 350k areas (landuse=reservoir has way more nodes, but I would consider rather as evidence against this tagging scheme). Note that it may be useful to compare actual usage, who and when added them rather than raw usage count.
That is because JOSM primary editing method is to input raw tag and in ID is to use presets. https://taghistory.raifer.tech/ is also indicating that most of a large lead of landuse=reservoir is result of a bot edit, likely an import. Also, since 2016 landuse=reservoir popularity among mappers suddenly decreased. Overall, I see no evidence of iD vs others, it looks like decision that could be reasonably taken in both directions. I am planning to request exactly the same deprecation rule in JOSM, if it is not present already once this issue is closed (assuming that no new evidence appears). EDIT: I opened "Propose to change landuse=reservoir to natural=water+water=reservoir" in JOSM, see https://josm.openstreetmap.de/ticket/17874 |
This is an endless problem. No tagging is 100% approved by the "OpenStreetMap community" because there is no centralised community and everyone disagrees with one another. The issue title is also exaggerated because nobody is being forced to do anything. Raw tag editor is available and other tools are available if people are not happy with what iD provides. It's true that old tag is widely used, it's currently got double the usage according to taginfo. However, relying on usage magnitude to drive tagging development is inherently biased toward whichever scheme came first (unless a special effort has been made to deprecate the tagging in which case it's biased toward the newer scheme). Worth mentioning I personally couldn't care which tagging is used at the end of the day. However, this is an infinitely repeating problem for the "OSM community" which carto and tool developers will have to deal with until community driven solutions are developed (if ever). I think it's fair (in the case that multiple schemes are in use and documented) for iD to have preferred tagging, the old tagging is still allowed and possible to use and they both mean the same thing anyway. |
By trying to "depreciate" such a prominent tag without giving a benefit iD would be destroying stability. For iD it is a minor change, but it would require a lot of work for data consumers: data analysis, data extracts, transformations, topology rules, cartography, documentation, training etc. There must be a very good reason to single handedly create so much work for so many people. |
@tomass For your information, iD is not inventing a new tag. This tag is already widely used! All data consumers that want to use this specific detail already need to support both of them! EDIT: I see no need to create a new comment to respond to argument below. All of them are applicable to case where this is a new tag. It is not applicable in situation where disputed tag has around 1/3 of usage ratio and is in use since a long time and has majority support among mappers within last years. All data consumers that want to use this specific detail already need to support both of them! "introduces havoc" especially deserves giant [citation needed] |
@matkoniecz iD is pushing a duplicate tag which introduces havoc, adds a lot of hard work for everybody and gives no benefit. Data consumers have successfully been using original OpenStreetMap water tagging scheme with waterway=riverbank,landuse=reservoir etc. from the very beginning of OpenStreetMap project! By doing so iD also diminishes trust in stability of OpenStreetMap tagging scheme: it is a very bad practice to change such prominent tags after so many years of usage without a benefit. |
Tomas,
It appears you disliked the original ‘water’ proposal and continue to seek some rolling back of these tags, despite many being in popular use for many years.
Things will continue to change, forever, as we all get better at identifying issues that require solving or modification. As I said in a previous post…. It’s the tagging scheme that needs a serious workover to ensure there are policies in place for creation, modification, acceptance and deprecation.
That will be of benefit to the entire OSM community….. if they could ever agree on it.
Cheers - Phil
|
This thread got long and heated so I'm just going to respond briefly to the primary points.
In sum, since there are multiple ways to tag reservoirs and iD can only support one, we use the scheme we think has the most benefits. You may disagree, but that's the nature of OSM. As @tastrax said:
I agree. We need better systems for managing the tagging scheme so iD isn't making these kind of decisions. |
@tomass Please knock it off. I'm going to just delete your comments if you continue the disrespect. |
iD is forcing users to retag reservoirs from landuse=reservoir to natural=water+water=reservoir.
landuse=reservoir is older and more widely used way to tag reservoirs. water=reservoir is newer and has no advantage over original OpenStreetMap way of tagging reservoirs.
Same thing with landuse=basin and natural=water+water=basin.
The text was updated successfully, but these errors were encountered: