[OSM-dev] Super-relations or not

Frederik Ramm frederik at remote.org
Thu Oct 28 18:40:52 BST 2010


Peter Budny wrote:
> 1) The common way, up to now, for storing routes that alternate between
> single- and dual-carriageway has been to leave the single-carriageway
> parts without a role, or with the role "north/south".  This makes the 
> order of the members of the relation meaningless, since you
> can't traverse the ways end-to-end in the specified order.

There is no requirement for the order to have meaning; it is just a tool 
the server offers you, and you can use it or not.

The way I view route relations, it is less about traversal and more 
about simply stating that a certain way belongs to a certain route. The 
route relation doesn't lose its usefulness if a little bit in the middle 
is missing.

I would simply group all bits together in the route relation, including 
the dual carriageway pieces, and not worry about roles etc. - this can 
all be deducted from the oneway tags.

> This could be solved by adding the single-carriageway sections twice
> (once with "north" and once with "south")

Please no.

> 2) If the direction of a road (e.g. north/south) is indicated by roles,

I recommend not to do that.

> If anyone has a compelling argument against super-relations, or for
> single relations, I'd like to hear it.  Supporting both seems really
> pointless

No, supporting them both is quite probably the best way forward. You can 
start with doing a simple relation, and when you find that there's 
something more complex to it you can still use a super-relation.

I always preach that you should write your code such that wherever you 
expect a way, you also accept a relation that groups a number of ways. 
If that were done throughout, then a super-relation would just be a 
normal relation with one or two sub-relations thrown in as required. No 
need to go up the tree and demand that super-relations exclusively 
contain relations etc.


Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the dev mailing list