[Tagging] Bridges redux

Steve Bennett stevagewp at gmail.com
Mon May 13 11:58:55 UTC 2013


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



More information about the Tagging mailing list