Questions about OpenStreetMap basic elements

[wycbtma]

@bernard1995

It means that: if long hiking, biking trails go over different streets and paths, they are NEVER made of a single way (line). But instead of parts of those different streets and paths over which they go?

Exactly. Just collecting together separate elements.

@bernard1995

This is the part that makes me confused.
A “way” is basically a line made by a certain number of nodes. So the nodes are only a construction elements in this case.

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.

@bernard1995

However, if a “way” has some nodes attached to it (bus stops of a certain road for example), that are not upper mentioned construction nodes, then this kind of OSM element is called: a “relation”.

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.

@bernard1995

How do I know if the nodes you’ve just showed me are a construction nodes of the particular “way”, or are they part of some “relation”?

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 osm.org. Just look at hadw’s nice example page again:
http://www.openstreetmap.org/way/71799578
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…

[escada]

@wycbtma

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.

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.

[bernard1995]

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

@alester

For example, let’s say we have a 5-node way that represents a road going around a corner. If we didn’t add any tags to the way, data consumers would have no way of knowing what real-world feature we intended this object to represent and it would be virtually useless. Since the real-world thing that’s being represented here is the road, we want to add tags to the way to indicate that’s what it is (like highway=residential). The 5 nodes are just there to define the shape of the way and don’t have any additional real-world meaning, so we don’t need to add any tags to them and can leave them untagged. However, if there was a traffic light at the location of one of these 5 nodes, we could add the tag “highway=traffic_signals” to represent it. In this case, that node is serving two purposes: to represent the traffic light, and to define the shape of the way.

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?

@alester

Similarly, ways that define the shape of a relation can sometimes be left untagged. For example, let’s say we have two 1500-node ways that have their ends joined to make a complete circle in order to represent a large lake. Each of these ways is only there to define the shape of the relation and doesn’t represent any other real-world feature, so they can be left untagged. We then add tags to the relation to indicate that it represents the lake (e.g. “natural=water”).

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?

@wycbtma

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.

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?

[escada]

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.

[muralito]

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.
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals

[bernard1995]

@escada

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.

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?

@muralito

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.
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals

Thank you muralito.

[hadw]

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.)

[escada]

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

[bernard1995]

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.

@hadw

You use a relation when you need to represent something that cannot be represented as isolated nodes

Can you give one example please?

@escada

• 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.

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”.

[muralito]

@bernard1995

@escada

• 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.

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 http://www.openstreetmap.org/relation/6497413

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. http://www.openstreetmap.org/relation/3639090))
The relation itself contains some information about the type of restriction, and references the objects where the rule is enforced.

[escada]

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)

[hadw]

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.

[bernard1995]

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:

@muralito

Node 4353119939 as to
Node 4353119938 as from
Node 4353119937 as device

are a “relation”?

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

@escada

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.

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

@hadw

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.

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”.

[escada]

@bernard1995

escada wrote:
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.
What do the ‘x’ and ‘y’ represent?

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

[escada]

@bernard1995

muralito wrote:
Node 4353119939 as to
Node 4353119938 as from
Node 4353119937 as device
are a “relation”?
And the “to”, “from” and “device” are not keys, but what?

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.

[escada]

@bernard1995

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”.

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

[bernard1995]

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?

[SomeoneElse (Andy Townsend)]

@bernard1995

Maybe I would start understanding the “relations” better once I start creating them.

The web-based editors on the openstreetmap.org website both try and hide what’s going on behind the scenes from new mappers. For example, when I created http://www.openstreetmap.org/relation/6702896 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.

[hadw]

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.

However:

• 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.

[bernard1995]

@SomeoneElse

@bernard1995

Maybe I would start understanding the “relations” better once I start creating them.

The web-based editors on the openstreetmap.org website both try and hide what’s going on behind the scenes from new mappers. For example, when I created http://www.openstreetmap.org/relation/6702896 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.

That’s good to know. Thank you SomeoneElse.

@hadw

• 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.

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