Upkeep - Anomalies
Dealing with anomalies
The concept of anomalies
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". This message will start a process to address the issue. This, in turn, involves confirming the non-conformity, taking remedial actions and recording all the connected transactions.
Obviously one or more reference parcels can be affected by the same anomaly and one reference parcel can be affected by more anomalies. Anyway, each affected reference parcel should be uniquely identified. Some of the anomalies are connected with the LPIS specification. Anomalies can be observed in any spatial or alphanumerical attribute value of the reference parcel.
ISO 19156 provides a framework to model observations but this has yet not been applied to LPIS reference parcels of the LCM.
Properties of anomalies
In database terms, each anomaly and the related observations can be regarded as "objects" or "features". Here we list the attributes that an anomaly should possess if it is used to drive the upkeep process (i.e. confirmation, remediation, and logging the actions related to a suspected non-conformity).
- Identification. A unique identification of the anomaly (e.g. an automatically generated sequential number)
- Object: Primarily, this should be the identifier of the affected the reference parcel (RPID), which can be further supported by its location (geometryLocation). Alternatively, the object could be a region of interest, whose coordinates (geometryLocation) are used to create "second generation" anomalies through spatial overlay. This approach is particularly useful when changes are reported by third parties (e.g. road builders).
- Cause. The cause of non conformity, as soon as it is established. The LPIS QA methodology identifies different types of causes.
- Observation(s). The details on the observation, including:
- Author (processOperator)
- Values that are suspected non-conforming (OM_GeometryObservation, OM_Measurement, etc.)
- Observation date (phenomenonTime)
- Other comments (parameter)
- status in the process. Details on the processing of the anomaly, including:
- Date of reception (resultTime)
- Status of actions regarding the confirmation
- Status and logged consequences on the LPIS objects
- Other comments
The sequence of processing anomalies can be summarized in the following steps:
- Anomalies can be observed by any stakeholder (actor) using the LPIS. This can happen at any time and the anomaly should be described in detail. A report is sent to the LPIS/GIS custodian.
- The operator of the LPIS/GIS custodian registers the anomaly in the database of reference parcels. The operator of the LPIS/GIS custodian may observe or collect additional (extra) anomalies that are in turn registered.
- The anomalies are processed by dedicated personnel of the data custodian or alternatively by contracted parties. These actors retrieve the data of the affected parcels from the database and after processing deliver it to the GIS/LPIS custodian.
- The operator of the GIS/LPIS custodian validates the proposed remedial actions. The operator commits the corresponding changes to the database and changes the status of the anomaly.
Some actors are expected to report specific types of anomalies as listed below:
- a farmer- reports anomalies holding a new area of the reference parcel.
- an OTSC inspector - reports anomalies with an area determined and a position of the affected boundaries of the reference parcel.
- third parties - (partners and contractors) – report anomalies on images used for control, area and boundaries of the reference parcels.
Anomaly process sequence diagram
The process described in the previous section is shown in diagram 1 using UML sequence diagram:
Please contact the JRC if you wish to share your developments.
Go back to the main upkeep article