Re: [Tagging] Bridges redux

2013-06-07 Thread Bryce Nesbitt
On Mon, May 13, 2013 at 11:42 AM, John F. Eldredge 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= tag. If we were dealing with a database with all bridge types > required to be in a l

Re: [Tagging] Bridges redux

2013-05-19 Thread Steve Bennett
On Wed, May 15, 2013 at 7:34 AM, Christopher Hoess 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 actua

Re: [Tagging] Bridges redux

2013-05-14 Thread 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.

Re: [Tagging] Bridges redux

2013-05-14 Thread 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

Re: [Tagging] Bridges redux

2013-05-14 Thread 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.

Re: [Tagging] Bridges redux

2013-05-13 Thread 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= 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 t

Re: [Tagging] Bridges redux

2013-05-13 Thread Steve Bennett
On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst 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

Re: [Tagging] Bridges redux

2013-05-10 Thread Chris Hill
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

Re: [Tagging] Bridges redux

2013-05-10 Thread Brad Neuhauser
On Friday, May 10, 2013, Martin Vonwald wrote: > 2013/5/10 Richard Fairhurst 'cvml', 'rich...@systemed.net');>> > >> OSM's most valuable resource is mappers. We should therefore optimise >> tagging schemes for ease of mapping. >> > > +1 > > +1 ___ Taggi

Re: [Tagging] Bridges redux

2013-05-10 Thread Martin Vonwald
2013/5/10 Richard Fairhurst > OSM's most valuable resource is mappers. We should therefore optimise > tagging schemes for ease of mapping. > +1 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bridges redux

2013-05-10 Thread Richard Fairhurst
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 actu

Re: [Tagging] Bridges redux

2013-05-09 Thread dies38061
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 l

Re: [Tagging] Bridges redux

2013-05-09 Thread 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, sin

Re: [Tagging] Bridges redux

2013-05-09 Thread 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

Re: [Tagging] Bridges redux

2013-05-09 Thread Richard Fairhurst
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 > b

Re: [Tagging] Bridges redux

2013-05-08 Thread Martin Koppenhoefer
2013/5/8 Christopher Hoess > > I've started revising my bridge tagging proposal > > 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

[Tagging] Bridges redux

2013-05-08 Thread Christopher Hoess
Greetings to the list, I've started revising my bridge tagging proposal 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.