The anomaly feature type

From Wikicap - European Commission

Go up to the main update page

In the LPIS context, an anomaly materialises a message originating from stakeholders’ observation stating that "something is different from what it is supposed to be". The anomaly is an observation of a data discrepancy or a potential non-conformity.

This message will start a process to resolve the discrepancy or non-conformity. An anomaly can be originated from various stakeholders, from example:

  • OTSC inspectors who reports and confirms non-conformity of the determined area of the position of the affected boundary segments of the reference parcel. It is expected that not only the non-conformity is reported and confirmed, but supplementary data (for example boundary measurements) are also provided.
  • LPIS QA inspectors. In the course of inspecting the parcels, non-conformities expressed as values of the applicable data quality measures (area, critical defect, and contamination) might be found. Beyond reporting, confirming and categorising the non-conformity, additional input data, for example precise location of non-conformity i.e. of critical defect or contamination) may be provided as well.
  • Farmers may report anomalies in terms of the reference parcel and, especially in the context of geospatial application, the location of agricultural parcels included in the reference parcel. The declarations of farmers and the related cross checks may trigger launching an anomaly thread. It should be noted, that the input data, as they do not come from professional sources, should be treated with special care.
  • Third parties - (datasets of partners and contractors, open data) –can reveal non-conformities, especially by spatial intersecting their data with LPIS. An appearance of a new road or building, when third party data is more current than the last imagery provides a valuable input for updates.

The completeness of the anomaly description and its status varies depending on the stakeholder. In all cases it very important to define, whether it affects one or more reference parcels.

The information needed for managing the update process is included in the following concepts:

  • Anomaly (the core feature type)
  • Values for cause of anomaly
  • Status of anomaly

These concepts, represented in Figure 3 as UML classes, specify the information that has to be recorded by the processing of an anomaly. They also help the users to monitor the status of the update workflow.

Pic3.jpg

Figure 3: UML classes describing the main concepts of the anomaly

Name

Mnemonic name

''''Description

Metadata

metadata

Feature level metadata can include information about the life-cycle, status, data quality, usability, responsible entity, etc.

Status of anomaly

statusOfAnomaly

Status of the anomaly at a given stage of its life –cycle. The stages are defined in terms of the related code list, such as

  • Open
  • In progress
  • Archived

Cause of anomaly

causeOfAnomaly

Change in the real world that causes a non-conformity. The possible reasons are taken from the related code list:

  • Cause unknown
  • Cause not confirmed
  • Irreversible conversion of agricultural land covers
  • Appearance of permanent constructions
  • Change in the perimeter because of addition of agricultural land
  • Change in the perimeter because of exchange of agricultural land

Reference parcel ID

referenceParcelId

Unique thematic ID of the reference parcel or the reference parcels where the non-conformity has been observed.

Confirmed by visual inspection

confirmedByVisualInspection

Statement whether a reported anomaly is confirmed after the visual inspection in course of the updating process. NOTE: The input data comprises imagery and vector data. They are fit for update when the parcel(s) involved in the anomaly are fully represented by the image and vector data (completeness of input) and they are congruent. In addition, the imagery should be not older than that one that has been used for detecting anomaly. Otherwise the changes are not visible.

Congruency test

congruencyTest

Conformance statement about the result of the optional congruency test. "Congruent" refers to a situation where two polygons (parcel representations) have the same shape and dimension. This condition is fulfilled when

  • the position of the two geometric representations coincides
  • there is no coincidence between the geometric representations, but the shape and the dimension is the same. In fact, in this case there is a shift between the two geometries.

NOTE: Congruency test is very rarely needed, only when visual inspection leaves a distinct doubt

Supplementary data as ancillary

supplementaryDataAsAncillary

Ancillary value is assigned to those non-conforming supplementary data that can contribute to the update process, but alone, do not allow complete processing..

Supplementary data

supplementaryData

Reference to the data source that is evaluated as fit for update. Such data sources are selected for resolving an anomaly. It can be one or more dataset, imagery, measurement vectors, etc.

Go up to the main update page