[OSM-talk] Advanced relationships

[Frederik Ramm]

Hi,

> The more I use OpenStreetMap, the more I think it needs an Advanced
> Relationships feature 

Yes. I don't know about Musicbrainz ,and your suggestion is just one of 
a multitude of possible ways to do it, but in one way or another we will 
need relationships.

Relationships *between objects* I'd like to say, because I do not know 
whether we will still have nodes and ways and segment by the time this 
idea becomes implemented, but yes, some sort of relationships.

A brief mention of relationships in GDF, the data model that TeleAtlas 
and NavTeq are based on, is here (with pointers to more):

http://wiki.openstreetmap.org/index.php/GDF

Jochen and I have also discussed the lack of relationships and their 
possbible uses in our data model paper (which we haven't worked on after 
the Essen workshop because we were under the impression that it wasn't 
the right time for these ideas or, to put it more cynically, OSM is not 
yet broken enough to realize the necessity of a proper model) - see 
http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf, 
chapter 2.1.

When we implement relationships, some existing things will change - e.g. 
we will not have "is_in=textual_name" any more, but we will have a 
relationship. The same for routes - we will just have a "is part of 
route" relationship and then there will be objects representing the 
route itself. (This will require the creation of objects without 
geographical representation of their own, e.g. an object named "London" 
which does not have any segments or nodes, but is just a "partner" for 
relationships.)

Your example of turn restrictions is also an important one, and we will 
probably also have some "belongs to" relationships that will help 
modelling things like the "scout camp" previously discussed here.

> There would need to be extensions to the api to fetch relationships
> from/to things, and the bbox query would return extra data containing
> all the relationships that have one or other end inside the area that is
> being fetched. 

Yes, and the paramount thing is that the API must at all times make sure 
that relationships are not broken, i.e. no dangling links. Of course 
this should be caught by editors (e.g. they must forbid the deletion of 
an object that is referenced by a relationship), but the API must also 
have a last line of defense here.

I would like to caution against implementing relationships as a "quick 
fix". Changes in renderers, API, and editors will be required, and we 
owe it to all the developers and mappers involved to find a way to model 
relationships that will really work (and not one that does the 50% most 
important cases and leaves the rest out in the rain).

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'