# Exploring Data Model Relations in OpenStreetMap
## 3 Working with Relations in OSM  
Before we detail our experimental analysis, we shall now provide a more formalized definition of an OSM relation. In OSM, a node \(n\) is a geographic coordinate with tags \(n_{t}\) where the set of tags can be empty. A way \(w\) is an ordered set of nodes \((n^{0},n^{1},\ldots n^{N-1})\). If the way \(w\) represents a polyline feature such as a road or path then the \(n^{0}\
eq n^{N-1}\). However, if the way \(w\) represents a closed polygon feature such as a building or a lake then \(n^{0}=n^{N-1}\). For polyline ways, there should always be a minimum of two nodes while for closed polygon features there should always be a minimum of three nodes. A way can also have a set of tags \(w_{t}\). The set \(w_{t}\) can be empty, but normally it is encouraged that this is not the case. Finally in OSM a relation \(r\) is an element representing the logical relationship between objects. A relation \(r\) is represented by a set containing at least one object. A relation can contain any combination of existing nodes, ways and even relations themselves. These are called members. As is the case with nodes and ways relations can also have a set of tags \(r_{t}\) associated with them. As before this set can be empty but this is discouraged. The OSM Wiki has a large section dedicated to relations [25] and this is an important source of guidance to contributors to OSM. The documentation around relations recommended that relation objects only have about 300 members. If it is necessary to handle more than that amount of members contributors are encouraged to create several relations and combine them with a Super-Relation. The thinking behind this is as follows. The more members that are included in a single relation, the more difficult it is to handle, the easier logical errors and conflicts can occur. Ultimately, the OSM Wiki outlines these super relations consume additional resources at the database and server side. To illustrate the data representation of a relation in OSM Figure 1 shows the XML (eXtendible Markup Language) representing a relation in the Zurich, Switzerland. This relation is of type route and represents a cycle route which is part of the regional cycle network of Switzerland. There are 14 members of this relation. Two of the members are themselves relations while the remaining 12 are ways representing part of the bicycle route ref 66. The first part of the XML for the relation tag has all of the standard OSM attribute information: the current version number of the relation, the timestamp of the last edit, the user ID and username of the last contributor to edit the relation, the change set of edits that this relation edit in contained in, and the OSM ID. Each relation, as is the case for nodes and ways, has its own unique identification number (OSM ID) within the OSM database. If one can access these number then the OSM website provides a simple way to visualise relations and their history within a single API (Application Programming Interface) call. For example the Tiergarten suburb of Berlin, Germany, has an OSM ID of 55750. The API call [[http://www.openstreetmap.org/relation/55750](http://www.openstreetmap.org/relation/55750)]([http://www.openstreetmap.org/relation/55750](http://www.openstreetmap.org/relation/55750)) will display (render) the current version of this relation on a basemap while the API call [[http://www.openstreetmap.org/relation/55750/history](http://www.openstreetmap.org/relation/55750/history)]([http://www.openstreetmap.org/relation/55750/history](http://www.openstreetmap.org/relation/55750/history)) will also display or render the current version of this relation but also provide access to all of the previous versions or history of the relation for access.