[Tagging] Bridges redux

[Christopher Hoess]

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.herring at 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 at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20130514/8b1c5c86/attachment.html>