# Exploring Data Model Relations in OpenStreetMap
## 1 Introduction  
The OpenStreetMap (OSM) project and database have both received increasing research attention from academics and analysts over the past number of years. The majority of geocomputational research reported has focused on the OSM database and the OSM data model. The OSM geographic data model is reasonably easy to understand. There are three principal data object types: nodes (points), ways (polygons and polylines), and relations (logical grouping of all three object types). At the time of writing in August 2017, in the global OSM database, there are over four billion nodes, over four hundred million ways, and over five million relations [1]. Nodes and ways have been the subject of the most intense research investigation while there has been limited work reported or published on relations in OSM. This is surprising given that, as we shall discuss, relations provide the constructs to model complex real-world features, geographic relationships, and representations within the OSM database. Relations play a very important role within the OSM data model. While there has been limited academic investigation into relations in OSM they provide OSM with a means of implementing complex spatial and topological relationships. A relation is one of the core data elements that consists of one or more tags [2] and also an ordered list of one or more nodes, ways and/or relations as members which is used to define logical or geographic relationships between these elements. A member of a relation can optionally have a role which describes the part that a particular feature plays within a relation. A simple example of a relation might be a university campus. The university campus itself contains many ways, representing roads and buildings for example, and nodes representing points of interest around the campus. The relationthen expresses the geographic relationship of the campus between these node and way elements. Another very popular type of relation in OSM is called a _turn restriction_. These relations are usually applied at road intersections, streets, or junctions. Such relations have a set of tags describing the type of turn restriction. Turn restrictions, such as No-left-turn, restriction=only_straight_on and No-U-turn, regulate traffic flow at intersections. The relation then includes the ways and nodes which make up the physical road infrastructure in the junction or intersection. In a similar way to nodes and ways, relations are created and edited by contributors to OSM using software such as JOSM (Java for OpenStreetMap [3]). Routing software and applications which use OSM data then use these relations to create workable optimal routes between locations. We believe that relations play a very important role in modeling complex real-world geographical relationships and phenomena in OSM. Without relations, the OSM database could not be used for applications such as routing [4; 5], traffic simulation [6] or Web Map Services (WMS) [7] to name but a few. Indeed we believe anecdotally that the role of relations is not actually apparent to many of external users and consumers of OSM data. To address this apparent gap in the knowledge of Volunteered Geographic Information (VGI), this paper has three research goals which are outlined as follows:  
* To carry out an exploration of the types of relations represented in OSM for four large European cities and understand how they model geographical relationships and phenomena in these cities. * To investigate how the relations are represented, for these four cities, within the OSM database as data objects. * To explore the research question: are the patterns of contribution, editing and tagging for relations similar to those observed by other researcher work on OSM nodes and ways? At the conclusion of this work, we will provide some general observations and conclusions about this work along with a number of suggestions for future research work which could be considered. The remainder of this paper is organized as follows.