Changing RFC time for proposals including deprecation

General talk Tagging general discussion
10

Well, I’m uncomfortable with one important point missing here: despite of deprecation requiring efforts, how many items remain to be mapped with proposed tagging?

I mean, what do we get at spending time to make a plan, that probably won’t occur as expected, to retag 500k objects if 50 millions remain to be found?
Facts (taginfo) show that such proposals catalyze contribution a lot. It often increases usage 2 or 3 times more on proposed new tagging than on the deprecated one.
We tag 12x times more line_attachment=anchor than tower:type=anchor, starting from the deprecation of the last.

We replaced waterway=riverbank, landuse=farm… so how this can be a challenge anymore?

As we may deal with unifying tagging practices among many in use at the time of the proposal, consumers won’t be bothered by the change. They will continue to use existing tagging until it disappear from the database.

My 2cts.

11

True. It probably would we worth suggesting that proponent sends a reminder at least once again in the middle of RFC if there are not much comments, and additionally on any major change to the proposal.

12

Well if you were talking about 5 objects instead of 500k, that would totally make sense to just ignore. But 500k is extremely huge number, and even 5k is very very high. There are 500k of useful pieces of information that would stop being useful (and become database deadweight) if they were ignored instead planed for. Those are 500 thousands of edits translates into years of someones hard work that somebody just carelessly destroyed with a swipe of the mouse, because they didn’t feel like investing extra half of hour into making a minimum of effort to do a more useful proposal. That is way beyond selfish!

How would you feel if someone came and removed just 5k streets or shops from your country? I know I would be very angry. It wouldn’t matter to me one iota that millions of streets elsewhere are just fine (in fact, it would probably make me even more angry!) Now replace that spatial emotional attachment (e.g. “my country”) with any other attachment (e.g. “my hobby”). For example I like cyclotouring. If someone deleted (or in other ways made them useless in apps and websites) tons of cycleways worldwide, it wouldn’t make me feel better because “oh well, but all the roads for cars of which are there many more are still there, so it’s fine”. No, I would be even more outraged.

That is why one should not do half-assed proposals, but invest effort into them, if they propose to negatively affect work of all those who came before them.

13

Correlation does not imply causation. I would propose that it is more likely that strong leader emerged who incited more mapping of such feature, or that community using that tag has grown or had extra imports/organized mappings, or that the improved semantics allowed more things to be mapped, etc - than that the mere tag name change (which majority of users rarely if ever use directly, but instead often use presets in their local language in their editing apps) has caused the sudden surge of usage.

But regardless, note that there were effort to handle old keys there. Maybe you weren’t involved in it, but it was there. So, potential proponents must be made aware of that fact that the “renaming of OSM tags” is much much harder and more time consuming than “search & replace” in their favorite word processor, which many of them seem to naively assume.

We replaced waterway=riverbank, landuse=farm… so how this can be a challenge anymore?

Have we really replaced (past perfect tense) them, now?

We have surely started the process of replacing them, and after mere 3 years of work we have made a great progress, but there are still 4481 unfixed waterway=riverbank according to taginfo. Perhaps in several more years that effort will be completed, and those tags will really be replaced, but until such time, there is more fixing that is yet to be done to rectify damage that was done in the name of that “river modernization”.

But what is important is that this problem was considered, cost / benefit analyses was done and taken into account, and it was deemed that it will likely be worth it, and an effort has gone into proposing how to handle it in the best way. (and that is all that one would ask from new proposals!)

As we may deal with unifying tagging practices among many in use at the time of the proposal, consumers won’t be bothered by the change. They will continue to use existing tagging until it disappear from the database.

There are two types of data consumers: that which read data only, and those that write it too (AKA “Editors”. They both need to be upgraded, but possibly at different times (see especially bulletpoints 2 and 3 of this post).

1 Like
14

While there has always been the occasional proposal from well-meaning but inexperienced contributors, it seems like lately, we’ve seen a string of unpopular proposals from well-established, long-term contributors. Other than coincidence, I am at a loss to explain the recent trend.

15

But if you don’t count Norway, that drops to only ~130 worldwide! overpass turbo

1 Like
16

Interested tidbit! That actually makes it worse :cry: (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:

riverbank
riverbank1080×87 7.24 KB

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.

17

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
18

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.)

19

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
20

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!

21

I find this is usually due to one of the following reasons:

  1. The proposal is discussing a niche topic that many people are not interested in.
  2. 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
22

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
23

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.

24

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.

25

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
26

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.

27

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
28

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
29

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