[talk-au] Sports Clubs

[Steve Bennett]

On Tue, Dec 15, 2009 at 9:34 AM, Roy Wallace <waldo000000 at gmail.com> wrote:
>> Because otherwise, the logic "if A and B and C then member_club" needs
>> to be encoded in each and every renderer.
>
> Ah, I understand your thinking now.
>
>> Now, I don't mind if you
>> want to tag the thing "A, B, C, member_club".
>
> Yes, I would prefer to do that.

Ok, it sounds like we have found some agreement.

"Where A, B and C are simple tags, and Z is a complex tag whose
meaning can be construed from the presence of A, B and C:
Preferred tagging: A, B, C, Z
Acceptable, but dispreferred shorthand: Z"


> 1) let say a user wants to find (or render) features that are, say, "A
> and B". This isn't easy to do if A and B aren't explicitly tagged, but
> only "A, B and C", or "A, not B and generally C", "C but with a gravel
> surface", "B except on Tuesdays unless tagged with X", "A and
> well-engineered for bicycles", etc.

Yes, but I think you ignore the tradeoff. It's like saying "I like
taking planes rather than trains, because they get me places quicker".
Well, yes, but they cost more. You want 10 different tags assigned for
one object because it's "more powerful". Well, yes, but it costs more.
More time and effort. That's less time and effort that could be spent
on other things. So it's a tradeoff.

Now, if you *want* to spend the time and effort on all that tagging,
you're very welcome. My personal preference is to tag thin and wide -
tag lots of things, but only one or two tags per thing. So obviously
to accommodate both of us, a tagging scheme like the one we appear to
have agreed on above, is needed.

> 2) the need for complex tag definitions in the wiki is lessened. I
> think this can help us avoid future footway/cycleway-type problems.

I'm not sure that's the cause of the problem, but I probably need to
do more research. I'm still unclear on whether anyone actually uses
the definition of "path" that is so painstakingly documented.

Steve