But if you don’t count Norway, that drops to only ~130 worldwide! overpass turbo
Interested tidbit! That actually makes it worse 
(even if it strengthens my points)!
i.e. if Norway is intentionally not wanting to change to new tagging schema (which seems possible reason, but I have not investigated at all, it might as well be just an mistake or coincidence), than we’ll probably never finish replacing waterway=riverbank with water=river, instead of it possibly being finished in several more years (in addition to initial 3 years which did most of the work) like current taghistory trend seem to indicate:
But that Norway is randomness which varies with the tag; if you take another example mentioned above, old landuse=farm which still has 6098 uses, and strongholds seem to be predominantly UK and west coast of USA. Regardless: if OSM purports to be a map of the world, it should not start excluding Norway, UK, California etc. from its definition.
Anyways, my main point was: Rome wasn’t built in a day, and neither was discussion about waterway=riverbank deprecation (and finally carrying out that idea to the conclusion) done in a day (or a month, or a year. In a decade - maybe). And IMHO, the same principle should be applied to other new proposals wanting to deprecate things: The more issues new proposals create by deprecating existing usages, the more effort needs to be put into them for addressing those issues.
It is not random.
When this issue was discussed with the Norway mapping community there was not a consensus for making the change. The specific issue is that at least one editor in the country was combining waterway=riverbank with intermittent=yes and natural=sand (or some other non-water value of natural=*.) in order to show intermittent water rendered on top of some other type of landuse. And since an object can’t be both natural=water and natural=sand, thus is the problem.
For an example of the effect this type of mapping is trying to achieve, take a look at some detailed land cover mapping I’ve done along the shores of Lake Powell as part of my Mappy Hour Presentation on river tagging.
4 Likes
Thanks for that bit of history! So I guess waterway=riverbank is here to stay, then?
Too bad that this usage wasn’t caught in proposal stage, or we’d likely be happily living with more versatile waterway=riverbank today without all the renaming fuss. Just goes to show how important it is to involve a lots different people and dedicate a lot of time into such big changes, as even with forethinking some issue might still slip through. (Now imagine how much more problems would that cause instead of just that one, if proponents were fans of “well why bother with all those checks and overthinking about potential damage, it’s just few hundred thousand elements, whatever” philosophy.)
(Aside: about the “random”; I didn’t mean to imply that relation between Norway and waterway=riverbank is random, but that random countries will be “old tag strongholds” for different tags; e.g. Norway for waterway=riverbank, but UK/California for landuse=farm, etc.)
Not really. The key conflict is a non-issue since the intermittant water area and the sand or rock can be mapped as two separate objects. For example: river area, rock area. Eventually the remaining waterway=riverbank areas in Norway will get changed to this style.
3 Likes
But what do you do when people don’t respond, or do but then stop?
As mentioned on the Tagging list: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum, I’ve been discussing making changes to the various existing lifeboat-station tags, which would mean setting emergency=lifeboat_station as the default, while deprecating the mainly duplicated options: [Tagging] Possible merge of marine_rescue & lifeboat_station tags? & Possible merge of marine_rescue & lifeboat_station tags?.
The last two questions I’ve asked haven’t had any response, apart from two likes on here.
Do I now just raise a proposal to change that tag from “in use” to “approved” & also mark the others as deprecated, or just think, “I asked, but nobody answered or complained, so they must be happy with the idea, so I’ll just go ahead & do it”?
Next step would be to go through the several 00 uses of the various tags worldwide & remove the duplicated tags that have been used on the same POI e.g. emergency=lifeboat_station + amenity=lifeboat_station.
Some of them are also tagged as emergency_service=water, which doesn’t even have a page created, but is in use 250+ times!
I find this is usually due to one of the following reasons:
- The proposal is discussing a niche topic that many people are not interested in.
- The proposal is poorly-written and people are not willing to put in the time and energy needed to fully develop it.
I tend to find that the best way to get useful feedback on a timely manner is to share the proposal on one of OSM’s many chat communities, which tend to result in faster response times.
Unfortunately, persuasive writing is a fairly challenging skill to get right and there is no obvious feedback when you’re missing the mark beyond a lack of engagement and negative responses when the proposal goes up for a vote. If the topic is niche, then there is often not a need to go through a proposal at all - just document the usage under the principle of “any tags you like”.
5 Likes
I still don’t believe that more time would bring more answers. A reminder after a week or similar would make more sense.
Much more important is: I would start somewhere completely different. We finally need a reasonable deprecation process. Maybe it will be somewhere around a year or two and take all stakeholders with it. But a “cleaning up” of the database should not be prevented any further.
Incl. broader participation, e.g. when we finally get away from the mailing list. Less “nerdy” people are simply deterred from it. Also one must ask oneself as a community whether we “consensus” with our Tagging recommendations in controversial questions Tagging A or Tagging B not with 75+% but halt simple majority to decide let. But then also prepared accordingly.
2 Likes
I’m not sure it is possible to get a deprecation process that can support a large-scale deprecation process, enjoys broad participation, and has a lower threshold for “consensus”.
Deprecation is inherently disruptive as it requires data consumers to change the way they use the data. We don’t have any control over how or when consumers choose to do that, but we must keep in mind that consumers will have some maximum capacity for changes in a given period. Deprecation needs to take some time if we want to keep data consumers happy and up to date.
Increasing participation in these discussions is a good thing, but as more people join the conversation it will take longer and longer to reconcile different points of view. More participation will increase the amount of potential issues identified with proposals, and it will take more time, not less, to resolve them.
Lowering the threshold for consensus will resolve some of the difficulties with increased participation, but will compromise the legitimacy of the entire process. The proposal process operates essentially “by consent”, and a highly polarised proposal that passes with 51% will lead some to ignore the process entirely.
By analogy to the Project management triangle - the cost (effort by data consumers to transition) is fixed, and the scope (of proposals) is fixed. The only way we can increase quality is by allowing more time.
By your writing, shouldn’t deprecation of little used, non-standard, or non-adopted ones have a more relaxed requirement?
Requiring a thorough analysis of their existing usage might be too much, when a problem statement could do. But it should be reasonable to ask proposers to check and list out what visibly used public applications are using them.
I wouldn’t describe it as a “relaxed” requirement, but it might be easier to put together a comprehensive proposal that meets requirements that other tags.
Although if noone is using the tag, is there any reason to officially “deprecate” it at all?
1 Like
But that is precisely the point why we really need a process. And I think that in the end we don’t need more time for a proposal, but for the transition process. But then you also have to define this process correctly. Especially with a project that has this scope, we really have to consider whether the database should be structured a bit more and “official” tags introduced, precisely because there is this mishmash. Just so that you don’t always have this hiccup.
I searched around again and brought the old proposal for a sensible deprecation process here. Unfortunately, it was abandoned at the beginning of the year. Not everything made sense with this one either. But if you only look at the intended process…
But this is where I would like to step in. After all, according to project management, the proposal process is first of all the start of a project, in which the scope is defined.
And if we then use the project triangle, the costs are, as you said, the effort of the data consumers, but the scope is the deprecation itself. And that’s why we have to extend the duration until a deprecation is complete.
note that it is also viable to establish ongoing bot edit to retag new tags as they appear in a given area (if local community is sure that some specific tagging can be autimatically amended/retagged)
I have some ongoing bot edits doing exactly this.
1 Like
That is useful additional info to know what is possible under “automated edits”. Although I at least would prefer a solution where deprecated tags stop being created.
But if it is impossible to totally eradicate such new usages of deprecated tags, such bots might be an option (as you say, in areas where local community approved that) in same cases (e.g. when there is simple one-to-one renaming - it obviously won’t work if old deprecated tag is unclear; e.g. might be interpreted to mean different things for which different tags exist).
1 Like
We have a process already, and it works just fine. That process is the Automated Edits Code of Conduct which of course we’re all aware of. And that’s exactly what I used to guide me when conducting the river modernization project, in which the community replaced, by way of automated edits, a tag which had been deprecated in a proposal, with support from the local communities involved.
The underlying subtext that I am hearing is that we would like it to be easier than what I just described to make mass edits after a tag is deprecated in a proposal.
2 Likes
This process must be able to do much more. It has to take the relevant stakeholders with it. So editors and data users. It must provide an information platform (e.g. by informing them directly). There must be a defined procedure depending on the “Automated Edits Code of Conduct” for a) first double tagging (if possible) and then b) after a transition phase, phasing out the old tag.
In my view, deprecating is a process that can make use of automatic edits, which are then sub-processes, but must still represent other functions.
1 Like
This project wasn’t starting from scratch. There was never a serious risk of rivers vanishing from renderers after retagging, because natural=water enjoys better support (this being an argument in favor of the retagging). The retagging didn’t affect other use cases such as routing or geocoding. The analysis use case was also largely unaffected, as global queries had had to account for both tags for some time.
In other words, this was the best-case scenario. Unfortunately, many desired deprecations start out at a disadvantage because the migration path for data consumers is not as straightforward.
1 Like
Sorry to disappoint but this change did affect geocoding. It is a stellar example of something that might have looked like a bit of a simple cleanup but in reality was a structural change to the tagging that can suddenly pose quite a huge problem on the software side.
Here is the problem: we’ve had this double tagging of rivers with waterway=river/stream + waterway=riverbank. Often both were tagged with a name. This needs some deduplication for geocoding purposes. Nominatim did this by simply ignoring waterway=riverbank. After all, the river line is the more interesting result and ignoring a tag is easy enough. Then @ZeLonewolf came along and changed the tagging from a simple waterway=riverbank to natural=water+water=river. What was previously a primary feature now became an attribute to another tag. The way the tag processing works in Nominatim there is no way to filter by such an attribute, so deduplication of rivers has been broken since this particular mass edit because fixing it requires a change in the design of the software.
Please don’t discuss now the peculiars of how to implement secondary tag filtering. It’s not really the point. The point is that any changes to existing tagging may have an affect on data consumers that you don’t have foreseen. So if you want to have deprecation and ‘tagging cleanup’ in a major way, you have to devise a plan that gets feedback from data consumers already during the RFC phase. I consider any proposal doomed that cannot show that considerable thought has gone into the secondary effects that the change might have.
7 Likes
I stand corrected on this point, and am glad that we agree that deprecation is not normally as simple as it seems on the surface.
It is not double-tagging, they are entirely separate features. One is the path of the river, and the other is the water-covered area of the river.
Tagging a name on a river area is always incorrect tagging. If Nominatim is indexing names on waterway=riverbank or natural=water + water=river, then that behavior is simply incorrect, and has been incorrect for over a decade.
False, both tagging systems were widely in use at the time I became involved, sometimes just one, sometimes just the other, and sometimes both. If Nominatim was failing to correctly handle the former but not the latter style tagging, then it was already failing to properly handle a significant percentage of the river area objects tagged worldwide when I became involved.
If this effort further exposed an issue with Nominatim that was already widely present, I would consider that a positive outcome.
6 Likes