In a previous blog post we performed a conceptual compliance analysis between OSM data and several tagging-guidelines using the OSHDB API. The results were visualized in a linechart, comparing the different compliance ratio over several months. In this post we explain how to calculate a spatial compliance rate by making just a few changes in the previously used code.
We use a shapefile containing a grid of equal area 10×10 km cells over the region of interest. The cells have unique ids. The compliance rate will be calculated for every cell.
The first steps in the code are equal to the monthly compliance analysis, apart from the time parameter. For the spatial compliance calculation we need a timestamp and not an interval. After we read the tags of the editor tag lists, we need to prepare and read the shape file that is stored in the variable “collection”.
The key difference is that we add an .aggregateBy() function after the filter .osmTag(“highway”), to aggregate the compliance values per cell id of the grid in the shape file.
.aggregateBy(snapshot -> {
// calculate the center coordinates of the highway-object (entity)
double xCoord = 0;
double yCoord = 0;
if (!snapshot.getGeometry().isEmpty()){
xCoord = snapshot.getGeometry().getCentroid().getX();
yCoord = snapshot.getGeometry().getCentroid().getY();}
// find the corresponding id of the grid cell in which the entity falls.
Long cellId = -1L;
FeatureIterator iterator = collection.features();
try {
while (iterator.hasNext()) {
Feature feature = iterator.next();
GeometryAttribute sourceGeometry = feature.getDefaultGeometryProperty();
if (sourceGeometry.getBounds().contains(xCoord, yCoord)) {
cellId = (Long) feature.getProperty("ID").getValue();
break;
}
}
} finally {
iterator.close();
}
return cellId;
}
In the following .map() function we compare the tags of the entity to the tagging-guideline. The entity can either be compliant to the guideline, or not. If the entity contains one or more invalid tags, the whole entity is non-compliant. In the case of compliance, we return the value 1. In the case of non-compliance we return the value 0. Thereby we can store the information of how many compliant and how many not compliant entities exist per cell id.
.map(snapshot -> {
int key = 0;
int value = 0;
EnumSet complianceInformation = EnumSet.noneOf(EntityObject.class);
OSMEntity entity = snapshot.getEntity();
// analyze step by step all tags of an entity
for (OSHDBTag tag : entity.getTags()) {
key = tag.getKey();
value = tag.getValue();
/* comparison of osm tags to tags of source lists
. . .
every time we find an invalid tag, we store the information in the complianceInformation
*/
}
if (complianceInformation.isEmpty())
return 1;
else
return 0;
})
In the last step we calculate the average of the compliant entities.
.average();
The result is a sorted map that holds the compliance rate based on entities for every raster cell id. We aggregated the results to yearly compliance rates.
Visualization
In our former post on computing a compliance rate, we could see a reduction between 2015 and 2016 in the compliance of the OSM data with the iD and JOSM editor. This was caused by a special tag (de:strassenschluessel). This tag is used almost exclusively in Mecklenburg Western Pomerania and is therefore not supported by the iD and JOSM editor. In the spatial visualization the effect of this tag is visible as well. Between 2015 and 2016 we see a clear decline of cells with the highest compliance.
This post shows you how to combine different capabilities of the OSHDB API and provides further insights on why the conceptual quality differs. If you have any questions or want to give us feedback, don’t hesitate to contact us via info@heigit.org.
Part 1 of conceptual compliance analysis with the OSHB you can find here:
heigit.org/conceptual-compliance-analysis-with-the-openstreetmap-history-database-oshdb/