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