W dniu 01.06.2015 14:18, Marc Gemis napisał(a):
The need to choose top-level tag for it is the problem itself.
What's a top level key ? Suppose you drop "shop". Then you get
bakery=yes. Is bakery now a top level key ? Is everything acceptable
as top level in this new schema ? Won't we have discussions on what is
acceptable as top level then ?
Good question, indeed!
In theory we have nothing like top level keys - "highway=service +
area=yes" may mean "service road, that has a known area border", but we
may also read it like "area=yes + highway=service" ("the area, which has
a property of being service road"). So far, so good, but in practice we
strongly depend on such namespaces like building, highway, shop, craft,
amenity - and try to stick with them as closely as possible. Not even
such notable examples as public_transport or Healthcare 2.0 really took
off.
It looks like we need a set of useful categories and don't like to loose
the known, legacy set. But I'm sure this set have to be better and not
that rigid. And I think it's possible to fulfill all those needs.
If we have bakery=shop (aka "shop=bakery" today), we can safely assume
it belongs to shop category.
And if we have more or less proper, dynamic category tree outside (in
metadata), we can assume that bakery=yes and all the other values except
"no" are also shop in fact. Nothing changes - the category is here to be
used. We don't really "drop" anything, we just move it somewhere else.
Now, you can accept it as top level or not, at your discretion. But you
will also have subcategory food_and_drink_shops, where the bakery is
really located - maybe it's more useful as a top level category for you?
We can treat old categories as a legacy - they will stay with us, but
will not be the hard requirement (in practice) anymore. You will
automatically know that health_specialty:dentistry=yes is amenity,
because it's categorized in health_amenities subcategory, so you loose
nothing; but at the same time you don't have to abuse amenity=*
namespace and you can choose health as your top level category.
Maybe we should "demand" that each tagging proposal includes a preset
for JOSM and iD, it might also increase acceptance and usage of new
tags.
I would be very happy with having common set of presets!
The external category tree is for nicely extending our objects base as
they grow (and they really do!), the presets are for easy using already
defined and agreed upon values. I hope wiki, map editors (I mean
software) and default rendering will make OSM more of a collaborative
environment than it is today. We could start with synchronizing JOSM and
iD presets, probably.
Why do you need to specify amenity = yes or tourism = yes ? What do I
learn from that ? Is this for the case that there are 2 reception
desks on a property (thinking about a campsite here), where one is
used by the tourist and the other for deliveries ?
You should not specify anything, unless you want to indicate that you
know it for sure - just like with plain old building=*.
If you don't know or you're unable to tell, better make it only
"reception_desk=yes". This way you won't silently spoil the data with
wild guessing. It's always better if you know exactly and collect as
many informations as possible, sure. But it's also better to know when
something is uncertain or just more general, than insist on adding
details at all cost - the cost being cutting some information, sneaking
the entropy into database (ever heard of Procrustean bed?) or losing the
input at all, as the mapper is unable to tell and abstains from adding
anything. We've just learned to not take these hidden costs into
account, because - well - they're hidden and we don't think a better
categorization is possible (or needed).
I still haven't figured out for myself whether top level keys bring a
lot of benefits. I suppose they do for building or shop (see e.g. SK53
latest diary entry on shop statistics, which won't be possible with a
top-level shop tag).
But does it help for things "amenity", leisure or tourism, which are
really collections of totally different things ? Would they be better
off without those top level tags ?
I know that some of them are better, and some other are worse. Building,
highway, area, water, shop, public_transport are nice. Amenity,
man_made, landuse, natural or leisure are not that clear.
But they don't need to be really top-level. Building is just useful
entity, however we could probably argue that it's kind of area and man
made at the same time. So let's put it under both categories then. It's
not top-level now (the only really top-level might be "object"), but
what's the problem? We can still use it as a basic structure for our
needs, as we do it now!
--
"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
