Questions about OpenStreetMap basic elements

Exactly. Just collecting together separate elements.

I like your term “construction nodes”, it shows understanding that the geometry of lines has to be defined somehow after all, and that is by giving some positions (latitude/longitude) where it passes along. Those positions are called nodes and get an id-number.

Uh, no. A way made up of nodes is still just a way, not a relation. Because ALL of the nodes listed in a way are its construction nodes, regardless if some of them may carry additional tags (traffic lights, bus stop, etc.) A way must pass over ALL its nodes, otherwise they would simply not be contained in this way’s definition.
That doesn’t mean that construction nodes could not at the same time also be bus stops etc. It’s not either-or, instead just multiple functions for such a node.

Just to clarify, that also doesn’t mean that it wouldn’t be possible to list both, the way and one of its special nodes together in a relation too. It just means, if you want a relation, it must be created manually, like everything else too. Relations also allow to collect together ways and nodes that are not connected in the same position, like, let’s say, info boards a few steps sideways of some hiking trail.

If they are contained in the definition of a way, they are its construction nodes.
If additionally they may be contained in some relation, that can be seen e.g. at the bottom of their page at Just look at hadw’s nice example page again:
Editors show it too, somehow somewhere, each one has its own methods.

Of course, if you add nodes as single elements to a relation, they must represent something of their own. That means they should have some meaningful tag like bus stop.

Uh oh, just remembered:
If you use the iD-editor, that one seems not intended to handle relations! Perhaps better not touch them with it…

This is not necessarily true. In case of a turn restriction relation, there is a from-way, a via-node and a to-way. The via-node does not require any additional tags at all. The “from”, “via” and “to” are roles of the objects in the relation and are defined on relation level, not way or node level.

Thank you for the replies: alester, wycbtma, escada.

If the position of some traffic lights does not coincide with the one of those 5 construction nodes (the nodes from which the road is made of), then these traffic lights will be added as a separate nodes, right?
In that case that specific road will be a “relation” consisting of a single line (way) made of 5 (construction nodes), and a couple of additional nodes, where some may concide with the constuction nodes, and some may not (these are traffic lights).
And OpenStreetMap will simply ignore any kind of connection between these last nodes and construction nodes?

This is very interesting! Where can I find a screenshot (from JSOM Editor for example, or any other source) of how this would look like?

Hm, I am a bit confused.

Let’s say I have a “way” representing some residential road. And that “way” is consisted of 5 construction nodes.
If 3 of those 5 construction nodes also represent location where traffic lights are located, then I simply need to tag those nods with “traffic_signals=*”.
And in that case I do not need to create a “relation”. What we have is a regular “way” where some of its construction nodes are tagged.

But, if locations of traffic lights do not coincide with the upper 5 construction nodes, then one needs to add additional nodes for those locations. In that case a “relation” needs to be created, between the mentioned “way” and these new nodes?

Let’s say the first mapper just draws a way via an editor. This ways consists of e.g. 5 nodes and the tags on the way. That’s what goes into the OSM database. The editor knows that it is a way and will connect the nodes on the screen. The 5 nodes will be a bit thicker than the rest of the dots of the way.

Second mapper comes in and wants to add a traffic signal between the previously drawn nodes. He clicks on the way and adds a node to it. Now the way consists of 6 nodes. Of course she/he has to use the editor in such a way that the node gets added to the existing way.

Adding an extra node to an existing way depends on the editor, in JOSM, you could double click on any line that is drawn to add an additional node to it.

You can add as many extra nodes to a way (up to the limit of 1500) to add additional “features” like traffic signals, zebras, passing places, bus stops, etc. All those nodes become part of the way.

For traffic lights, as for other features, there are several options from simple mapping as a node in the intersection, to a more detailed mapping each stop position.

Thank you escada. So a person does not need to create a “relation” in order to add the additional nodes ON the line?
If this is true, then when does one needs to create a “relation” from that road? If additional points do not lie on the line, but somewhere around it?

Thank you muralito.

You use a relation when you need to represent something that cannot be represented as isolated nodes or nodes on a way, or would exceed the maximum number of nodes for a way.

Relations are difficult for people to understand and can be expensive for machines to process, so they so should not be used if there is another reasonable way of achieving the objective.

(It might be worth noting that if a road has to be split into more then one way, e.g. because only part of it allows two way traffic, giving the two ways the same name is treated as being sufficient to indicate they are related, you wouldn’t create a relation for the road as a whole.)

I think the most used relations are:

  • multipolygons (think islands in lakes or anything with a hole in the middle). You draw 2 closed lines (or ways) and indicate that one represents the outer “circle” and the other the inner circle
  • route relations for busses, hiking, cycling. They consist of a sequence of parts of streets paths and track. All those segments are added in order to the relation. For bus routes one also adds the platforms (lines or nodes besides the street)
  • turn restrictions (see above typically 2 ways and the intersecting node)
  • enforcement restrictions (e.g. speed camera’s): the node of the camera (often mapped besides the highway), and 2 nodes on the highway (or street) to indicate the beginning and end of the controlled area.
  • boundaries: the boundary of a city consists of a number of ways, typically forming a closed area. The ways are shared with the boundaries of the neighboring cities or even the provincies

hope this helps

Thank you for your patience with me and shared knowledge, both hadw and escada!

I’ve also found this article on wiki.openstreetmap, but still for some reason I am puzzled about some specific cases when “relations” should and should not be used.

Can you give one example please?

So the only reason why we are making a “relation” is that single node of camera which is mapped outside the highway line? That is the only reason?

What would happen if the all nodes of cameras will be on the highway line? In that case there would be no need for creation of a “relation”.

No, the relation IS the data, is how we choosed to model that if you drive in a way, there is a “device” (the speedometer/sensor/camera) which verifies that “from” some point in the road, “to” another point in the road you respect the speed limit or the red light. See this example

There are some features in the real world, like a turn restriction that modeled with a relation (In this intersection “via”, you cannot turn left “restriction=no_left_turn” “from” some way “to” another way.
The relation itself contains some information about the type of restriction, and references the objects where the rule is enforced.

If you put a speed camera on the road, it is not obvious in which direction it is working. Hence you have to add some kind of direction information. This is done with the from and to nodes in the relation.

It is also possible that there are 2 speed cameras at the same place (positioned left and right of the physical road), one for each directions, or that there are different speed limits in the two directions. While you might be able to model all those situations with tags on the nodes, the community opted for a relation. It is true that some people map speed camera’s on the way representing the street, but then they should at least add “direction=forward” or “direction=backward”. This would be an alternative, but then you would also have to add “maxspeed:forward=x” or “maxspeed:backward=y” or so, or deduce that from the tags on the street. It quickly gets messy and then the relation is more elegant.

With the category example you mention, we mean the following: We do not create a relation with all supermarkets of brand X. That would be a collection, that is just grouping objects together because they have a common characteristic, i.e. all have brand X.

A relation adds information, e.g. the order of ways in a route, the direction in which the speed camera is working and the speed it is recording, the fact that 2 ways together are forming a “donut” (island in water). Typically objects in a relation get a “role”: This is the “from” way", this is the “speed camera”, this is the “inner” circle. Or they get an order (as in the routes)

If you group objects together (all shop of brand X), there is no “role” or “sequence”. They are just all equal members of a set. That’s something we do not model. Those objects can easily be retrieved with a query (e.g. via Overpass)

One of the things I sense is that you want a precise algorithm for how to code everything. In reality, like many things in the real world of information, OSM works by defining what things mean, but allowing the mapper to then use them in the way that they think best fits reality. As an analogy, it is providing a dictionary, but it is not providing rules that result in a best selling novel.

There are certain other principles that apply:

  • the map can be built up progressively - a mapper can map things with very little detail, and a later mapper can refine it by adding more detail, so it may start with landuse=residential, then have buildings added with building=yes, then have building=yes, changed to buildlng=house and building=garage. Finally, someone may discover that a house has been converted into flats, and correct it to building=apartments.

  • there is a simplicity principle: one should use the simplest representation that achieves the purpose (in particular, that discourages the use of relations).

There are also things like not mapping information about people, not mapping things that change too often for the map to keep up, and many more.

As a possibly less obvious analogy, the details of the way that a film should be encoded into digital form for a DVD or digital TV is not specified anywhere in the standards. The standards only say how to reconstruct the moving image from that data. It is up to the designers of the recording equipment to find the way of encoding that produces the best end result for the viewer and is achievable at a reasonable cost.

Thank you for the replies muralito, escada, hadw and for your kind patience with me.
I succeeded in adding my first closed “way” to OSM, and will add some “nodes” (restaurants) soon.
But the “relations” are driving me crazy, as I still do not understand them.

Those three nodes alone:

are a “relation”?

And the “to”, “from” and “device” are not keys, but what?

What do the ‘x’ and ‘y’ represent?

I am trying to at least understand when should I use and when should I not use a “relation”.
For example with the upper speed camera’s on the road: I still do not understand why I couldn’t use a simple “way” and tag its nodes. I still do not understand why it is necessary to create a “relation”.

different speeds for the different driving directions e.g. 50 from left to right and 70 from right to left

No, you need to create a relation and add the three nodes to the relation.
Take a look at this relation creation dialog. This was opened after I selected 2 ways and a node and used the “turn restriction”-preset.
In the first step this preset asked me for the type of turn restriction I picked no_right_turn. In the second step I have to add the participants in the relation and type their roles:

a relation is a dedicated “object” that you have to create. This object can then have tags (the top section) and participants (the bottom section). The participants can have a role and/or a sequence. This depends on the type of relation you are defining.

3 loose nodes do not form a relation. You need a object that says: look those objects form a relation of type route/multipolygon/restriction/…, this are the characteristics of the relation and those objects participate in it.

suppose you have a very simple way

X------SP---->Y where X, Y and SP are the “defining” nodes of the way. Furthermore SP is the speedcamera. The way’s direction is from left to right. Now in which way is the speed camera working ? When you travel from left to right or right to left ?

OK, this can be solved by adding a tag direction:forward (in case it’s from left to right).

But what in case there is also a speed camera at the same place from right to left ? And it has to measure a different speed ?
Which tags would you add then ?

Furthermore, did you map the projected position of the speed camera on the road, or the position from where it starts to measure ?
What if that same camera can also measure whether you drive through a traffic signal ?

Try to map all those combinations with tags on that single node and you will notice that it becomes very hard to map.

I know that the older way of mapping was just putting the camera on the road, but it gave problems for some cases people wanted to map. Therefore they introduced a relation. So one could really map the exact position of the camera (which is typically besides the road, allows indicating the direction), allows to reuse the camera node for red-light camera purposes, etc.

But you still might find speed cameras mapped on the road, especially because OsmAnd was (or still is) not recognizing the enforcement relation

Escada, thank you for the detailed reply once again.
And for tolerating all these a bit too irrelevant questions, and my constant insisting on not understanding the answers.

Maybe I would start understanding the “relations” better once I start creating them.
For now, I do not feel confident to do that. I will stick with closed/open ways and nodes.
During time I may start to understand them better.
I hope it would not be a problem if I open a topic or two on “relations” again?

The web-based editors on the website both try and hide what’s going on behind the scenes from new mappers. For example, when I created I didn’t have to think “this is a way with role ‘outer’, this is a way with role ‘inner’”, I just drew the lake and the island and clicked the “make into a multipolygon” button in the editor.

Maybe one of the reasons for the difficulty in understanding relations is that ways are in some ways redundant, in that they are ordered lists of another object type, with associated attributes, and relations can also represent such lists, i.e. you could have a relation with a type=way.


  • ordered lists of nodes are so fundamental to a map (or any 2D drawing) that it makes sense to have a basic construct that represents them. (If you didn’t would probably have to create that construct internally, so that they could handled efficiently.)

  • it is likely that relations did not exist in the original design (or the original of the design on which the OSM design was based), but were added to deal with complex cases;

  • as implemented, relations aren’t actually treated as ordered, even though for some purposes it is much easier to deal with them if they are in order, e.g. a bus route should be ordered by the order in which the elements are encountered by the actual bus. (They are treated as ordered by JOSM but renderers cannot rely on them being ordered.)

  • as implemented, some of the web based editors only have limited support for relations. I believe that iD cannot create them;

  • as you have discovered, they are difficult to understand, but beginners can go a long way in mapping without ever having to deal with them, so, by having ways as a distinct object type, beginners only need to learn nodes and way to start mapping productively.

That’s good to know. Thank you SomeoneElse.

Thank you hadw. It’s good to know this!