Data specifications and e-Reporting for the E1b data flow EEA-ETC/ACM | 25-26 of November 2017| 3rd IPR Technical meeting, Copenhagen Data specifications and e-Reporting for the E1b data flow Modelled data and objective estimation

Agenda Recap on reporting models & objective estimation information How to report model & objective estimation methods & data It’s not the same as fixed & indicative measurements Describing your method / technique Reporting your observed / predicted data Revised framework of model configuration flags Plans for handling multiple file formats Examples

Recap on using models & objective estimation Modelled & objective estimation are forms of supplementary assessment data as set out by Articles 6, 7 and 10 of 2008/50/EC Article 4 of 2004/107/EC Guidelines on usage To supplement high quality fixed measurements To improve the spatial coverage of assessments Use as a sole source of information when levels are generally lower & can be assessed using methods with a greater uncertainty budget To support AQ Plans preparation e.g. source apportionment & evaluation senarios

Model & objective estimation types Predictions along a vector / trajectories Roads Railways Rivers Predictions on a regular / irregular grid Raster / gridded data Receptor locations Predictions at a point / polygon Receptor modelling Hot spot modelling Expert judgement Historical trends & emissions inventory analysis Shared / combined measurement time-series NS & WSS contributions

Reporting model & objective estimation data If you are reporting models or objective estimation PLEASE DO NOT report in the D & E1a data flows, these data flows are reserved for fixed & indicative measurements Description of assessment method / metadata delivered in D Modelled & objective estimation observational data / predictions delivered in E1a D data flow E1a data flow

Reporting model & objective estimation data If you are reporting models or objective estimation i.e. anything other than fixed or indicative measurements, you must report with the framework below Description of assessment method / metadata delivered in D1b Modelled & objective estimation observational data / predictions delivered in E1b D1b data flow E1b data flow

Reporting model & objective estimation descriptions D1b for models D1b for objective estimation High-level description of the model in the AQD_Model class Simple description of model domain in the AQD_ModelArea class e.g. a bounding box or point location Summary information on model configuration in the AQD_ModelProcess class using flags to indicate important model inputs & citations to external report(s) on model set-up Simplified high-level description of the model in the AQD_Model class Simple description of model domain in the AQD_ModelArea class e.g. a bounding box or point location Simplified summary information on model configuration in the AQD_ModelProcess class – level of information is more descriptive & can make heavy use of citations of external report(s) on method

New guidelines for reporting & benefits D1b provides a high-level description of how the model has been configured E1b provides the actual configuration information & results Emissions inventory used Meteorology used Chemistry used Interpolation technique used etc. Emissions inventory version Meteorology year Chemistry scheme Interpolation technique e.g. bilinear Data encoding & data formats New guidance on reporting model configuration D1b can be static Reusable for many years Less updating for countries Parameters that will change the results, travel with the results E1b is by definition dynamic & generally needs updating each year

Example model configuration - emissions <ompr:processParameter> <ompr:ProcessParameter> <ompr:name xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/modelparameter/emissions"/> <ompr:description>The emissions inventory used to configure the model including as appropriate the year, version and summary of post processing required</ompr:description> </ompr:ProcessParameter> </ompr:processParameter> D1b declaration <om:parameter> <om:NameValue> <om:name xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/modelparameter/emissions"/> <om:value> NAEI2011 data, scaled forward to 2012 by linear interpolation between 2011 and projected (UEP45) 2012 data </om:value> </om:NameValue> </om:parameter> E1b definition

Example model configuration - meteorology <ompr:processParameter> <ompr:ProcessParameter> <ompr:name xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/modelparameter/meteorology"/> <ompr:description>A description of the meteorological dataset used to configure the model including name, year, version and citation (as appropriate)</ompr:description> </ompr:ProcessParameter> </ompr:processParameter> D1b declaration <om:parameter> <om:NameValue> <om:name xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/modelparameter/emissions"/> <om:value> Waddington met station for 2012 (data acquired from the Met Office). Other met sites may be used for more detailed modelling studies where the national scale modelling/monitoring highlights potential problems</om:value> </om:NameValue> </om:parameter> E1b definition

Handling multiple data types Multiple possible data types are numerous Conceptual data types we can expect Regular grids Irregular grids Points Polygons Vector / trajectory data 3-dimensional arrays Multiple possible data formats are numerous

Handling multiple data formats Focus on familiar, common external encoding formats for 2017 Vectors / trajectories External - Shapefile Inline - GML Regular / irregular grids External – ascii-grid, GeoTiff, NetCDF, WCS Inline – GML Coverage Points / Polygons External – Shapefile Inline – SWE array Remote measurements E1a ESRI shapefile (points, line & polygons) ASCII GRID for regular grids GeoTiff for regular grids SWE data array for simple cases Possible to extend to inline encodings - GML coverage, NetCDF, WCS etc. in the future (not a priority for 2017).

Encoding in the E1b XML deliverable Very similar to E1a reporting E1a framework has been extended using model specific content flags via the om:parameter class om:parameter is used to define important content e.g. model inputs data, configuration, result location etc. This framework supports data harvesting needs & QA checks

Encoding in the E1b XML deliverable Result encoding / location flags <om:parameter> <om:NamedValue> <om:name xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/processparameter/resultencoding"/> <om:value xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/resultencoding/external"/> </om:NamedValue> </om:parameter> <om:name xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/pocessparameter/resultencoding"/> <om:value xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/resultencoding/inline"/>

Encoding in the E1b XML deliverable Result file format flags <om:parameter> <om:NamedValue> <om:name xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/processparameter/resultformat "/> <om:value xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/resultformat/ascii-grid"/> </om:NamedValue> </om:parameter> <om:value xlink:href="http://dd.eionet.europa.eu/vocabulary/aq/resultformat/swe-array"/>

Encoding in the E1b XML deliverable External result file declaration <gml:File> <gml:rangeParameters> <swe:Quantity definition="http://dd.eionet.europa.eu/vocabulary/aq/aggregationprocess/PY1"> <swe:label>annual mean</swe:label> <swe:description>annual mean at background locations on a 1x1km regular grid</swe:description> <swe:uom xlink:href="http://dd.eionet.europa.eu/vocabulary/uom/concentration/ug.m-3"/> </swe:Quantity> </gml:rangeParameters> <gml:fileReference>http://cdr.eionet.europa.eu/gb/eu/aqd/e1b/envvfbicq/no2_ameanbk_osgb.tgz#VALUE</gml:fileRefe rence> <gml:compression >LZ77</gml:compression> /gml:File>

Encoding in the E1b XML deliverable Inline SWE data array results for expert judgement or objective estimation results Single SWE record for whole domain provide in E1b <om:result> <swe:DataArray> … <swe:encoding> <swe:TextEncoding decimalSeparator="." tokenSeparator="," blockSeparator="@@"/> </swe:encoding> <swe:values>2012-01-01T00:00:00Z,2012-12-31T23:59:59Z,3,1,<10@@</swe:values> </swe:DataArray> </om:result> Model/method descriptor provided in D1b (AQD_Model) Model/method domain described in D1b (AQD_ModelArea) Model/method configuration described in D1b (AQD_ModelProcess)

Encoding in the E1b XML deliverable Don’t forget your spatial reference system information Where the external file is in a proprietary or open GIS file format e.g. Shapefile or an open alternative e.g. ASCII grid or GeoTiff, it is mandatory to include information on the spatial reference system applicable as part of a projection file (.prj), world file (.twf) or similar. All spatial reference systems declared in D1b, E1b & in any external .prj or .twf files must be internally consistent in order to pass QA

Encoding in the E1b XML deliverable What are the benefits? The D1b & E1b reporting framework enables XML deliveries to be easily checked with QA Facilitates harvesting into a data store Facilitates cross checks against Attainment statement in data flow G

Questions & Answers EEA-ETC/ACM contact: Tony Bush Director of Apertum Consulting m. +44 7431 382 074 e. tony.bush@apertum.co.uk skype. tony_bush1