Validation Process

Mapping is a crucial activity that requires accuracy and consistency to ensure the information presented on a map is reliable.

In a perfect mapping scenario, contributors adhere to instructions and accurately map the tile. However, this is not always the case. Therefore, the validation process is in place to maintain a high standard and continuously improve the quality of the data, ensuring its consistency and reliability.

There are two fundamental premises that should be considered when creating a map: the map must describe a reality that is verifiable, and, according to the philosophy of OpenStreetMap (OSM), anyone can check, correct, or integrate any previously mapped data.

Even non-expert users' mapped data is part of a project whose use often goes beyond the project's scope. As such, mapping work that is performed non-professionally but on a voluntary basis by non-professional citizens or students must be checked and validated. The validation process is equally important because it allows the validator to provide comments that help "train" the mapper. The validator can point out inaccuracies that the mapper can avoid in subsequent mappings. Therefore, mapping work requires accuracy and consistency to ensure the reliability of the information presented on a map.

The validation process is critical in ensuring that the mapping work is consistent with the project's specifications and executed correctly. The validator's role is to check the data's consistency entered with the project's requirements. This activity is crucial since it allows all the mapping work done in previous times to be preserved. Without validation, there is a risk of having to discard all the work previously done, which can be detrimental to the project's progress.

Those who create the project generally decide who can map and who can validate the mapping once it is completed. As a rule, these tasks are assigned to specific groups, and the one in charge of validation is an experienced mapper.

Each project has a different level of mapping complexity, ranging from Beginner to Intermediate to Advanced. Project Creators can limit the validation process to those with appropriate expertise for the difficulty level or complexity of the mapping in their project.

The validation operation is almost always done within the Tasking Manager, using the same editor that was used to perform the mapping. More generally, the purpose of the Tasking Manager is to divide a large mapping project into smaller tasks, with many people contributing to the goal set in the project. The areas that need to be mapped, those that need to be reviewed, those that need to be validated, and which areas have been completed are then shown (Fig. 1).

Fig. 1: Within TeachOSM it is possible to explore existing projects, see what percentage of area has been mapped and what percentage has been validated.

Within TeachOSM (accessed with your OSM account) it is possible to explore existing projects, see what percentage of area has been mapped and what percentage has been validated. In Teachosm.org, areas that have yet to be completed appear yellow, those that need to be validated appear blue. In general, the legend that appears implicitly establishes a priority of tasks to be performed on that area.

The validator sees exactly the instructions that guided the mappers during their work (e.g., mapping only the buildings in this area) and in this way the verification of the work done is well defined (Fig. 2).

Fig. 2: The instructions set at the beginning of the project are the basis for validation.

Validation begins only when the mapping activity on a certain area is declared finished, whereas, on the other hand, control of the operating users can be carried out at any time. Thus, with validation, all activities are stopped, and when validation is completed, the project is declared completed.

On an open project in the Tasking Manager, it is possible to check the different time levels of mapping contributions: who mapped that area and when. The temporal level is important because with the passage of time it is possible that the actual situation has changed (for example, a new building is built, or another is demolished).

Therefore, before analyzing the data we check the mapping history, that is, how many and which users have operated and any comments they have left. The validation process is carried out on the tasks into which the project itself is divided, which are then validated one at a time. The process starts only when the mapping is declared "completed." The most common issue is a simple mistake that anyone can make, where a task is marked as complete even though it's clear that the majority or entirety of the task still needs to be mapped.

Within each task, two key aspects must be evaluated:

1. Completeness, that is, whether all the elements (required by the project) have been identified.

2. Correctness, i.e., whether the mapped entities are geometrically (example buildings should be squared) and semantically (the tag associated with individual elements) correct.

The correctness must be evaluated from several aspects. First, the temporal aspect must be considered. For example, in the mapping of satellite images, if the image was too "old" this could lead to an outdated and therefore not useful result. In this case the validator can intervene by giving feedback to the user who will then use the final map.

Of course, the geometric aspect is also crucial: the geometry of the mapped entities must be correct. In general, regular geometry is required according to standards that depend on what the mapped entities are. For example, buildings must be square, that is, have 90-degree angles even if they appear different in the satellite image. This is because there is a convention in OSM to consider the building object defined in this way. It can of course also be a different geometry (for example, a circular entity is used to describe huts) but always regular (Fig. 3, 4, 5). Regarding linear elements (e.g. roads) the main checks on the geometry that must take place are:

a. lines must join "nodes."

b. lines must not intersect each other,

c. they must consist of as few nodes as possible,

d. intersections must coincide with a node.

For the entities "points" there are no possible geometric inconsistencies but very often semantic inconsistencies, that is, related to the tag that is associated with the point (usually points are mapped in the field and not from satellite imagery).

Fig. 3: Red closed lines that constitute polygons appear in the image and correctly correspond to buildings. The white lines are still polygons, but the associated tag is missing, then they are identified as lines and not as buildings. In this case, the correct tag is associated with the geometric entity during validation.

Fig. 4: Beginner error example: a mouse click error does not complete the building perimeter.

Fig. 5: Example of distraction error: buildings are not squared or forget to associate the corresponding tag.

In checking on the geometry, one must verify that the correspondence between the elements (on the image and on the map being constructed) is always 1:1. So, for example, two neighboring houses should not be grouped together but shown as two adjacent but distinct buildings (Fig. 6).

Fig. 6: Example of multiple errors: in this case some buildings are mapped twice, there are overlapping elements, non-square buildings appear with missing tags.

Control over the semantics (tag) of the input data is critical. At the beginning of the project, the degree of detail to be achieved must also be clearly established: based on this the required tags must be defined. This list of tags is the basis for subsequent validation. There are very detailed tagging guides (see for example WIKI OSM), with specifications that often vary by country (Fig. 7).

Fig. 7: The highways tags depend on the country and are divided in categories, each category has different tags (https://wiki.openstreetmap.org/wiki/Highway_tagging_samples/urban).

This means controlling the tag associated with mapped entities, which must be consistent with OSM guidelines. For example, a building mapped on a satellite image must be tagged as "building=yes" and not otherwise; field mapping is required to include other specifications.

In a mapping to satellite imagery at the time of validation one must check for missing objects and the background image must obviously be the same as that used by the mappers. If the image is different there may be an offset between what is on the image and what is mapped.

1. Verify base map image.

2. Check for any missing objects.

3. Consistency of mapped objects.

The result of the validation can be yes, no or validation suspended.

On satellite imagery, georeferencing is linked to the image itself: you map to the image and then link the mapped object to the image's reference system, regardless of the inherent accuracy of the image. If the mapping is in the field (e.g., in an urban environment), the coordinates that are read on the cell phone and linked to the mapped object may also have considerable errors, but this aspect is not usually considered in validation.

In the presence of an error or inconsistency, the validator has two options: he can report the error and request that the mapping be repeated/integrated, or he can intervene directly and correct it himself.