On Feb 5, 2011, at 7:14 AM, Craig Hinners wrote: > 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.
Shapefiles are a lowest common denominator interchange format, not something we should strive to have our database equivalent to. If you want to express the cycleway network as a shapefile your best bet would be to use overlapping geometries, one for each relation. That's the way the database that renders the slippymap works, but it's not a good enough representation to do shields properly. If your trying to get this data into general purpose GIS software, you could use a PostGIS or SpatiaLite database as your backend instead of shapefiles. I don't have experience with the Arc tools, but all the open source GIS software will allow you to generate layers from an SQL query, which should allow you to display relations. > 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. This example still can't handle ways that are part of more than one route (e.g. situations like the I-580, I-80 overlap are actually fairly common). > _______________________________________________ > Talk-us mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
