# Exploring Data Model Relations in OpenStreetMap
## 5 Conclusions and Future Work
### Summary of Key Findings  
Section 4 outlined our analysis of relations in four European cities. There are a number of key findings in this paper and they are summarized as follows:  
* **Composition of Relations:** In our analysis, we found that relations composed of only way objects and relations composed of only node and way objects are by far the most frequently occurring composition arrangement for ways in all four cities. Much smaller, but not insignificant, numbers of relations are comprised of only node objects or only relation objects. More indepth analysis of the composition of relations is required to better understand the spatial and topological relationships they are trying to represent. [PERSON] et al. [PERSON] et al. (2015) conclude that the composition of relations, the spatial relations they represent and the tags associated with the relations could provide opportunities for applications such as the derivation of Land Cover classes from Land User map data. [PERSON] et al. [PERSON] et al. (2016) present a new method to provide local decision makers with tools to assess the remaining (roof-mounted photovoltaic) PV potential within their respective communities. It allows highly detailed analyses without having to rely on 3D city models. OSM is used for the building footprint data. The authors estimate building size from the geographical area of ways relations with the building tag. However, their results are dependent upon accurate building tagging of ways and relations. It can also be assumed that the topological validity of relations would also need to be investigated to ensure that an accurate estimate of building footprint area was being calculated. * **Membership Size of Relations:** The distribution of membership size of relations is very heavily skewed towards relations with 10 members or less. We describe in Section 4.2.3 that over 70% of relations in all cities have 10 members or fewer. The tendency towards smaller relations follows the advice of the OSM Wiki on maintaining relation objects with a manageable number of members. We did not find specific work reported in the literature related to the membership size of relations. We find that overall the number of members in relations appears relatively small. A wider sample of cities is required to establish if this is a general trend or pattern. Additionally, we feel that the membership size of relations could play an important role in assessing data quality variables such as completeness and coverage. The number of members within a relation may also have influence on any semantic interpretations extracted from these data
* **Tagging on Relations:** Over 85% of relations in all of our four cities have three tags or fewer. The two most frequently co-occurring tag keys with the type tag on relations are very consistently applied across the five most popular type tags in all of the cities. Tagging and the subsequent maintenance of tags on objects in OSM is a well studied problem. In [PERSON] et al. [PERSON] et al. (2017) the authors find, in a global study of OSM Points-of-Interest objects that only a minority of POI types (fewer than 10% of all types) are actually being frequently maintained (for example tag edits) and that several hundreds of POI types receiving near zero maintenance instead. [PERSON] et al. [PERSON] et al. (2018) study several major European cities. While they do not provide precise statistics, they remark that there is a lack of tagging observed on way objects representing highways in all of the cities investigated. In an extensive global analysis, [PERSON] et al. [PERSON] et al. (2018) found that for 40 cities globally there was very often a very low number of tag keys used, with a mean of fewer than 2 (approximately 1.33) additional tags per object for way objects. In [PERSON] et al. [PERSON] et al. (2015), the authors consider which tags and relations in OSM can be used to create Land Use and Land Cover (LULC) classes from the Corine Landcover Classes.