• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
LPIS QA formalises mainstream GI  in the CAP
 

LPIS QA formalises mainstream GI in the CAP

on

  • 1,619 views

Presentation by Wim Devos of JRC-IES MARS-unit on the LPIS Quality Assurance and its importance to the CAP.

Presentation by Wim Devos of JRC-IES MARS-unit on the LPIS Quality Assurance and its importance to the CAP.

Statistics

Views

Total Views
1,619
Views on SlideShare
1,473
Embed Views
146

Actions

Likes
0
Downloads
7
Comments
0

6 Embeds 146

http://www.capigi.eu 67
http://aerovision.prolific.nl 62
http://capigi.eu 12
http://www.projectbioscope.eu 3
http://projectbioscope.eu 1
http://www.docseek.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • evident
  • Evident: H Object Referencing: the AP-RP concept implemented in PAC is actually breaching INSPIRE recommendation 21 As already mentioned: Lack of structured metadata doesn’t enable a full assessment of individual MS LPIS’s Most of the components are addressed but only in a sporadic manner
  • Evident

LPIS QA formalises mainstream GI  in the CAP LPIS QA formalises mainstream GI in the CAP Presentation Transcript

  •  
  • LPIS and INSPIRE
    • CAP represents a formal EU requirement on GIS in the MS:  LPIS
      • Council Regulation EC 2003/1782 art (20) . The identification system for agricultural parcels shall be established on the basis of maps or land registry documents or other cartographic references. Use shall be made of computerised geographical information system techniques including preferably aerial or spatial orthoimagery, with an homogenous standard guaranteeing accuracy at least equivalent to cartography at a scale of 1:10 000 .
    • 2004 LPIS implementation precedes INSPIRE with > 5 years
      • INSPIRE Directive EC 2007/2 art (1): The purpose … is to lay down general rules aimed at the establishment of the Infrastructure for Spatial Information in the European Community for the purposes of Community environmental policies and policies or activities which may have an impact on the environment .
      • But
      • no mentioning of CAP in recital 11: “ Many initiatives are taken at national and Community level to collect, harmonise or organise the dissemination or use of spatial information .“
    • LPIS is not an explicit INSPIRE ANNEX theme, However;
      • many dependencies on INSPIRE themes: e.g cadastre, topography, land cover, land use, orthoimagery, soil data, elevation, hydrology, restriction/regulation zones,
      • similar needs towards GI technology
      • CAP = major beneficiary of improved data access
  • CAP process is mentioned in documents
    • Generic Conceptual Model http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.5_v3.2.pdf page 91
    •  Only FB / AP LPIS designs respect Recommendation 18
  • GI standards in LPIS
    • INSPIRE relies on the application of GI standards to build an EU SDI from national SDI’s
    • Did GI standards find their way into the LPIS?
    • whereas for LPIS custodians:
      • as data producer: INSPIRE regulatory milestones are not applicable
        • Implementing Rules not yet available
        • Not an explicit theme
      • as data user: too early to benefit from improved access of ancillary data
  • Status on 5/7/2007
    • Data harmonisation components of draft DS-2.5
    • see: http://www.ec-gis.org/Workshops/13ec-gis/presentations/5_environment_II_devos_4.pdf
    Component covered Component partly covered
  • Changes by 4/4/2011
    • Data harmonisation components of draft DS-2.5 v3.3
    Covered in 2007 partly covered in 2007 Covered since 2007 * * * * : changed order
  • GI standards in LPIS
    • YET standards seem to be well introduced
    • Why?
    • Fundamental characteristics differentiate LPIS from an INSPIRE theme :
      • LPIS is designed upon common concepts
      • LPIS supports common procedures
      • LPIS operation is audited
    • A political push to “get things right” focused attention on the LPIS in a quality assurance setup
  • LPIS and INSPIRE theme concepts INSPIRE annex data set 1 common concepts 2 common use 3 common QC existing data sets custom built national data sets  maximum access/distribution/use  maximum data effectiveness no (restrictive) quality specifications well specified quality objectives LPIS spec db spec db spec db spec db spec db spec db spec db at be bg cy se es uk i view - transformation services INSPIRE specific. eu db report spec db spec db spec db spec db spec db spec db spec db at be vl bg cy se es uk en CAP operations spec db be wa db uk ni eu clearance EC 1122/2009 payment control file Aid application
  • So, what’s newly formalised?
    • D: Rules for application schema
    • F: Multilingual and cultural aspects
    • H: Spatial object referencing
    • J: Data transformation
    • L: Registries
    • P: Data transfer
    • Q: Quality
    • T: Conformance
  • D: Rules for Application Schema/Feature Catalogue
    • FC templates provided
    • LPIS Core Model designed (GML Application Schema)
    • Specifications for feature exchange (XML and GML schemas)
    Inspection Measurements (GML) ETS Scoreboard (XML)
  • F: Multi-lingual and cultural aspects
    • Documented ATS and ETS methodology applicable to all MS
      • Supportive documents in national languages
    • Harmonised description of the local “agricultural land” concepts and semantics through the FAO Land Cover Classification System (LCCS) and the Land Cover Meta Language (future ISO 19144-2)
    Common inspection key
  • H: Spatial object referencing
    • “ institutional”
      • 2009R1122 art (6).1“operate at reference parcel level such as cadastral parcel or production block which shall ensure unique identification of each reference parcel”
    • Direct aid process: LPIS parcel is referenced for 3 applications
      • identification (e.g. declaration, performing the CC check)
          • Ideal 1 : 1 spatial object = 1 farmer unit
      • assessing the eligibility value of the identified land (informing the farmer and performing the crosscheck)
          • Ideal 2 : 1 spatial object = 100 % eligible
      • performing the OTSC
          • Ideal 3 : 1 spatial object = 1 crop group
  • H: Spatial object referencing: noise factors
    • What if the area attribute values are determined alphanumerically?
    • Is the reference unit a sub-element of a larger elementary entity?
    • Are several elementary land units aggregated into a larger entity?
    • If third party references are used (cadastral parcels) is there a boundary shift?
    • If third party references are used, are they relevant regarding land at all?
    Formally allowed by the regulations/guidelines under well specified conditions Declaration/ crosscheck OTSC-checks Declaration/ cross-compliance Alphanumeric substraction = X = Subdivision = / V = / X = / V Aggregation X = X Shifted references X = X «irrelevant references » X X X
  • I: Data transformation
    • ATS allows for national model mapping towards LCM (and ETS setup)
      •  Documented workflow
    Mapping of a national LPIS schema to LCM, compilation of an ATS report (source: TUD Final Report to the EC JRC) Basic architecture of a schema transformation process using web services (source: TUD Final Report to the EC JRC) Data transformation services prototype  proven web services : WFS+WPS
  • P: Data transfer
    • Orthorectified imagery available through CID portal and WMS
    • XML and GML schemas designed for all data exchanges
    • Portal: LPIS QA Web Application designed, up and running
    Data exchange process implemented Abstract Test Suite (ATS) Screening Procedures LPIS Implementation Feature Catalogue Application Schema Executive Test Suite (ETS) Random Sample Pre-selection GML XML Orthoimagery WMS 1. sampling 2. reporting 3. screening ATS reporting package XML PDF ETS reporting package XML PDF GML
  • T: Conformance
    • http://marswiki.jrc.ec.europa.eu/wikicap/index.php/GAMMA_0
      • Model conformance: Abstract Test Suite: ATS
      • Data conformance: Executable Test Suite: ETS
    • Standardized approach for GI based on ISO19105 through 2009R1122 art 6.2
    Model and Data conformance testing (ISO19105) Model Conformance: ATS+ICS+EP+W LPIS Feature Catalog App. Schema Data Conformance: ETS Results analysis Conformance test report Data conformance testing procedure documentation transferred
  • O: Quality
    • LPIS data quality measures - compliance with ISO 19113, 19114 and TS19138
    • 3 sets of measures (observations, variant with history test , database query)
    Quality measure documents Inspection work flow
  • ( O) Quality (supportive data)
    • Orthoimagery quality recommendations (inspired by ISO/TS 19138)
      • http://marswiki.jrc.ec.europa.eu/wikicap/index.php/Orthoimage_technical_specifications_for_the_purpose_of_LPIS
    • Guidelines
  • L: Register and registries
    • Catalogue Service Web (CSW): terraCatalog
      •  for the prototype (GeoNetwork - WPS transformation service)
    Proposed service infrastructure for LPIS QA framework (source: TUD Final Report to the EC JRC ) EC MS/user
  • To recapitulate
    • Only 5 / 20 harmonisation components are not (completely) covered within the LPIS community
      • INSPIRE principles (in particular the sharing)
      • Metadata (in particular the publication)
      • Portrayal
      • Multiple representations
      • these 4 components primarily effect the download/viewing aspects
      • Registries
    • 15 INSPIRE harmonization components were addressed due to:
      • the need for a comparable quality report
      • the necessity to exchange experiences among MS for addressing quality issues
  • Lesson learnt
    • Standards bring advantages:
      • better understanding of the systems (also internally)
        • fitness for purpose
        • meaningful indicators on the system quality
      • improved communication between MS
        • harmonization of concepts and definitions
        • interoperability of methods
      • reproducibility of the results
      • more effective guidance
      • extensibility for future
    • but suffer from drawbacks :
      • need to “cross a threshold”, learning curve caused by complexity
        • technical skills
        • management
      • not all standards are fully implemented: emerging tool market
        • WPS in catalogue
        • Multi-surface in GML
      • lack of flexibility ?
  • Thank you for your attention!
  • Intentionally blank
    • INSPIRE Principles: +/-
      • Once stored, maintained at appropriate level: Y
      • Communication across the EC: N  Y
      • Data collected shared by others : N privacy
    • Terminology: +/-
      • Consistent glossary: Regulations EC1782/2003 & EC796/2004  EC73/2009 & EC1122/2009
      • Multilingual via Eurolex,
      • Glossary of Generic Geographic Information: not tested
    • Reference Model: Y
      • Guidelines + working documents + LCM
    • Application Schemas and feature catalogues: +/-
      • On a MS by MS basis  generalised
      • Computer readable data description: N  Y (feature catalogue/application schema in ICS/ATS procedure)
      • Common and correct understanding: Y ?  Y
    • Spatial and Temporal aspects : +/- -  Y - dataflow
    Detailed inventory of change 1/3
    • Multi-lingual text and cultural adaptability: N/A  Yes – ATS-log + Eligibilty profile based on LCCS
    • Coordinate referencing: Y national CRS mandatory + explicited/reported (GML/.prj)
    • Object referencing: Y AP  RP + cardinality of relation
    • Data translation model / guidelines: N/A  Y: ATS
    • Portrayal model: N/A
    • Identifier management: Uniqueness Y, Persistence/Traceability ?  Y
    • Registers and Registries: +/- (EU: N, MS:Y)  EU: Y : LCCS
    • Metadata: +/- (at EU level only ‘standard’ questionnaires)
    • Maintenance: Y  wikiCAP guidelines
      • obligation for farmers to report ‘corrections’, but….
      • 5% on-the spot checks annually, common specification for CwRS
    • Data and information quality: Y acceptable quality level  LQ
      • Creation: spatial requirements
      • Operational: Y (75%/90% rule of art 6.2 Reg 796/04)  ETS for 7 quality elements
    Detailed inventory of change 2/3
    • Data transfer: N/A  Y: portal, GML
    • Consistency between data: +/-  Y (common TS, design dependend “waivers”)
      • caused by different reference parcel sub-type
    • Multiple representations: N
      • single scale level for aid application & control
    • Data capturing rules: Y  eligibility profile
      • common guidelines for all MS
      • Orthoimage quality guidelines
      • photo-interpretation ortho-imagery for creation & CwRS
    • Conformance:  Y regulatory annual ATS+ETS scoreboards
      • Internal: audit of payments validates internal conformance… although with some discussions between MS en EC
    Detailed inventory of change 3/3