## 5 Conclusions and Future Work
### Conclusions  
Our analysis of OSM history data has given us some interesting research results. In Section 4.2 we showed that \(11\%\) of contributors created or edited \(87\%\) of the spatial data in the \(15,640\) \"heavily \begin{table}
\begin{tabular}{l r r} \hline \hline
**Node Edit Action** & **Total** & **(Same User)** \\ \hline Nodes Unchanged & \(50\),\(216(16\%)\) & \(41\),\(678(83\%)\) \\ Nodes Deleted & \(15\),\(692(5\%)\) & \(9\),\(729(62\%)\) \\ Nodes Added & \(247\),\(937(79\%)\) & \(223\),\(143(90\%)\) \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Summary of the number of consecutive versions where nodes were added, deleted, or left unchanged. The percentages in brackets indicate the number of cases where consecutive versions were edited by the same contributor. \begin{table}
\begin{tabular}{l r r} \hline \hline
**Consecutive Versions** & **Total** & **(Same User)** \\ \hline Invalid,Invalid & \(25\),\(107(8\%)\) & \(21\),\(843(87\%)\) \\ Valid,Valid & \(285\),\(598(91\%)\) & \(237\),\(046(83\%)\) \\ Invalid,Valid & \(1685\)(\(<\)\(1\%)\) & \(1145(68\%)\) \\ Valid,Invalid & \(1455\)(\(<\)\(1\%)\) & \(1091(75\%)\) \\ \hline \hline \end{tabular}
\end{table} 
Table 5: The validity status of consecutive versions of the same objects. The percentages in brackets indicate the number of cases where consecutive versions were edited by the same contributor. edited\" objects. Assignment of values to attributes or tag keys is another area where a historical analysis of edits demonstrates issues in the collaborative nature of OSM. \(4.1\%\) of objects have the assigned value to their \"name\" attribute changed \(3\) or more times. This rises to \(25\%\) of objects which have the assigned value to their \"name\" attribute changed \(2\) or more times. Disputes and disagreements occur. Table 4 shows a long and protracted dispute in Germany over the assignment of a classification to the highway tag. Table 3 shows an example from the UK where a street is assigned \(5\) different names. The use of two well known string matching metrics in Figure 3 shows that changes to \"name\" attributes are not subtle single character changes but major edits to the value assigned to \"name\". This will form a useful basis for future work to investigate if this behaviour extends to other OSM regions and communities. The uncertainty introduced by frequent changes to \"name\" or \"highway\" attributes has implications for the development of gazetteers from OSM and location-based services (LBS) which will need to be evaluated [56]. In [PERSON] _et al._[8] the authors comment that the quality control of OSM differs fundamentally from professionally edited maps. The community-based approach allows anyone to upload and alter map data. However, due to the huge number of editors, errors and conflicts are usually quickly resolved. A long-term historical analysis, following on from this work, will provide evidence to support this hypothesis that eventually OSM data \"stabilizes\" for an area. Some tools are beginning to appear for visualization of the history of Wikipedia pages [57]. Some tools are beginning to emerge for OSM history but they are still in their infancy and lack powerful information visualisation functionality. Section 4.5 discusses the number of tags, or metadata, assigned to each object at its final (current) version. The mean number of tags assigned to features is \(3.45\). There is no discernible statistical relationship between increasing numbers of contributors and number of tags nor is there a statistical relationship between the number of versions created for an object and the number of tags. This could indicate that new contributors to an object passively accept the current set of tags without adding any additional tags. The increase in versions, without an apparent correlated increase in the number of tags, is probably a result of the \"tag flip-flopping\" we discussed in Section 4.3 or edits to the geometry of the object (Section 4.6). As Table 6 shows in \(79\%\) of edits nodes are added to objects.