1st face-to-face meeting 2014-05-28 Paris - Minutes

Agenda

Attendees

Presentations

Usage of GML in Inspire, detected problems and recommended changes

The discussion was introduced by presentations from several of the paticipants (detailed notes on the individual presentations).

The following were recurring topics from the presentations. These are possible topics to be addressed/discussed as part of INSPIRE maintenance and implementation.
  • Proposal of additional simplified schemas, e.g. based on the schema complexity supported by GML SF, level 0
  • Analysis of which GML/XML schema aspects are actually being used in INSPIRE models
  • Maintenance procedures of INSPIRE schemas
  • UML-to-GML encoding rules – implementation
  • How to improve tool support by vendors (e.g. reading GML 3.2.1)?
  • Constraints on geometry types in UML models - is there a need for schematron rules?
  • Documentation / capacity building

In conclusion, a gap was identified between the (complex) INSPIRE schemas and what current tools can support. Two possible solutions were highlighted for this problem: (1) To reduce complexity of schemas for data exchange and (2) to encourage better support by vendors. Both should be investigated.

Reducing complexity

[Proposed action] Work on generic rules that address some of the specific problems identified

  • Create repository of possible simplification rules to be applied
    • Could be based on list of complexity aspects presented by Marie (also Clemens has a more extensive list)
  • Up to thematic communities to decide which rules to apply to each application schema
  • Some recommendations (e.g. aim for SF, level 0, or even simpler) could be overarching
  • Once a simplified schema has been developed in a thematic community, this should be proposed to the MIG
  • After testing and usage documentation, the schema can be endorsed by the MIG (or a specific schema sub-group?)

Encourage better support by vendors

  • It is important to work with vendors to be able to support more complex models and with users to better understand what they can get out of the model
    • There are usually good reasons (e.g. underlying DB technology, costs) for not implementing complex models
    • Also need to find incentives (e.g. INSPIRE compliance certificate) for vendors
  • Possible link to MIWP-5 on validation and conformity testing
  • An analysis could be done on which sub-sets of GML/XSD are actually being used in INSPIRE, e.g.
    • Which themes use only SF, level 0?
    • Which geometry types are used?

Rules for maintenance of the GML schema (introduction by Peter Parslow)

  • Suggestions in wiki of MIG collaboration space
    • Based on OGC schema version numbering
  • Need for clear definitions (see Peter’s slides) of patches, minor, major, backwards compatibility (data vs schema, and vice versa)
  • Changes that break existing implementations and datasets are a problem in INSPIRE --> stability is key!
  • Every change needs to be very carefully managed
  • Don’t punish early adopters!
  • Example of AU update in latest IR amendment – deprecation of NUTS property
  • Solutions (for a new schema) that guarantee that existing data are still valid may break existing client applications (because “new” data may not be compliant to the “old” schema). However, such solutions would be overall less disruptive because there are much fewer INSPIRE clients than INSPIRE suppliers
  • In the HTML-->XHTML transition, a soft schema (less restrictive) and hard schema (more restrictive) in the same namespace were used in parallel – could we use a similar approach?
  • Have different evaluation criteria for different update options and evaluate the consequences for different stakeholder groups

[Proposed action] Start with developing a proposal for the changes made to Annex I models in the IR amendment.

  • Make a proposal for updating the schemas, following an approach that ensures that existing data created according to the old schema and existing implementations based on the old schema remain valid
    • Do not change the namespace for a new minor version of the schema
      • NOTE This would mean a change to the current INSPIRE approach to versioning (based on OGC procedures)
    • Only changes that relax the schema are allowed
  • Define how to communicate changes
    • E.g. what does deprecation mean? What does it mean to be based on an older version?
    • If we keep the namespace the same in a new version of a schema, it is important to communicate that change clearly to all software providers, to make sure that they use the latest version of the schema for validating data! Otherwise they may be using an old schema that will not validate new data.
      • Such software also includes download services, ETL tools, ...
  • Define procedure for testing, review and endorsement
    • Need to involve different kinds of producers (& larger community) --> Have discussions on proposed schema updates in a public space
      • National CPs to alert their communities about this.
  • Develop proposal for reflecting changes (e.g. deprecation) also explicitly in the UML model, so that UML models, diagrams and schemas are kept in sync. and updated schemas could also be generated automatically
    • Also be clearer of what “removing” attributes/classes mean – how much longer are they still valid?

Discussion on the version of GML (introduction by Clemens Portele)

  • Differences between Annex I and Annex II+III schemas
    • Namespaces: URNs vs. http URIs --> just identifiers, no need to harmonise to http URIs
    • Encoding of code list-valued properties --> Propose Union type in the “base” application schema for code list types for Annex I updates
<complexType name="CodeListType">
    <annotation>
         <documentation>...</documentation>
     </annotation>
     <simpleContent>
         <extension base="string">
             <attribute name="codeSpace" type="anyURI"/>
             <attributeGroup ref="gml:OwnershipAttributeGroup"/>
             <attributeGroup ref="gml:AssociationAttributeGroup"/>
         </extension>
     </simpleContent>
</complexType>
  • Use of GML 3.1.1 SF / GML 2.1.2? --> INSPIRE should promote usage of GML 3.2.1
  • MIWP-11/12 wording – which mentions GML 3.3 a lot – needs to be rephrased
    • GML 3.3 constructs will only be used in cases where the additional constructs are needed, not anywhere where 3.2.1 could be used instead. --> no influence on schemas.
    • [Action] Revisit description of task in the WP

Goals of the MIWP, work plan, tasks and responsibilities include rough estimate of efforts for 2014

[Action] JRC to develop work plan for MIWP-11/12/18 based on Workshop outcomes. This work plan should
  • distinguish between (a) short-term actions, (b) longer term actions around approval, (c) development of simplified guidelines
  • propose how actions could be achieved (e.g. through MIG sub-group, contracts, ...)
  • highlight possible funding, e.g.
    • ARE3NA
    • GeoSmartCities – work around BU theme --> could involve simplification of themes
    • eENVplus?
    • ELF --> input could be provided around simplification

GML workshop at the INSPIRE conference

Since Christine will not be able to prepare the workshop, the following was agreed:
  • Use only the Monday 16:00-17:30 session and cancel the 14:00-15:30 one
  • JRC to give a presentation about the issues raised at the workshop and the activities agreed/next steps
    • [Action] JRC to prepare the presentation based on the slides presented at the workshop
  • Present the proposed updates of the Annex I schemas and have a discussion on whether this is the right way forward
    • [Action] JRC to make a proposal for the Annex I schema update
  • [Action] JRC to update the workshop description to reflect this content
  • [Action] All to invite relevant stakeholders (in particular Annex I data producers and tool/application providers) to attend the session

Usage of GML in Inspire, detected problems and recommended changes - Detailed notes

Jan Schulze Althoff (Giger GeoIT), Switzerland

  • Transformation problems
    • Code list URIs
    • Many voidable attributes
    • Geographical names are deeply nested
    • Namespace for inspireIds
  • deegree WFS: complex configuration, but possible
  • Client: QGIS 2.2.0 with WFS 2.0 extension
    • Many attributes are not represented
    • Complex structure not shown
    • nilReason not shown
    • code list values not shown
  • Only few of the GML types are actually used in the schemas
  • Documentation complex: UML models, DS documents, INSPIRE registry, XML schemas, GML specification, ...
  • OCL constraints not reflected in XML schemas
  • Current GIS tools support only limited number of geometric types

Linda van den Brink, Marcel Reuvers (geonovum), Netherlands (presented by Clemens)

  • Circular includes in GML schema documents
    • Problem for code generators
  • Complexity of GML namespace
    • There is modularization but not in the sense of the namespace (just the documents)
  • In NL they use complex models and look at the best exchange standard for distributing national large scale topography to software suppliers
    • CityGML based model (complex like the INSPIRE one)
  • Four exchange standards tested
    • CityGML ADE IMgeo
    • GML 3.2 SF level 0
    • GML 3.1 SF level0
    • OGC KML
  • Software tested (November 2013)
    • PostGIS 2.0
    • QGIS 20.0
    • ESRI ArcGIS 10.2
    • ... other
  • Internal testing (without vendors), results not for publication and anonymized
  • GML 3.1.1 SF well supported, 3.2.1 less supported --> Implementation of standards in software products takes time (GML 3.2.1 is stable since 2006, adopted in 2007)
  • Idea for a GML relay to trigger sw suppliers in supporting GML for INSPIRE
  • Idea for INSPIRE to promote the use of SF-0 more
  • Other formats (GeoJSON, GeoPackage, ...)

Clemens Portele (interactive instruments), Germany

  • Consider additional, simplified encodings (based on SF, level 0 and only one geometry attribute)
    • Not every piece of information would be included
    • Will not cover all requirements, but may be enough for most applications
    • Will be difficult for schemas that are based on complex foundation schemas, e.g. O&M
    • Generation of flattened schemas supported by ShapeChange (http://shapechange.net/transformations/flattener/)
  • XML schema maintenance
    • Make sure that schemas remain valid and supported
    • Changes that break existing implementations should not be called bug-fixes
    • any change needs to be communicated well in advance
    • new schema versions should only be released after testing with real data (D2.6)
    • Involve implementers early
  • MIWP-11 and MIWP-12 descriptions are partly misguided and misleading
    • GML 3.3 schema components are not being used in INSPIRE
    • Most are about simplifying schemas – this is not very clear

Peter Parslow (Ordnance survey), UK

  • UK interoperability assessment plugfest
    • OGC engineering report to be published soon
  • OS hack day: 6 recent / under development products including 3 INSPIRE compliant (HY, GN, EL)
  • Issues
    • Multiplicities >1
    • Hardly any of the tested products actually uses the XSD
    • GML wrapper for grids is not used

Marie Lambois (IGN), France

  • ELF INSPIRE schemas (extended)
    • Used in IGN-F but many mistakes in these schemas
  • Compare what software users can do with INSPIRE data using different sw products (ArcGIS, GeoConcept, MapInfo, QGIS, OpenJump)
  • Different criteria, e.g. complex data types, multiple property values, ...
  • French test data for AD, AU, CP, GN plus some test data from NO (within ELF project)
  • Some sw unable to read GML 3.2.1, other need configuration file to be able (.gfs file for GeoConcept and QGIS, based on OGR/GDAL): need to define *.gfs files and keep implementation as simple as possible
  • Peter mentioned that when talking to the MapInfo product manager, they said they had not had many requests to implement GML 3.2.1 reader, but might be willing to do so if they got more requests from customers --> encourage customers to ask software vendors

Sylvain Grellet (BRGM), France

  • Discussing pure GML issues is not enough. Examples:
    • GeoServer 2.3 on EarthResourceML with xml conformant but performance issues
    • Min4EU: INSPIRE MR spacs extended, planned to use pre-configured deegree
  • Many critical open issues
    • Very few solutions
    • Server: GeoServer 2.5 (not tested) and deegree 3.3 (testing in Min4EU)
    • Client: ?
  • Wish list:
    • Inspire-labeled compatibility matrix
    • Cookbooks (as the UK one on WFS)
    • Lower barriers (example of portrayal class designed in GeoSciML to be SF-0 compliant)
    • Add portrayal classes to INSPIRE will help split from conceptual to exchange and to answer question “what feature to be exposed?”
  • XSD maintenance
    • Permanent EU group has to be set up to coordinate
    • Vendor and open source solutions should point to the schema version they support

Chris Schubert (JRC)

  • Issues of GML
    • Viewer / clients not able to show all content (eg. Codelists)
    • OSGeo out-of-boxes
  • UML-to-GML
    • EA UML and schemas generated by ShapeChange
    • Other initiatives/projects generated their own schemas based on INSPIRE UML
    • JRC should provide ShapeChange configuration to the public
    • Generation of schemas: order of elements (sortedOutput alphabetical), sequence number, order of attributes only per application schema
    • EA PackageControl: update of UML content and their associations is not always reliable (lot of checks needed)

Discussion about reducing complexity

  • Complexity depends on user requirements
    • May need to have both simple & complex exchange models/schemas
    • Maybe only address in this group the complexity that is introduced by the encoding.
    • The discussion about simpler conceptual models should be done in the thematic communities
  • Don’t touch the conceptual schemas, but create additional implementation schemas for simplified use cases
  • Generic simple use case could be: making a map (? ELF) / portrayal
  • Don’t design simplified model simply based on what is currently supported by software – better use requirements from use cases
  • Multiplicity seems to be a problem for many software products
    • ShapeChange flattener uses encoding rules that has a default max. of 3 occurrences of each attribute (can be over-ruled in config or in UML model)
      • Flattening is done in memory
      • Can also be written back to EA to make the flattened model explicit
  • May need domain-specific implementation model
  • Will it be always possible to map from simplified/flattened schema to complex one?
    • Not if some information is omitted in the simplification
  • Will simplified schemas be enough for compliance?
    • Better look at usage of different encodings. This may differ between themes
  • Would also be good to have good examples of simple data
  • Simplified schemas may also help mapping exercise for data providers
  • Also consider the use of the data
    • Directive only talks about downloading and viewing
    • There could be guidelines for naming of sub-sets of datasets, e.g. for Administrative Units of different levels

Attendees

  • Alberto Belussi, University of Verona, Italy
  • Benoit David, Ministry of the Environment, France
  • Chris Schubert, JRC
  • Clemens Portele, interactive instruments, Germany
  • Dimitri Sarafinof, IGN France
  • Jan Schulze Althoff, Giger GeoIT, Switzerland
  • Kent-Jacob Jonsrud, Statens Kartverket, Norway
  • Marie Lambois, IGN France
  • Michael Lutz, JRC
  • Pasquale Di Donato, Federal Office of Topography swisstopo, KOGIS, Switzerland
  • Piergiorgio Cipriano, Sinergis, Italy
  • Peter Parslow, Ordnance Survey, UK
  • Sylvain Grellet, BRGM, France