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 <stevag...@gmail.com> wrote:
> On Fri, May 10, 2013 at 8:24 PM, Richard Fairhurst
> <rich...@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.
> 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
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
--
John F. Eldredge -- j...@jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to
think at all." -- Hypatia of Alexandria
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
