[Tagging] Shop vs amenity

[Daniel Koć]

W dniu 24.08.2015 14:11, Warin napisał(a):

> So I do both ends of the scale ... benches in parks and gardens,
> rubbish bins .. and upto city wide areas. Both have their appeal. The
> detail is most usefull for people that are there, the larger stuff for
> planning.

This what I've experienced trying micromapping too. I also try see the 
need to mark larger stuff to put the smaller objects into the context.

>  I'd rather say ...  leave "amenity" for things that are not shops,
> buildings nor landuse.

What if amenity takes the whole building? Landuse=school for area + 
building=school is enough or we still should add amenity=school for the 
building?

>  There have been changes in the past ...
>  transport 'routes' have changed .. as have power distribution things
> ...

I feel the context is rapidly changing and we can no more rely on what 
was in the past.

Once OSM was a small London-based project, now it's gaining popularity 
worldwide, is quite strong in Europe and some big players are involved ( 
http://www.reuters.com/article/2015/07/30/telenav-toyota-scout-idUSnPn7d9hjT+81+PRN20150730 
). This makes any changes much harder now and I'm sure it will be even 
more like that in the future.

It's harder to make any consensus just because there is much more people 
to contact with. For example see the suggested highway color shift - it 
was not made in the closet, Mateusz was writing about it in his diary, 
on the mailing lists and discussed a lot on the GitHub, yet some people 
are surprised and angry because they felt like not being warned. We also 
had big discussion about voting on features which had no real effects or 
conclusions. And this is just internal communication!

There are also some examples of well thought and even accepted tagging 
schemes which are not in a wider use, like:
- highway:area (4 years before it really took off now!)
- public_transport=* (still less popular than highway=bus_stop alone)
- health 2.0 (still just "proposed" after 4 years) or even healthcare=* 
(approved 5 years ago, yet less than 10k uses)

For me it means we have serious problems with bigger changes and it 
won't be any easier if we have no more effective procedures.

>  shop= needs work too .... some shops sell more than one category of
> things. And some mappers want to have more detail. I'm thinking about
> it. Just another on the list!

I guess the ultimate solution would be allowing to have more than one 
value for given key (shop=feature1 + shop=feature2), possibly even 
allowing pairs to be numbered, and maybe even having trees instead of a 
flat k=v namespace, but it's purely technical thing (different kind of 
database) and it would be definitely the biggest single change we ever 
had to deal with!

>  Note
>  There have been no objectors so far ... these will come.

I'm eager to hear them too!

I want the system to be coherent, but there are many ways it can be done 
and objections to one of them may be perfectly legit. I just hope at the 
end of the day we can choose "the least imperfect" solution, because as 
I've just wrote, everything has some downsides - even "smooth" gradual 
changes (being bound to old cruft for a long time and waiting for the 
critical mass forever).

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