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]
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
