On Sat, Jun 11, 2011 at 10:31 PM, John Smith <deltafoxtrot...@gmail.com> wrote:
>> The logical conclusion is: >> >> shop=pets >> animals:cats=yes >> animals:reptiles=gecko;snakes >> supplies:cat_food=dry;canned >> supplies:fish=block;flakes;filters;nets >> supplies:fish:treasure_chest=no >> ... > > I don't see a problem with this except to prove your point you made > things excessively specific, but I don't see a problem with more > general forms, how is this any different than tagging the types of > fuel sold at amenity=fuel? I'll elaborate on why this is a bad idea: 1. It's a lot of tags 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. 2. It won't get used in real life 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. 3. It's nested 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. 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 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. 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 _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
