dieterdreist at gmail.com
Mon Jun 1 11:51:48 UTC 2015
2015-06-01 11:51 GMT+02:00 Daniel Koć <daniel at koć.pl>:
> You _have_ to decide whether it's a shop=travel_agency or
no, you don't have to, you can also use both tags if you think they should
> Also look at the reception_desk "classification" problem. Some want to
>> classify it as amenity, others as a tourism feature. That just depends
>> on your needs. There isn't always a classification that works for
> But we're just mentally caged in a "*=reception_desk schema", so you still
> have to be sure what class is this object. In my view you could tag it only
> "reception_desk=yes" if you don't know or care for classification, but
> you're still able to make it "reception_desk=tourism" for example, if
> that's what you're sure about.
having few keys and many values has a certain advantage in certain database
systems, turning this the other way round will not let you gain much but
will have negative implications for those systems. Plus you loose the
generic "classes" that might be useful for finding tags or for filtering
(e.g. "all shops in this area" is harder or impossible if the scheme goes:
grocery=yes / shop).
And what about presets? Will there be two of them?
If we want to have consistent tagging and details, simple "presets" the way
we have them now will not be sufficient. We should better have a guided
scenario (aka "wizard") that asks the mapper some questions and in the end
proposes the tags to set or states that there aren't yet tags for this kind
of thing. This would also decourage people from using similar but not
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging