Sure, relations get you an additional degree of normalization. And using relations to carry route/network tags gets the job done, granted. But at what cost?
I've yet to hear a convincing argument that justifies the additional complexity of relations as they are being championed as carriers of route/network tags, nor have I heard why applying tags with highly-specific keys directly to ways is so fundamentally flawed that it warrants the added complexity of relations.
As if to prove my point, the whole reason this thread even exists (if my understanding is correct) is that those who are trying to import data from other GIS formats (Shapefiles) are being stymied by the fact that the tags-to-relations-to-ways model turns a non-trivial task into a head scratcher.
So, what this tells me is that, while insistence on a one-relation-per-logical-route methodology results in a normalized, one-to-many schema, it creates an artificial barrier for those seeking to add data to OSM. I, for one, will gladly accept the tradeoff of not being able to trumpet the fact that my dataset is "normalized" in return for lowering the barrier for others to enrich the map.
If I had my way, I'd tell these people to forget about relations and simply tag the ways that comprise the cycleways with tags like cycleway:oregon=3A, cycleway:oregon=9, cycleway:oregon=Sunset Ridge Trail, etc., and be done with it. (I have no clue whether those are legitimate route numbers/names for cycleways in Oregon; I'm just using them to illustrate a point.)
And, unlike the current situation of keys-that-aren't-really-keys, cycleway:oregon represents one concept, and one concept only: cycleways in Oregon. Unlike, say, a "ref" tag, you won't find it on cycleways in Ohio, or highways in Ottawa, or bus routes in Oslo, or oil pipelines in Oman. Want a map of the Oregon cycleway network? Hello OSM API, give me all the ways with tag.key==cycleway:oregon. Want to render the Oregon cycleway shield? Do so if the tag.key==cycleway:oregon and put the tag.value in the shield. No parsing...no additional DB JOINs...no collisions with other tags on the same way.
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
