[RFC] Feature Proposal - landcover proposal V2

[02JanDal (Jan Dalheimer)]

@pnorman

It’s not the mappers who bear the cost of tagging changes, it’s data consumers. It’s very easy for mappers - they just update their editor, since most people don’t work with raw tags.

Most tagging changes so far involve tags not used by any data consumers or seldom used ones. Some tagging changes involve data consumers noticing flaws in the model.

With the features involved, virtually every rendered map using OSM data will be changed, many analytic uses, and pretty much every use I can think of except routing will be changed. And by changed, I mean broken in most cases.

I think this is important, but rather than just saying “we can’t do this sort of thing because of this”, it would be more productive to say “we need to take this into account”.

A good versioning (or migration, or whatever) process as suggested by @stevea would then be able to take such problems into account, hopefully solving them or at least making the problem smaller.

As an example of how this particular issue (data gets suddenly broken for data consumers) could be solved in a versioning/migration process:

1. New tagging scheme is accepted
   1. Objects get dual-tagged in both the old and new tagging scheme (preferable automatically by the editors, might in many cases be implemented just by adjusting the prefixes), QA tools warn of either tagging scheme missing
   2. New tagging scheme is applied to existing objects (either in automatic mass edits or over time)
2. Time passes (measured in years)
3. Old tagging scheme is officially deprecated
   1. Editors and QA tools warn of old tagging scheme being present
   2. Old tagging scheme is removed (either in automatic mass edits over time)

This would give data consumers time to adjust. As these issues often have already been present for a long time, migrating over a long time (3-6 years possible) should not be unreasonable. Do note that this is just one possible solution, which might or might not work together with any other requirements the versioning/migration process would have.

Just throwing a few other random ideas for solutions out here, not really part of the topic

• Providing planet dumps that are “normalized” according to a specific version, a new version would come every X years, and dumps for the last Y versions are available
• Provide “normalization” scripts in various languages so that each consumer can choose their target language which the rest of their system works with, without having to manually see what has changed over time
• Just let it play out, but disallow mass edits, so that consumers would start to see gradual changes over time, and hopefully adapt on their side
• Having official “version change days”, one every X years, on which all data is adjusted according to the new tagging scheme, and made very clear to all consumers that this will occur and on which days

---

This got a lot longer than intended, but my point is: We as a community have problems (such as tagging schemes that aren’t ideal), and it’s a lot better then if we actually try to solve them, rather than just vetoing any attempt to improve the situation.

That said, problems such as the one you’ve outlined are very important that they are mentioned (so that they can be taken into account), however, I think it would be a lot better if such posts had a tone of “great initiative, here’s a thing to consider” than “that’ll never work, stop trying to improve anything”.

It might in the end very well be that the end result is that no workable versioning scheme can be devised. But we should dismiss that possibility before trying.