What are you going to do when the route is part of more than one state highway 
or bike route? You can't do a db query for ref:highway:ca:0, ref:highway:ca:1, 
ref:highway:ca:n without doing expensive string comparisons, and you can't 
explode a delimited list of refs without breaking the one key = one value 
relation.

No relations = no way to normalize one-to-many. At least without a lot of extra 
work on the part of the parser and API tools.

Yes it can be done, but then we'll end up with the kind of horrific data layout 
your average shapefile has.

- Daniel

On Feb 4, 2011, at 8:53 PM, Craig Hinners wrote:

> The only thing that relations add (in terms of tagging) is an order of 
> magnitude of complexity.
> 
> There is no technical reason why direct application of tags to ways can't 
> work. However, this requires the use of highly-specific tag keys, such as a 
> unique key for interstate highways, a unique key for U.S. highways, a unique 
> key for [insert your state here] highways, a unique key for [insert your 
> state here] bikeways, etc.
> 
> For whatever reason, though, the de-facto practice became cramming everything 
> under the sun into the values of tags having non-unique keys, such as ref, to 
> the point where said tags mean everything while at the same time mean nothing.
> 
> The concept of key/value pairs is common in computing, where the key 
> describes a unique concept in the dataset: interstate, U.S. hwy., etc. 
> However, now that ref has taken on thousands of different meanings depending 
> on context, it can hardly be considered a "key" any more, to where it has 
> zero utility outside of rendering (i.e., displaying its value in a "shield"). 
> Which is quite ironic, if you think about it, given how we're constantly 
> berated to "not tag for the renderer".
> 
> Hence the reason why everything breaks down when, god forbid, there is a way 
> that belongs to two classes of networks (say, interstate and U.S. hwy.), 
> because you now have to somehow convey multiple concepts in a single tag 
> (ref). Which is why the operative workaround is to resort to another layer of 
> abstraction (and complexity) in the form of highly-specific relations, when 
> everything could have been taken care of in the first place with 
> directly-applied tags having conceptually-unique keys.
> _______________________________________________
> 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

Reply via email to