[Talk-us] Relations, cycle routes, shapefiles

[Peter Budny]

I'm sorry that you don't seem to see the value in using relations.

You are definitely correct... there are many ways to represent the same
set of data, with no loss of integrity.  Computer programmers often have
to make choices over how complex the data model should be.  Some very
large and efficient systems have been built with nothing but key-value
stores.  (Google and Amazon have both used this model for some of their
highly-distributed storage systems.)

This doesn't mean, though, that it's the right solution for everything.

A major advantage of using relations is that there is a single "entity"
which unambiguously represents a highway like US-26.  Without relations,
the only "representation" is a mathematical set of ways.

This causes a lot of problems, because there's no obvious place to put
information that belongs to the whole road, like the official_name.
Does it go on one way?  On all of them?  What if two ways have
official_name tags that don't match?  Even if your tags are correct, it
could cause users to have to look through a LOT of data to find a piece
of information.

This is the reason behind the common database concept of "normalization".
The idea is that you specify things in ONE place, and then reference the
data indirectly elsewhere.  Using key/value tags as you suggest is a
highly denormalized system, and would be a bad solution for the kind of
data OSM is trying to represent.

Relations are also easier for computers to parse, because it's very easy
to write a pattern that recognizes "type=route, route=road" and handles
it appropriately.  With keys, you have to perform text matching on the
keys, and this is a serious pain for programmers.  Any time you ask a
computer to interpret a string as being something other than a literal
bunch of characters, there is the possibility for things to get screwed
up.  Strings are the ultimate vehicle for hiding information.

~ Peter Budny

"Craig Hinners" <craig at hinnerspace.com> writes:

> 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
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us

-- 
Peter Budny  \
Georgia Tech  \
CS MS student  \