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
