What about this tagging schema: shop=pet_supplies for shops that don't sell pets shop=pets for shops that do sell pets, and if you want to go in detail, you can tag it animals=fish;dog;cat;horse;whale (or in the plural form if you like to)
While you can give it the same amount of detail, it has some advantages: 2011/6/12 Serge Wroclawski <emac...@gmail.com> > > I'll elaborate on why this is a bad idea: > > 1. It's a lot of tags > > Not anymore, it's one or two tags, depending on how specific you want to be > The problem with over specificity is that in my experience, it scares > mappers off. > > We want users to come in and be able to map quickly and easily; but > what we see from a subset of our community is the desire to design > complex hierarchies of tags. These tags intimidate users. > If a user does not want to edit the animals list, he doesn't have to. It's only one tag extra. > > 2. It won't get used in real life > Maybe not, but if someone likes to use it, he can. > > The second problem with these complex scheme is that the tagging list > is an entity unto itself. People on this list love specificity, they > love the idea of mapping in extreme depth. The problem is that it's > rare that these tags get used. The original mapper uses them, maybe a > few others, but overall they're just noise in the data, but appear > prominently in the documentation. See #1. > It won't appear prominently, only in the description of the tag "shop=pets". > > 3. It's nested > Not entirely nested any more, you don't have the ':' structure. > > In the Python programming world, there's a saying "Flat is better than > nested."- I feel the same applies to tags. In this example the > question was "Can we distinguish between pet shops that sell animals > and those who don't." > > My suggestion was that the term is ambiguous, but if you wanted to > make them less ambiguous, you could distinguish a pet supply store by > simply having a tag: > > shop=pet_supplies > > That's simple, easy, elegant, and solves the problem. > > if you wanted to have an animals=yes tag, I'd /almost/ be okay with that. > I don't like *feature=yes* tags, if you have a feature key, the value can be used to describe it, putting "yes" is kinda useless IMHO. > > But when you start getting into these nests and subnests, I think this > is an exercise in complexity and futility. > > 4. It's apt to change > > The value can change (like any value) but the keys won't change. > animals:fish = yes is you listing a store's inventory. > > It would be the same as > > store=clothing > men:bowties=yes > > Inventory changes, and this leads to increasingly bizare tagging of > individual items. > > After all, why stop at "fish" > > animals:fish:neon_tetras=yes > animals:fish:angel_fish=no > > ? > > 5. It's outside the reasonable scope of the project. > Maybe, but if someone wants to map it, he can. > > There's value in knowing what store carries what product, but it's not > OSM's job to do that tracking. > > In some cases we bend the rules a bit, as you mention in your fuel > example, or as I sometimes do with cuisine= on a restaurant. That's > why I'm okay with the distinction between pets and pet supplies, but > where I'm not okay with listing individual items of the inventory any > more than I would be if we had: > > cuisine=thai > menu:pad_see_ew=yes > menu:pineapple_fried_rice=no > > We should be striving for simplicity wherever we can. > > - Serge > > Please tell me what you think about it. Regards, Sander
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
