[Tagging] Pet supplies store but doesn't sell animals

Serge Wroclawski emacsen at gmail.com
Sun Jun 12 05:04:34 BST 2011


On Sat, Jun 11, 2011 at 10:31 PM, John Smith <deltafoxtrot256 at 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



More information about the Tagging mailing list