[Tagging] Bridges redux
John F. Eldredge
john at jfeldredge.com
Mon May 13 18:42:57 UTC 2013
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 <stevagewp at gmail.com> wrote:
> On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst
> <richard at systemed.net> 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.
> > 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
> > boats) and one routing project (for bikes). Even coping with paths,
> the most
> > complex tagging scheme that we have, is really easy with the
> > combination; just 20 lines of code sorts out the complexities of
> > bicycle=, designation=, highway=, tracktype=, and surface= into the
> > 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! -
> > 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
> 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).
> Tagging mailing list
> Tagging at openstreetmap.org
John F. Eldredge -- john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging