1 / 16

E-reporting: road to implementation

E-reporting: road to implementation. Patrick van Hooydonk European Topic Centre on Air pollution and Climate change Mitigation (ETC/ACM) 5 th pilot meeting Copenhagen, 24-25 may 2012. E-reporting: road to implementation point of view from an ETC data collector.

katen
Download Presentation

E-reporting: road to implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. E-reporting: road to implementation Patrick van Hooydonk European Topic Centre on Air pollution and Climate change Mitigation (ETC/ACM) 5th pilot meeting Copenhagen, 24-25 may 2012

  2. E-reporting: road to implementationpoint of view from an ETC data collector • Ideal situation AQD reporting • Current implementation • Challenges • Conclusions 5th pilot meeting e-reporting

  3. E-reporting:road to implementationOverview procedure ideal situation Update AQD report Report Agreement(Commission decision: WHAT) Report Agreement(AQD schemata: HOW) Valid Complete AQD report Historical AQD storage INSPIRE Check AQD report OpenGIS generate AQD report Country AQD storage Complete AQD report Report status AQ Status AQ Europe

  4. E-reporting:road to implementationOverview procedure ideal situation Report Agreement(Commission decision: WHAT) Report Agreement(AQD schemata: HOW) Historical AQD storage ? INSPIRE OpenGIS (to be updated) Country AQD storage (to be updated)

  5. Schemata meeting both guidance as well as INSPIRE/OpenGIS requirements Uniform structure for all AQD reporting Not possible to enforce all dedicated Guidance restrictions Definition of structures are combination of dedicated and global structures: lack of transparency E-reporting: road to implementationimplementation AQD-schemata(1) Advantages Disadvantages

  6. E-reporting: road to implementationimplementation AQD-schemata(2) Structure according INSPIRE/OpenGIS Structure according Guidance Implementation AQD schemata

  7. E-reporting: road to implementationchallenges Challenges for getting valid and complete AQD report: • Aligning AQD schemata with the Guidance • How to generate a AQD report according the AQD-schemata • How to ensure that the AQD report is checked on quality, completeness and according the defined XML-format 5th pilot meeting e-reporting

  8. E-reporting: road to implementationAligning AQD-schemata with the Guidance What are the problems: • Mandatory fields do not have to be reportedExamples: • Geometry (minOccurs=0) in AQD_Station (location of station does not need to be reported) • Procedure (minOccurs=0) in AQD_SamplingPoint (link to procedure/method does not need to be reported) • Fields can not be checked on defined code listExample: • ObservedProperty (nillable=true) in AQD_SamplingPoint (link to pollutant can be any string value, even empty) How to solve? • Define additional restrictions for specific fields • Implement additional checking to ensure correct XML-reports 5th pilot meeting e-reporting

  9. E-reporting: road to implementationHow to generate a AQD report according the AQD-schemata What are the problems? - XML structure is difficult to determine because of: • implementation of AQD-schemata is based on definitions on different levels (difficult to find the detailed definition) • Use of global identifiers (difficult to detect what is meant to be reported) • Irrelevant fields are obliged to fill in ( Example: in AQD_Process timeCoverage and dataCapture have to be filled although these are related to an observation) 5th pilot meeting e-reporting

  10. E-reporting: road to implementationWhat are the problems?: definitions on different levels AQD-schemata implemented in XSD-format: link with general XSD’s: • AQD: • Feature definitions (Station, Network, SamplingPoint, Process, AssessmentRegime, ..) • INSPIRE: • Base definitions (BaseTypes) • Area management (am) • Reporting units (am-ru) • EnvironmentalMonitoringFacilities (ef) • OpenGis: • Observations (om) • Results(detail of Observation) (swe) 5th pilot meeting e-reporting

  11. E-reporting: road to implementationWhat are the problems: Use of global identifiers (1) Definition of results in Observation may be reported in several ways like: • BlockComponents: (DataArray, Matrix, DataStream) • RecordComponents: (DataRecord, Vector) • AdvancedEncodings: (Block, BinaryEncoding, Component) This means that every data supplier may chose which way of reporting their Observation data is convenient. For processing the results it will be necessary to define additional restrictions how we report the different types of observations (measurement data, aggregated data, model data) 5th pilot meeting e-reporting

  12. E-reporting: road to implementationWhat are the problems: use of global identifiers(2) Link from SamplingPoint to Station: <element name="broader" type="ef:HierarchyPropertyType" minOccurs="0"> <annotation> <appinfo> <reversePropertyName xmlns="http://www.opengis.net/gml/3.2">ef:narrower </reversePropertyName> </appinfo> </annotation> </element> Link from Observation to Pollutant: <element name="observedProperty" type="gml:ReferenceType" nillable="true"> <annotation> <appinfo> <gml:targetElement>xs:anyType</gml:targetElement> </appinfo> <documentation> The association Phenomenon shall link the OM_Observation to the GFI_PropertyType (C.2.2) for which the OM_Observation:result (6.2.2.9) provides an estimate of its value. The property type has the role observedProperty with respect to the observation. The observed property shall be a phenomenon associated with the type of the featureOfInterest. NOTE An observed property may, but need not be modelled as a property (in the sense of the General Feature Model) in a formal application schema that defines the type of the feature of interest The observed property supports semantic or thematic classification of observations, which is useful for discovery and data fusion. </documentation> </annotation> </element> 5th pilot meeting e-reporting

  13. E-reporting: road to implementationHow to generate a AQD report according the AQD-schemata What are the problems? - XML structure is difficult to determine because of: • implementation of AQD-schemata is based on definitions on different levels (difficult to find the detailed definition) • Use of global identifiers (difficult to detect what is meant to be reported) • Irrelevant fields are obliged to fill in ( Example: in AQD_Process timeCoverage and dataCapture have to be filled although these are related to an observation) How to solve? • Determine the irrelevant fields and find a solution by adjustments in structure and/or define default values • Create detailed documentation in which a clear definition is presented for all elements in the AQD Schemata 5th pilot meeting e-reporting

  14. E-reporting: road to implementationHow to generate a complete and correct AQD report What are the problems? • Checking completeness of AQD-report • When is a report complete since the format supports partial reports (for example: only zones, observations or samplingpoints) • How to detect whether a newly reported SamplingPoint is an update or a correction? • Threats of inconsistent reporting although it is according the definitions in AQD schemata: • Meaningless identifiers (example: INSPIRE identifier: string value) • Missing/inconsistent links to essential meta information (links to stations/networks are defined as string value) • (too) large variety in reporting observation data How to solve? • Perform additional checking to ensure inconsistency/incompleteness using historical AQD storage • Facilitate an interface for quality checking • Facilitate an interface for generating a correct XML-report to ensure meaningfull identifiers and correct links to essential meta data 5th pilot meeting e-reporting

  15. E-reporting: road to implementationconclusions • For implementation of AQD-reporting there are the following challenges: • Solve inconsistencies between agreements AQD reporting and implementation • Ensure completeness and quality of the AQD reporting • Proposed solutions: • Detailed documentation of the AQD reporting implementation • Determine the irrelevant fields and find a solution by adjustments in structure and/or define default values • Facilitate a User Interface to ensure completeness and quality of the AQD data and to generate the requested XML exchange format 5th pilot meeting e-reporting

  16. THANK YOU FOR YOUR ATTENTION 5th pilot meeting e-reporting

More Related