To speak to Malcolm's point, there is a "default" rendering strategy for unknown bridge tags. Unfortunately, because there's an ill-defined group of values used to indicate that a bridge is closed, damaged, gone, etc., the default rendering is not to render an undefined "bridge" value as a bridge. Looking at Mapnik's osm.xml, there appears to be a "whitelist" of accepted values that will get rendered as a bridge: "yes,true,1,viaduct". Since, in practice, mappers are unlikely to use a tag that has a disruptive or unexpected rendering, any new value is going to have to be coded into that whitelist before it gets much practical use. Movable bridges are a fairly eclectic lot, with a lot of oddball solutions to the problem of clearing the channel; rather than try to stuff a completely comprehensive list into "bridge=*", I still think it makes sense to use "bridge=movable" to indicate them and push the detailed information, which is unlikely to affect rendering or routing, into "bridge:movable=*". I see the situation as being analogous to "highway=service; service=*", which allows us to render service roads more or less uniformly without having to specify an exhaustive list of possible types.
I appreciate Richard's point that the tools available on the programming side aren't your grandfather's regexp, but I was basically considering the "whitelist" problem I discussed above, which as far as I can see isn't really soluble by sophisticated parsing alone. From a human interface point of view, even with "bridge:movable" and "bridge:type" thrown into the mix, this proposal is still a set of fairly concrete (no pun intended) key-value pairs. I don't feel that using this syntax would be a terrible hurdle for typical mappers, particularly when compared to some of the more abstract relations, conditional syntax, and so on. I'm trying to strike a balance between several goals: easy and intuitive tagging so mappers mostly "get it right", a rich, expressive vocabulary so mappers don't have to choose between conflicting tags, and some amount of flexibility and modularity, so that extending our tagging beyond what's now proposed will still more or less work with programs that implement the proposal. -- Chris Hoess (choess) On Thu, May 9, 2013 at 6:09 PM, Malcolm Herring < malcolm.herr...@btinternet.com> wrote: > On 09/05/2013 21:41, Christopher Hoess wrote: > >> I'm not absolutely set either way; since you bring it up, I'd like to >> hear other people weigh in as well. >> >> > As a renderer developer, I see no problems with Richard's simplification. > Renderers should always have a default for unrecognized types, since these > are frequent, owing to typos and mappers inventing their own. My view is > that the simpler the tagging scheme is, the better. > > > > ______________________________**_________________ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging> >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
