[Tagging] man_made=works

Daniel Koć daniel at xn--ko-wla.pl
Mon Jun 1 15:46:02 UTC 2015


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]



More information about the Tagging mailing list