Frederik Ramm wrote:
> Without commenting on the rest of the discussion: Surely you (the
> renderer) must draw such an object as if there were no bicycle tag at
> all, whatever that means for you.
But that doesn't work, does it?
Say I'm a general purpose renderer who shows access. I understand
bicycle="no" and bicycle="yes", and show them accordingly. Now, instead
of someone coming along with a new tag for their info, they extend
bicycle and do "bicycle=difficult". My code hits it. If I've defensively
programmed my code, it'll do one of:
if (bicycle=yes) {
Do A
}
else {
Do B
}
or, alternatively,
if (bicycle=no) {
Do B
}
else {
Do A
}
Which should I have done? That's the question I'm saying that anyone who
wants to extend a formerly binary tag with new values needs to provide
an answer to before they start using the new values.
Say I assume "bicycle=no" for unknown values, as you suggest. That means
that bicycle-accessible bits, formerly rendered on my map, would
suddenly drop off entirely because someone decided to get more specific.
So in this case, an assumption of "yes" might make more sense. But it
might not in every case.
My point is that (leaving aside the specific bicycle example) extending
already-used tags in this way is going to result in confused renderers
and undefined and renderer-specific behaviour.
Gerv
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
