Re: [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.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
>
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bridges redux

[Christopher Hoess]

On Mon, May 13, 2013 at 7:58 AM, Steve Bennett  wrote:

> On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst 
> wrote:
>
> > So for the tiny number of renderers/routers which want to show bridge
> types
> > differently - and my canal renderer will be one of them! -
> differentiating
> > based on a single bridge= tag is plenty easy enough. For the majority of
> > renderers/routers, "it's a bridge" will suffice.
>
> In this case, "movable" is such an obvious place to break the
> hierarchy down. It's very easy to imagine a non-specialist map would
> want to show movable bridges slightly differently. It's much harder to
> imagine many maps caring about the difference between bascules and
> drawbridges.
>

Agreed.


> Similarly, the bridge_type=* is a convenient place to get all the
> bridge nerdery out of the way of normal data consumers. (But I'd
> quibble: I'd promote "floating" and "culvert" as a fundamental kind of
> bridge, and demote "trestle" and "cantilever" as bridge_types).


Well, bridge_type or bridge:structure or whatever isn't *just* for
offloading technical detail of limited rendering value; it's also a
conflict-prevention measure. Demoting "cantilever" into that key, for
instance, makes it impossible to express both "cantilever" and "truss"
simultaneously, which presents a problem. Now, I've realized that
"bridge=covered" is actually superfluous to "bridge=yes; covered=yes"; if
that goes away, several of the values ("trestle", "viaduct", "movable",
"cantilever") sort of have a loose association in describing how the spans
are supported or mounted. So promoting "floating" up there would make sense
to me, but I wouldn't demote "cantilever" and I'm inclined to keep
"trestle" together with the nearly synonymous "viaduct".

Because it's almost always tagged on the lower, rather than the upper, way,
I'm inclined to drop "culvert" entirely barring a strong argument to keep
it.

-- 
Chris Hoess
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bridges redux

[Christopher Hoess]

On Wed, May 8, 2013 at 5:39 PM, Martin Koppenhoefer
wrote:

>
> I think we could also keep typology in bridge=* like we do for buildings,
> but if there was a majority for bridge:type I had no problem either.
>
>
>From comments so far, I think I'm happy to go with this for simplicity.

[...snipped...]

>
>
> Maybe we could also add some key to distinguish the kind of material of
> the structure, e.g. masonry, riveted steel, iron, wood, ...?
>
>
I'm holding on that for later. (There's a base_material key in the
Humanitarian Data Model that looks useful.)

I want to try to do this proposal /right/; thorough discussion on-list and
on-wiki, get it formally approved and changed on the wiki, and, with some
help, get patches out so that Mapnik, Potlach, and JOSM (and now iD, I
suppose) will parse the new scheme and support it in their presets.
Hopefully, in the long run, this means more stability for "bridge" and
related tags. However, it does mean I don't want to make it too big in
scope: the more issues I try to address, the harder it is for me to keep up
with all of them, and the more likely it is that the whole proposal will
get snagged on one contentious part. Once this proposal seems well along
towards completion, I'll probably go back and start drafting separate
proposals for structural material, bridge name, and maybe try to make sense
of the various values indicating that a bridge isn't usable.

-- 
Chris Hoess (choess)
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging