Bridges redux

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Bridges redux

Christopher Hoess
Greetings to the list,

I've started revising my bridge tagging proposal
<http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types>
based on the comments received in the last go-round in January. There
are three specific questions I'd like some feedback on before I submit
a full RFC again.

As preface, I should note that I feel it is important to create at
least one key in addition to "bridge". Trying to fit all of the
proposed values in one key will inevitably lead to conflicts: how do
we represent a beam bridge that is also covered? A viaduct that is
also an arch bridge? a cantilever made of truss spans? The "railway"
key has problems caused by the all-in-one approach: how do you
represent a disused narrow-gauge heritage railway? I'm not going to
float a bridge proposal that sets us up for similar problems.

That said, the first of my questions is "How should we divide these
values among keys"? My proposal basically follows the dichotomy Martin
Koppenhoefer laid out here
<http://lists.openstreetmap.org/pipermail/tagging/2012-January/009162.html>:
one set of tags for "typology" (originally proposed by me under
"bridge"), and one set for "structure" (originally proposed by me
under "bridge_type"). I'm in favor of placing the "structure"
classifications under "bridge:structure" to make it clear what's being
classified; there are about 550 occurrences of "bridge_type" at
present, most of which can go to "bridge:structure". The bigger
question is whether the "typological" values (covered bridges,
viaducts, trestle) should stay under "bridge" or move to a
"bridge:type" key. The main disadvantage of this move is that there
are a large number of existing "bridge=viaduct" instances (about
27,000). The advantage of putting typology under "bridge:type" is that
it reduces the number of types a renderer or downstream consumer has
to be aware of. All ways tagged with "bridge=yes; bridge:type=..."
would be rendered properly as bridges without changes to the current
renderers, as would future additions or removals of types. If we
consider this, we might also consider whether "movable" should be
under "bridge" or "bridge:type". Placing it in the former would mean
patching current renderers (e.g., Mapnik), but placing it in the
latter makes specific movable bridge types (e.g., bascule, swing)
rather wordy to tag, with three separate keys.

At present, I tend to favor placing the typology under "bridge:type"
except for "bridge=movable" but I would like further opinions and
discussion.

My second question is whether culverts should be included in this
proposal. I included values for culverts in the "structure"
classification to maintain compatibility with the Humanitarian Data
Model <http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Model>,
but tagging culverts on the overhead way (rather than the way that
passes through them) is a very small minority tagging style. JaakkoH,
who's active in Haiti work, suggested dropping it, and I'm inclined to
follow his advice.

My third question is what to do about the "drawbridge" value for the
proposed "bridge:movable" key. NE2 pointed out that this is something
of an attractive nuisance; people tend to use "drawbridge" when they
really mean "bascule". Should we drop this value from the proposal
because of the potential for misuse? Is there another name that can be
applied to those bridges?

Your comment on these three points is much appreciated. Once I feel
like I have a sense of the community's position, I'll revise the
proposal page and put it up for RFC again.

Yours,

--
Chris Hoess (choess)

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

dieterdreist



2013/5/8 Christopher Hoess <[hidden email]>
I've started revising my bridge tagging proposal
<http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_types>
based on the comments received in the last go-round in January. There
are three specific questions I'd like some feedback on before I submit
a full RFC again.


thank you for reviving this. Bridge details are really a problem right now. 
 
 
 I'm in favor of placing the "structure"
classifications under "bridge:structure" to make it clear what's being
classified; there are about 550 occurrences of "bridge_type" at
present, most of which can go to "bridge:structure". The bigger
question is whether the "typological" values (covered bridges,
viaducts, trestle) should stay under "bridge" or move to a
"bridge:type" key.


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.


>My second question is whether culverts should be included in this
>proposal.
 >I included values for culverts in the "structure"
>classification to maintain compatibility with the Humanitarian Data
>Model <http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Model>,
>but tagging culverts on the overhead way (rather than the way that
>passes through them) is a very small minority tagging style. JaakkoH,
>who's active in Haiti work, suggested dropping it, and I'm inclined to
>follow his advice.


+1, I'd drop culverts from the bridge tagging, they are underneath


Maybe we could also add some key to distinguish the kind of material of the structure, e.g. masonry, riveted steel, iron, wood, ...?

cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Richard Fairhurst
In reply to this post by Christopher Hoess
This is generally good. One comment:

Christopher Hoess wrote:
> [...] we might also consider whether "movable"
> should be under "bridge" or "bridge:type". Placing it in the
> former would mean patching current renderers (e.g.,
> Mapnik), but placing it in the latter makes specific movable
> bridge types (e.g., bascule, swing) rather wordy to tag, with
> three separate keys.

It makes more sense to replace:

bridge=movable; bridge:movable=swing
bridge=movable; bridge:movable=lift
bridge=movable; bridge:movable=bascule
bridge=movable; bridge:movable=drawbridge
bridge=movable; bridge:movable=transporter

with simply

bridge=swing
bridge=lift
bridge=bascule
bridge=drawbridge
bridge=transporter

This removes unnecessary duplication, is more memorable ("is it 'moveable' or 'movable'...?") and accords with current usage (e.g. 577 occurrences of bridge=swing).

cheers
Richard

Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Christopher Hoess
Richard,

I included the types of movable bridge in the "bridge" key in the previous round of my proposal in January, for similar reasons (compatibility, brevity). I made the change based on LM_1's comments (<http://lists.openstreetmap.org/pipermail/tagging/2012-January/009163.html> and reiterated on the wiki).

Specifically, what made me switch was thinking about renderers, routers, and other consumers of the data. The list of movable bridge types is rather volatile: it's easy to imagine someone coming up with additional types besides the ones I've listed for movable bridges. If all the movable bridge types are filed under "bridge", adding a new type will not work with downstream consumers until they've been patched (which seems to be a fairly serious obstacle). Using "bridge=movable" with "bridge:movable" is a little more wordy, but it allows renderers to render it as a bridge and routers to recognize that it might open in the middle of the commute, even if it's some exotic type of movable bridge not provided for here.

577 instances isn't that big an installed base, all things considered (and they don't even render properly, right now). "movable" vs "moveable" is annoying, but they shouldn't build up too badly as long as someone is regularly sweeping taginfo for the misspelling.

I'm not absolutely set either way; since you bring it up, I'd like to hear other people weigh in as well.

Yours,

--
Chris Hoess




On Thu, May 9, 2013 at 10:35 AM, Richard Fairhurst <[hidden email]> wrote:
This is generally good. One comment:

Christopher Hoess wrote:
> [...] we might also consider whether "movable"
> should be under "bridge" or "bridge:type". Placing it in the
> former would mean patching current renderers (e.g.,
> Mapnik), but placing it in the latter makes specific movable
> bridge types (e.g., bascule, swing) rather wordy to tag, with
> three separate keys.

It makes more sense to replace:

bridge=movable; bridge:movable=swing
bridge=movable; bridge:movable=lift
bridge=movable; bridge:movable=bascule
bridge=movable; bridge:movable=drawbridge
bridge=movable; bridge:movable=transporter

with simply

bridge=swing
bridge=lift
bridge=bascule
bridge=drawbridge
bridge=transporter

This removes unnecessary duplication, is more memorable ("is it 'moveable'
or 'movable'...?") and accords with current usage (e.g. 577 occurrences of
bridge=swing).

cheers
Richard





--
View this message in context: http://gis.19327.n5.nabble.com/Bridges-redux-tp5760227p5760348.html
Sent from the Tagging mailing list archive at Nabble.com.

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Malcolm Herring
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
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

dies38061
In reply to this post by Christopher Hoess
There are advantages and disadvantages to this.  The advantage is, as you point out, you reduce information duplication; there is also the designation of a limited controlled vocabulary which is used as a primary facet.  The disadvantage is that the classification of these values as movable is lost from the primary data, meaning that the information relate to all being movable must be sourced from elsewhere. --ceyockey

>It makes more sense to replace:
>
>bridge=movable; bridge:movable=swing
>bridge=movable; bridge:movable=lift
>bridge=movable; bridge:movable=bascule
>bridge=movable; bridge:movable=drawbridge
>bridge=movable; bridge:movable=transporter
>
>with simply
>
>bridge=swing
>bridge=lift
>bridge=bascule
>bridge=drawbridge
>bridge=transporter
>


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Richard Fairhurst
In reply to this post by Christopher Hoess
Christopher Hoess wrote:
> Specifically, what made me switch was thinking about renderers,
> routers, and other consumers of the data.

OSM's most valuable resource is mappers. We should therefore optimise tagging schemes for ease of mapping.

I don't think non-programmers realise how easy it actually is to cope with tag variations, especially now that our tools are so sophisticated. For renderers, the standard is osm2pgsql+Mapnik/Tilemill: Carto makes it easy to assemble tagging rules, and osm2pgsql has (just!) got lua-based tag transformations. For routers, the standard is OSRM, and that too has lua-based tag transformations.

I'm currently working on two rendering projects (one for bikes, one for boats) and one routing project (for bikes). Even coping with paths, the most complex tagging scheme that we have, is really easy with the lua+Carto combination; just 20 lines of code sorts out the complexities of access=, bicycle=, designation=, highway=, tracktype=, and surface= into the three rendering categories I want.

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.

The simplicity and reduced burden for mappers wins out, as indeed it should always do. And I'm looking forward to people tagging more swing bridges and lift bridges so I can make a nice canal map. :)

cheers
Richard

Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Martin Vonwald (Imagic)
2013/5/10 Richard Fairhurst <[hidden email]>
OSM's most valuable resource is mappers. We should therefore optimise
tagging schemes for ease of mapping.

+1


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Brad Neuhauser


On Friday, May 10, 2013, Martin Vonwald wrote:
2013/5/10 Richard Fairhurst <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;richard@systemed.net&#39;);" target="_blank">richard@...>
OSM's most valuable resource is mappers. We should therefore optimise
tagging schemes for ease of mapping.

+1

+1 

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Chris Hill-6
In reply to this post by Richard Fairhurst
On 10/05/13 11:24, Richard Fairhurst wrote:
> Christopher Hoess wrote:
>> Specifically, what made me switch was thinking about renderers,
>> routers, and other consumers of the data.
> OSM's most valuable resource is mappers. We should therefore optimise
> tagging schemes for ease of mapping.
+1
>
> I don't think non-programmers realise how easy it actually is to cope with
> tag variations, especially now that our tools are so sophisticated.
>
+1

--
Cheers, Chris
user: chillly


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Steve Bennett-3
In reply to this post by Richard Fairhurst
On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst <[hidden email]> wrote:
> I don't think non-programmers realise how easy it actually is to cope with
> tag variations, especially now that our tools are so sophisticated. For
> renderers, the standard is osm2pgsql+Mapnik/Tilemill: Carto makes it easy to
> assemble tagging rules, and osm2pgsql has (just!) got lua-based tag
> transformations. For routers, the standard is OSRM, and that too has
> lua-based tag transformations.

Ok, I disagree. I'm a programmer, I'm pretty familiar with  most of
the tags, and I think the overhead in handling the immense variety of
tags is a huge burden. It's a major learning curve for anyone trying
to create a new generalist style, and is something we should be trying
to reduce, not increase. Maybe one day there will be standardised web
services (or Lua libraries) that condense these arrays of tags into
something simpler - but I don't think it exists yet.

The easier we make consuming OSM, the better maps, apps and general
penetration we get. Optimising for data contributors makes sense - but
should be done through editors like iD, not through messy, unwieldy
tagging systems.

> I'm currently working on two rendering projects (one for bikes, one for
> boats) and one routing project (for bikes). Even coping with paths, the most
> complex tagging scheme that we have, is really easy with the lua+Carto
> combination; just 20 lines of code sorts out the complexities of access=,
> bicycle=, designation=, highway=, tracktype=, and surface= into the three
> rendering categories I want.

And you bear almost no resemblance to a typical OSM data consumer.
(Which I mean as a compliment.)

> 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.

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).

Steve

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

John F. Eldredge
I am also a programmer, and agree that it would make sense to have a movable tag with a value of yes or no, in addition to the finer-grained bridge=<type> tag. If we were dealing with a database with all bridge types required to be in a lookup table, then it would make sense to have the bridge type table determine whether or not the bridge was movable. However, since we are dealing with a database where users can add new bridge types at any time, or may not know which technical term to use for the bridge type, having a separate movable=yes tag makes more sense.


Steve Bennett <[hidden email]> wrote:
On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst <[hidden email]> wrote:
I don't think non-programmers realise how easy it actually is to cope with
tag variations, especially now that our tools are so sophisticated. For
renderers, the standard is osm2pgsql+Mapnik/Tilemill: Carto makes it easy to
assemble tagging rules, and osm2pgsql has (just!) got lua-based tag
transformations. For routers, the standard is OSRM, and that too has
lua-based tag transformations.

Ok, I disagree. I'm a programmer, I'm pretty familiar with most of
the tags, and I think the overhead in handling the immense variety of
tags is a huge burden. It's a major learning curve for anyone trying
to create a new generalist style, and is something we should be trying
to reduce, not increase. Maybe one day there will be standardised web
services (or Lua libraries) that condense these arrays of tags into
something simpler - but I don't think it exists yet.

The easier we make consuming OSM, the better maps, apps and general
penetration we get. Optimising for data contributors makes sense - but
should be done through editors like iD, not through messy, unwieldy
tagging systems.

I'm currently working on two rendering projects (one for bikes, one for
boats) and one routing project (for bikes). Even coping with paths, the most
complex tagging scheme that we have, is really easy with the lua+Carto
combination; just 20 lines of code sorts out the complexities of access=,
bicycle=, designation=, highway=, tracktype=, and surface= into the three
rendering categories I want.

And you bear almost no resemblance to a typical OSM data consumer.
(Which I mean as a compliment.)

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.

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).

Steve



Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging

--
John F. Eldredge -- [hidden email]
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria
_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Christopher Hoess
In reply to this post by Malcolm Herring
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 <[hidden email]> 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
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Christopher Hoess
In reply to this post by Steve Bennett-3



On Mon, May 13, 2013 at 7:58 AM, Steve Bennett <[hidden email]> wrote:
On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst <[hidden email]> 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
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Christopher Hoess
In reply to this post by dieterdreist



On Wed, May 8, 2013 at 5:39 PM, Martin Koppenhoefer <[hidden email]> 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
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

Steve Bennett-3
In reply to this post by Christopher Hoess
On Wed, May 15, 2013 at 7:34 AM, Christopher Hoess <[hidden email]> wrote:
> 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,

I might be mistaken, but I don't think this is quite true. A "covered
bridge" is a very particular kind of historical structure. You
wouldn't call a modern bridge where the footway happened to be
sheltered from the elements a "covered bridge". Anyway.

> 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.

Yeah I thought so too, but if you look closer, the description here is
very specifically of a type of bridge which is part culvert, part
bridge. That is, a kind of brick structure which both has a tunnel for
water to pass through, and directly supports the roadway. (Why we
would want to specifically tag such a thing I'm less clear on...)

Steve

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Bridges redux

brycenesbitt
In reply to this post by John F. Eldredge


On Mon, May 13, 2013 at 11:42 AM, John F. Eldredge <[hidden email]> wrote:
I am also a programmer, and agree that it would make sense to have a movable tag with a value of yes or no, in addition to the finer-grained bridge=<type> tag. If we were dealing with a database with all bridge types required to be in a lookup table, then it would make sense to have the bridge type table determine whether or not the bridge was movable. However, since we are dealing with a database where users can add new bridge types at any time, or may not know which technical term to use for the bridge type, having a separate movable=yes tag makes more sense.

Complexities everywhere!  A pretty darn common type of bridge is a movable bridge that does not move.
e.g. a former bascule or swing bridge that is now fixed open or closed.  Or put another way: something people will expect
to see as a drawbridge in rendering, but should not be movable for routing purposes.

_______________________________________________
Tagging mailing list
[hidden email]
http://lists.openstreetmap.org/listinfo/tagging