ETS Data maintenance

From Wikicap - European Commission

Go up to the main ETS page


The reference data stored in the LPIS and being subject to ETS inspection can be the same as the deadline for the farmer's application or a later date linked with particular LPIS update on the basis of the annual MS upkeep cycle implemented by the MS Administration. The observations made during the inspection are based on imagery that can be earlier or later and possibly on field activities that are organized by the end of the year.

In this respect, it is acceptable that the sampled item under inspection would be updated to match any concurrent system update on condition that such system update occurred in "tempore non suspectu" (i.e. the LPIS custodian had no hand in the time when the update initiated).

Evidencing - NEW

The LPIS quality assessments of the previous years have revealed that the unstructured evidence instructions failed to provide sufficient reliability regarding the "in tempore non suspect" character of the updates and structured feature meta-information provides an easy but structured alternative:

ETS v6.4 has a dedicated xml schema, based on the LCM implementation of an anomaly and lifecycle information. It holds the following main attributes:

  • Identification. A unique identification of the anomaly (e.g. an automatically generated sequential number)
  • Object: this should be the identifier of the affected reference parcel (RPID)
  • Cause. The cause of non conformity, according to the list of QE4, "changes in land" is expect to be the most frequent cause
  • Observation(s). The details on the observation, including:
  1. Author (stakeholder)
  2. Values that are suspected non-conforming: in case of discrepancies in the ETS reference area as reported in the LPISPointZeroState
  3. Observation date of the findings related to the anomaly (validFrom)
  4. Data selected for resolving the anomaly (supplementaryData)
  • Status in the process. Details on the process closure of the anomaly, including:
  1. Date of reception (beginLifeSPanVersion)
  2. Status of actions regarding the processing of the anomaly: for example "completed" if the reference area has been already updated

Any discrepancy between the reference area values of the LPISPointZeroState and LPISPolygonAreaZeroState should be accompanied by a duly filled in record within this anomaly file. Its presence and correctness will be automatically checked during the upload of the ETS Reporting Package.

All vaiwered discrepancies in classification correctness test (vaiwer E) should be evidenced with additional written documentation or extracts from sourcing registers. These records can be unstructured and should be uploaded within the ETS reporting package in the LPIS QA Portal under "Optional Supportive Document"

For any potential incomplete block where the LPIS holds unaccounted land which has not been flagged as critical defect, an evidence from external or internal registries should be documented and uploaded as unstructured files within the ETS reporting package in the LPIS QA Portal under "Optional Supportive Document"

Any national rules of specific implementation for contamination occurrences (differing from the ETS methodology) should be documented and uploaded within the ETS reporting package in the LPIS QA Portal under "Optional Supportive Document".

Go up to the main ETS page