Talk:Relation

How to define a relation?

You pro-guys, please think of the beginners...! So, to start with, describe how you practically define a relation, say using potlatch, f.i. between two roads via a cross-point, to indicate a turn ban, like it is theoretically (!) defined in relation:restriction. it wouldn't be bad to create a ShowMeDo-video about that, if you can... Thanx a lot!

Just to give you an idea how the things look like for a beginner: you are in potlatch. If you are in the "simple"-mode (bottom, left), no way of possibly defining relations is shown. so you try - may be - "advanced". o.k.: now in the left column towards the bottom you see "relation", "id", "role" and you think: "ok, here I might enter the 'ordered list'... I might enter a way with the role 'from', a way with the role 'to', a point with the role 'via', the type=restriction and restriction=xyz" you double-click wanting to enter code, and you are being given a totally unordered list of "available relations"... you would need half an hour to sift through all the numbers to find the ID of the road to which you want to define a relation... (among the id's with values attached [after ":"] the related way, to which you want to define a relation, is not available... [e.g. from miethepfad in berlin to poleigrund].) no way of just entering code with the ID...

ok, you think: "try and define a 'new relation'..." you see a dialog: no tags set. please use the menu below... " ok, under "advanced" you find "turn restriction". you set a type ("straight on only"). ok. and how do I logically enter now from which road to which road via which point?? desperately I scroll down and I find: "advanced"... there I could define "relation", "id" and "role". but the same 'vicious cycle' restarts: "select relation! these ... are available..."

you see: no way of getting to work 'intuitively' or 'logically'... so you just give up... or you write here...

--BerlinerTourGuide 12:29, 5 October 2012 (BST)

Examples

How about some examples? Relations are not even named within the base dataypes, which are node, way and area only. Some examples could explain best how relations should be applied. --Traut 11:40, 16 January 2008 (UTC)

Data Primitives does mention relations. The relations linked to below (e.g., Relations/Multipolygon) may serve as examples, or were you looking for explicit XML code? Robx 12:19, 4 March 2008 (UTC)

I would also like to have more examples! could I see a for instance "an ordered list" as code?! or how would I encode a ban on a right turn in a relation between two roads?? thanx! --BerlinerTourGuide 11:59, 5 October 2012 (BST)

Some rather theoretical examples can be found in relation:restriction. --BerlinerTourGuide 12:31, 5 October 2012 (BST)

Previous attempts at drawing up a 'relations' concept

(moved from main page)

• Advanced relationships
• Relationships
• Proposed_features/Routing:_turn_restrictions.

GDF Alignment of relationships

Geographic Data Files (GDF) is a CEN/ISO standard primarily used for the description of transport infrastructure. Alignment of OSM concepts and/or terminology with GDF will help with professional adoption of OSM and may also allow us to learn from previous experience. Please also refer to GDF for a more general discussion of the OSM and GDF.

With regard to the above proposed relationships for OSM, in some cases we already use GDF modelling and terminology, in some our terminology that is different, in other cases our modelling is different as well. I will propose adjustments to align these better.

Bridges_and_Tunnels: GDF introduces the term 'Brunnel' as a shorthand for bridges_and_Tunnels. GDF specifically includes viaducts in their model.

Turn_Restrictions and Right_Of_Way: These are modeled as manoeuvres which can be prohibited, restricted, priority. The Ordnance Survey use include the concept of a mandatory manoeuvre in their ITN model which is useful. Note that in GDF the phrase 'restricted' is used for a turn which is physical difficultly to make as opposed to a turn that is legal difficulty (no right turn). I (PeterIto) recommend we adopt the GDF model and will propose a entry that covers both functions (Turn_Restriction and Right_Of_way).

• A restricted manoeuvre "is explicitly permitted by means of legal measures, as denoted by traffic signs", a prohibited manoeuvre "is physically possible but which is 'prohibited' by means of legal measures, as denoted by traffic signs" (cf. GDF standard). Both phrases are not used for physical, but legal restrictions. 'Restricted' represents it in a positive way (only this and that is allowed), 'prohibited' in a negative way (this and that is disallowed). For example, the traffic sign Turn Right denotes a restricted manoeuvre, No U Turn denotes a prohibited manouevre. --User:BerndR 26 Oct 2007
• Thank you BerndR, after I had written this I was puzzling over the descriptions in the standards. I was aware that I had not got it quite right and that my memory conflicted with what was in the document, but I am still not clear how to use the standard as written. How does one say 'It is not possible for a vehicle to turn here, in other words one that is legal but is not physically possible? I must say I find section 7.2.28.2 as clear as mud! Is it saying that at a junction you can use Prohibited manoeuvres to say what you can't do (for legal or network reasons) and use restricted manoeuvres for things that you can do (for legal or network reasons) and that you can use one of other approaches? User:PeterIto 29Oct07

Routes: The term Route is used in GDF specifically for public transport purposes, but fundmantally it defines an unambiguous route through the network using an ordered list of elements. The use of Route proposed for here for OSM seems like sensible extension of the GDF concept. We have a challenge in that members of our Route are not inherently ordered,h however a 'Start' tag solves that problem.

Collected Ways: these are what are termed Aggregated Ways in GDF.

• Personally I would recommend alligning with the the GDF term Aggregrated Ways, but am pretty relaxed about it really User:PeterIto 29Oct07

Dual Carriageways/Junctions: GDF uses a layered modeling approach which is very useful and I suggest we adopt. GDF Level 0 is to do with geometry and doesn't concern us here. GDF Level 1 is aligned closely to our basic OSM model of Ways and Junctions and requires no change. GDF Level 2 introduces a useful higher level description using the terms 'Road' and 'Intersection' for the concepts we referring to here as Dual_Carriageway and Junctions. For simple single carriageway parts of the network an Intersection (level 2) is associated automatically with a single Junction (Level 1) and a Road (Level 2) with a single Way (Level 1) however for motorways and dual carriageways then a Road can be formed of multiple Ways (normally two) and an Intersection can also be formed of multiple Ways. I [PeterIto] recommend that we use Road and Intersection for these relationships to make the levels clearer and to avoid confusion over when a Junction is a single node and when it is multiple nodes. Level 2 should form a complete unambiguous network of Intersection and Roads.

• I [BerndR] have replaced Peter's term 'Interchange' by the correct GDF term 'Intersection' in the paragraph above. Note that an GDF intersection object contains all the nodes and ways which are needed to represent a complete crossing. For example, a crossing between two multiple carriageways can be very complex with all junctions, ramps, and other connecting parts. A GDF road object contains all road elements between two GDF intersections. --User:BerndR 26 Oct 2007
• Thank you BerndR, that was pure dyslexia at work! Is there the general recommendation to use the GDF term Intersection for the relationship currently called Junction? and to use the GDF term 'Road' for what is currently called Dual Carriageways? User:PeterIto 29Oct07

Is_In: Fundamentally the same concept.

Rivers: not covered

Buildings: not covered

Composite Tag: Know as Composite Attributes in GDF.

• I (PeterIto) recommend we use Composite tag to stay consistent with the rest of the OSM model (also because by convention Tags are open-ended and Attibutes are not User:PeterIto 29Oct07

• I am not sure what is proposed here Mateusz Konieczny (talk) 12:34, 17 July 2018 (UTC)

How to print

how can I get a marked map of a relation (to print it out)? Like the one which is shown when I view the relation (27104 27104) but bigger. -- Schusch 10:21, 15 September 2008 (UTC)

Undo edit

How can i revert an edit of a relation to an older version of the historie? I can not find an option in potlatch or josm to do this. --Langläufer

Documented the solution here: Undoing_Deletions --Stephankn 19:59, 19 July 2009 (UTC)

Can we increase the warnings when an edit impacts or deletes an existing relation? "Warning! You are deleting a relation! Are you sure you want to proceed and delete this relation?" ("Do you understand what a relation is?")

The linked restore an edit instructions are limited. Can we increase the restoration capabilities so that the relation is restored as one connected unit (not unconnected segments); and with associated relationships to other relations restored; and with the type restored?

I know this may not be feasible but an increased Warning would be great! Thanks!--Peace2 (talk) 13:53, 18 May 2017 (UTC)

"Can we increase the warnings when an edit impacts or deletes an existing relation?" - you should propose it to author of editors (iD, JOSM, Vespucci...), not here. Mateusz Konieczny (talk) 12:36, 17 July 2018 (UTC)

Super/Metarelations

I have heard from users that they are using super/meta-relations that contain other relations. Only the superrelation has some tags and the member relations are meant to inherit those tags. I have not found this kind of relation use defined on this page, not even as a proposal.

I believe this is a problem. I can see how in some aspects clustering relations in superrelations helps to structure things. It makes a lot of sense e.g. for a network of single cycling routes which belong together. One relation per cycling route, one superrelation for the network. But when used arbitrarily without a concept, a common understanding and a clear definition, this can also lead to a lot of confusion.

To the best of my knowledge, there is no software that supports the concept. So to anybody thinking of normal relations as they are defined on this page, elements of a superrelation will appear to be standalone, or truncated and tags attached only to a superrelation will appear to be missing. This should lead to a lot of confusion and creation of duplicates. The same holds for renderers. They cannot evaluate superrelations, there is no defined inheritance and the relations structured this way will be crippled or not rendered at all. Another problem is with needlessly breaking up routes that can be expressed in a single relation into multiple ones. The breakpoints are arbitrary, any user might decide that a different place is better suited. The superrelation is not easily visible so the connection is lost to most people, editing and completing a route becomes much harder because what appears to be missing may be already part of another fragment that you need to find first. None of these problems exist when using a simple route relation.

I personally believe in keeping things practical and simple and avoid unnecessary complications. So I propose the following:

• Add some description on the meaningful and discouraged use of superrelations to this page
• Use relations of relations only when describing a defined network of routes or similar structure
• Break a route into several relations with a superrelation only if it is very long and the operator of the route has defined sections so there is a common agreement what the sections are. Add a tag with a hint to the relations that they belong to a larger system.
• Tag all relations with the minimum required tags so they work when used standalone, do not expect any inheritance of tags from superrelations.
• Never arbitrarily seperate a route relation that is described by the operator as a single, simple route.

--Nop 11:30, 13 January 2009 (UTC)

I disagree. Better request the use, inheritance and rendering of super-relations. Tagging has always been ahead of rendering and will always be. Don't propose to fill up the database with redundant keys and values that can easily be avoided by inheritance. --Lulu-Ann 15:25, 15 January 2009 (UTC)

I do not think this is practically possible. You cannot request rendering of something that is not even defined yet. And there is still the matter of confusing all mappers not familiar with the undefined and undocumented concept, thus creating contradictionary data. --Nop 15:33, 15 January 2009 (UTC)

I wrote use, inheritance and rendering. In that order. You can not request the rendering before the use. That's no news. Of course it is practically possible to propose all that in the correct order. No problems at all. --Lulu-Ann 14:58, 16 January 2009 (UTC)

If you mean "develop the concept first", I agree it is the proper order. But I would still advise against unnecessary complexity and I see practical problems. E.g. you have some superrelation, but the editor is not aware of that and does not open it automatically. So most users will likely create a new one, unable to see or retreive the existing stuff. Only very advanced users know how to find it using RelationAnalyzer or other tools and are willing to go through a complicated procedure to do so. Keeping things simple should work for a much wider number of people and I thought that was the intention of OSM. --Nop 16:32, 16 January 2009 (UTC)

I feel a need of super-relations or parent/child relation when working with rivers.

Idea: Make a map of a river basin

Example: http://www.openstreetmap.org/?relation=166216

I started to make relations for rivers using type=river - in the example it's Lena river with tributaries Vitim, Kirenga, Olyokma and Vilyuy and others. What I thought I could do is to create a parent relation (say type=river basin) and to only add child-relations for Lena and its tributaries. Unfortunately this didn't get rendered. Advantage would be that as the child relation are getting updated the parent will automatically get updated too - so Maintenance is really easy!. For now the above example contains all single river-ways of different rivers added manually for being able to get the relation being rendered correctly. In that way it has over 200 members. Using child relations I'd only add members for the child river basins...

Lena basin
 Vilyuy basin
  Chona basin
  ...
 Kirenga basin
  Minya basin
  Khanda basin
  ...
 Vitim basin
 Olyokma basin
 Aldan basin
 ...

with several nested parent-child relations... I do not know if this is technical makeable or too difficult to iterate to the different nested relation without complications or erros (imagine relation A being child of relation B being child of relation A again...!) --katpatuka 08:48, 7 July 2009 (UTC)

Relation naming scheme

Are relations supposed to use capital letters and underscores, or are they supposed to be case and space insensitive? Right now naming is all over the place, eg. Relations/Proposed/Is In has "Is_In", "Is In", "is_in"... Jpatokal 17:16, 17 March 2009 (UTC)

It seems to be problem of one specific proposal Mateusz Konieczny (talk) 12:35, 17 July 2018 (UTC)

Is splitting ways necessary?

With regard to hiking routes which go partly on paths and partly along roads, it's often the case that the route only goes on a small part of a way. I don't want to add the whole way to the relation, just the little bit. One solution is to split the way (twice) and just add the middle way to the relation. But that seems to be an unnecessary split of the way, which makes renaming the road for example a bit awkward. I'm not sure if it also introduces rendering artefacts if the renderer thinks that they're separate roads. Or maybe routing artefacts?

I assumed that in JOSM I could just select part of a way and assign the relation but it seems not to be the case. What's the "right" solution? Eric2 19:40, 22 March 2011 (UTC)

Yes, splitting is necessary. -- malenki 17:16, 11 April 2012 (BST)

Major rework and new articles

I am splitting this article into three separate ones for different functions. This article will be reduced to a tight definition of relations along the lines of other Data Primitives such as Node, Way and Tag. The rest of the content has been split between Using relations and Types of relation which seem to be very distinct subjects of there own. PeterIto 22:01, 9 January 2012 (UTC)

Names on relations and component ways

A conversation about the placement of names on relations and/or component ways took place in Jan 2013 on the tagging email list. See Jan 2013 archive. --Ceyockey 22:40, 6 January 2013 (UTC)