[Tagging] Removal of "amenity" from OSM tagging

[Daniel Koć]

W dniu 18.05.2015 11:18, David Earl napisał(a):
> On Mon, 18 May 2015 at 00:40 pmailkeey . <pmailkeey at googlemail.com>
> wrote:
> 
>> Unfortunately change is inevitable and it happens to Microsoft and
>> Google customers.
> 
> Yes, of course. But they go to considerable lengths to provide upward
> compatibility, and when they can't, they provide a migration path and
> controlled change. But in any case this is just a gratuitous change
> with heavy costs for all the software. If you have an API, and this is
> part of one, then changing it randomly under people's feet so it
> breaks their products is a sure fire way of driving all but the most
> dedicated and masochistic customers away.

I don't remember anybody talking about "randomly" changing anything! 
Quite the reverse - we try to make system more consistent and clear. I, 
for one, care a lot for as smooth transition as possible.

If we make the change like:

amenity=pub -> pub=yes
shop=travel_agent -> travel_agent=yes
office=travel_agent -> travel_agent=yes

you can still make the translation for legacy services out there:

pub=yes -> amenity=pub
travel_agent=yes -> shop=travel_agent (or office=travel_agent)

Note that while the second case is not a 1:1 mapping, the whole point of 
transition was exactly dropping the information we can't be sure. More 
radical way is to just choose preferable legacy category, but we can 
make it less radical simply preserving some of the old cruft:

shop=travel_agent -> travel_agent=shop
office=travel_agent -> travel_agent=office

It would still be a clear improvement, because from now on we would tag 
only travel_agent=yes, so at least new contributions are free of legacy 
bloat.

-- 
"The train is always on time / The trick is to be ready to put your bags 
down" [A. Cohen]