GIS
› OpenStreetMap
› General
›
Tagging
Bridges redux
Locked
 
|
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 |
|
|
2013/5/8 Christopher Hoess <[hidden email]>
I've started revising my bridge tagging proposal thank you for reviving this. Bridge details are really a problem right now. I'm in favor of placing the "structure" 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 |
|
|
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 |
|
|
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).I'm not absolutely set either way; since you bring it up, I'd like to hear other people weigh in as well. -- On Thu, May 9, 2013 at 10:35 AM, Richard Fairhurst <[hidden email]> wrote: This is generally good. One comment: _______________________________________________ Tagging mailing list [hidden email] http://lists.openstreetmap.org/listinfo/tagging |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
2013/5/10 Richard Fairhurst <[hidden email]> OSM's most valuable resource is mappers. We should therefore optimise +1 _______________________________________________ Tagging mailing list [hidden email] http://lists.openstreetmap.org/listinfo/tagging |
|
|
On Friday, May 10, 2013, Martin Vonwald wrote:
+1
_______________________________________________ Tagging mailing list [hidden email] http://lists.openstreetmap.org/listinfo/tagging |
|
|
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 |
|
|
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 |
|
|
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 -- 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 |
|
|
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. -- On Thu, May 9, 2013 at 6:09 PM, Malcolm Herring <[hidden email]> wrote:
_______________________________________________ Tagging mailing list [hidden email] http://lists.openstreetmap.org/listinfo/tagging |
|
|
In reply to this post by Steve Bennett-3
On Mon, May 13, 2013 at 7:58 AM, Steve Bennett <[hidden email]> wrote:
Agreed. Similarly, the bridge_type=* is a convenient place to get all the 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 |
|
|
In reply to this post by dieterdreist
On Wed, May 8, 2013 at 5:39 PM, Martin Koppenhoefer <[hidden email]> wrote:
From comments so far, I think I'm happy to go with this for simplicity. [...snipped...]
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 |
|
|
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 |
|
|
In reply to this post by John F. Eldredge
On Mon, May 13, 2013 at 11:42 AM, John F. Eldredge <[hidden email]> wrote:
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 |
«
Return to Tagging
|
1 view|%1 views
| Free forum by Nabble | Edit this page |