Super-relation

Definition

Relation that contains other relations. R. initially have been created to contain nodes, ways or areas and combinations thereof.

Usage

Nested relations as those hierarchic structures made of super- and sub-relations are also called, are virtually undocumented and neither frequently used nor rendered. Exceptions are:

• Routes, especially national and international cycling and hiking routes, should be rendered by Lonvia
• Routes, general? by the OSM_Route_Manager
• boundaries, used by Boundaries.pl

Merging super-relations of routes

An example to illustrate a possible algorithm of processing super-relations of routes, that is, merging them to a somehow flat hierarchy, depending on the particular purpose:

Finding a way to distinguish nested relations

Relation A Eurovelo6
  name=Riverway
  ref=EV6
  member Way 51 some way
    highway=cycleway
v
Relation B Dutch part of Eurovelo6.
  name=Riverway
  ref=EV6
    member Way 56

Merge? possible. Sub-relations with same or no relevant tags have no additional information. Member way 56 can be treated like way 51.

Relation A Eurovelo6
  name=Riverway
  ref=EV6
  member Way 51
v
Relation X Greek part of Eurovelo6 that is also used by Eurovelo12.
  no tags
  member Way 58

Merge? possible. Same. Member way 58 can be treated like way 51.

Relation A Eurovelo6
  name=Riverway
  ref=EV6
  member Way 51
v
Relation B Spanish part of Eurovelo6. 
  name=Riverway
  ref=EV6
  wikipedia=es:EV6_in_España
  member Way 57

Merge? information lost or missinterpreted. Sub-relation has an additional tag valid in the subrelation only. Copying the way members to both relation gives 2 EV6 cycleways in Spain where there is just one. Merging them drops or missinterprets the wikipedia tag.

Relation A Eurovelo6
  name=Riverway
  ref=EV6
  member Way 51
v
Relation B German part of EV6 is actually D6.
  name=Danubway
  ref=D6
  member Way 72

Merge with Relation 11? information lost. Sub-relation holds information about a different cycleway. Merging the relation to the parent would drop the D6 cycleway, and just keep it as EV6, so copying the way members to both relations is an alternative for further processing, as well as leaving the structure might be.

I wouldn't draw a conclusion from this, I just want to point out that deciding if the relations in a super-relation construction belong together or not, that is, should live seperately or not, is important. If you are just interested in the ways corresponding to wikipedia-tags then the wikipedia tags make the difference, in contrast to comparing all tags like the name and ref tags in this example. Is the wikipedia tag in the sub-relation the same than in the parent or is it missing in the sub relation then merge, is it different divide. And for completeness, would the tag be missing in the parent relation, then the parent wouldn't be examined.

The hiking and cycling map Lonvia obviously uses the network tag to distuingish between parent and child relations that match or those that are different from each other, the later are differently labelled then.[1]

Consolidation of nested relations

Now assuming a method for distinguishing is found then lets say matching relations are called with the same capital, like A.

Relation A W1 v Relation A W2

=>

Relation A W1, W2

Ways or other content of two of the same kind can be merged, as stated above. Usually the parent relation has no or few way members, but you never know.

Relation A W1 v Relation B W2

=>

Relation A W1, W2

Relation B W2

Different are split like above.

Relation A W1 v v Relation A Relation A W2 W3	=>	Relation A W1, W2 v Relation A W3	=>	Relation A W1, W2, W3
		Relation A Relation A W1, W2 W3	=> *	Relation A W1, W2, W3

Both transformations possible, the * indicating simple relation consolidation, no more hierarchy here.

Relation A W1 : v : Relation B : W2 v v Relation C W3

=>

Relation A W1, W2, W3

Relation B W2, W3

Relation C W3

That extra connection from A to C is superficious, but common (acceptable) practice. More practice in Wikipedia category tree [2].

Relation A W1 : v : Relation X : W6 v v Relation C W3

=>

Relation A W1, W6, W3

Relation C W3

X has no relevant tags and gets dropped, but not its ways.

Relation A W1 ^ v Relation C <··· Relation B W3 W2

=>

Relation A W1

Relation B W2

Relation C W3

A closed loop isn't valid, drop connections of different participants.

Relation A W1 ^ v Relation C <··· Relation A W3 W2

=>

Relation A W1, W2 ^ v Relation C W3

=>

Relation A W1, W2

Relation C W3

A closed loop still isn't valid but the matching participants can be merged before the connections are dropped.

Algorithm

Todo

See also

• Pros and cons of nested route relations: Relation:route#Creating_super-relations_for_routes