CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Copyright ©2013 EuroGeographics Supporting INSPIRE implementation: the Thematic Clusters for topographic and cadastral reference data 28 May 2015 ISN

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Examples of implementation topics Extension of INSPIRE schemas

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Context When developing new products, data producers generally want to be “close to” INSPIRE Data producers may have more data than in INSPIRE data models

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Option 1: free adaptation of INSPIRE Advantages – Free adaptation; no constraints Drawbacks – 2 services to be set up – INSPIRE data used only for pan-European or X-border applications INSPIRE adapted model New data (easy) transformation process INSPIRE data European users Transformation process (?) National users National product Interoperability poorly achieved

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Option 2: extension of INSPIRE Advantages – No transformation required – Only one service to be set up – INSPIRE data used by all users Drawbacks – Constraints on extended model INSPIRE extended model New data INSPIRE data European users National users

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Extension of INSPIRE: brakes Code lists and enumerations – Context: Enumerations and some INSPIRE code list are not extensible General case for Annex I themes => issue for making extended INSPIRE schemas – Example 1: VerticalPosition INSPIRE model « code list » VerticalPositionValue onGroundSurface suspendedOrElevated … underground …. Potential request for change Enumeration -> hierarchical code list (extension « narrower ») More generally, review extensibility of Annex I code lists

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Extension of INSPIRE: brakes Example 2: ServiceTypeValue – INSPIRE Restricted scope (theme US) – restricted to management of environmental issues; » Education » Health » Security » … – Culture and sport facilities excluded Code list only “narrower” extensible – But more information in some existing data user requirements (ex: POI for Eurostat) FeatureImportance Hospitals [1] [1] Mandatory Primary Schools (ISCED [2] 1) [2]Mandatory Secondary schoolsHigh UniversitiesHigh Emergency medical servicesHigh Disposal sites and landfillsHigh Police stationsMedium EmbassiesLow Government buildingsLow LibrariesLow Sport stadiums and facilitiesLow CinemasLow Concert hallsLow Cultural centresLow MuseumsLow OperasLow Other event facilitiesLow Postal officesLow Recreation facilitiesLow TheatresLow ……Low Excluded from INSPIRE Eurostat POI

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Extension of INSPIRE: brakes Validation – Data producers are unsure about validity of data according to INSPIRE extended schema – In theory, extending INSPIRE data models according to Generic Conceptual Model is fine – But, in practice: will validation tools validate data against extended schema? – May depend on tools? who will ensure that rules of GCM have been respected?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Extension of INSPIRE: brakes Example – INSPIRE context Data specifications (TN) : Runways must be represented as areas Generic Conceptual Model : “ Extending an INSPIRE data specification would imply at a minimum that: – the extension does not change anything in the INSPIRE data specification but normatively references it with all its requirements – the extension does not add a requirement that breaks any requirement of the INSPIRE data Specification » – Existing data (ERM – 250K) Runways are (logically) represented by lines => extension includes additional feature type « RunwayLine » – Is it correct to extend INSPIRE schema in this way?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Topics for discussions Have you tried to extend INSPIRE schemas? – For which purposes? – Which issues ? Solutions? Is INSPIRE influencing design of new products? How? – Formal extension of INSPIRE schemas? – Adaptation of INSPIRE schemas? Principles, purpose, …? What MIG should do? – facilitate extensions of INSPIRE data models? – …?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Examples of implementation topics Flattening of logical model?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE General context INSPIRE models use complex modelling patterns – Complex attributes (data types) – Undefined multiplicity [1..*] or [0..*] – Generic geometry (GM_Object, GM_Primitive) – Linear referencing (TN) – … that can be handled by GML but not by classical GIS formats

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Issues GML is an exchange format not a working one – Huge volume of data – But due to complexity of INSPIRE models, no easy export to other (working) GIS formats Lack of client applications for INSPIRE data – Several surveys done by data producers => poor results INSPIRE data not accepted at all INSPIRE data accepted but lack of information, difficult to handle, …

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE ELF context NMCA data NMCA data NMCA data NMCA data transformation INSPIRE GML data Edge- matching Quality validation Change detection Generalisation BaseMap ELF GML data …. Geo tools Applications Most geo tools and applications can’t use GML => adopt a common simplified logical model?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE ELF investigation To “simplify” the complex INSPIRE modelling patterns, several options are generally possible: – Multiple values of attribute Flatten model Relational model

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE ELF investigation The options to be chosen depend on the software (client application) – Multiple values of attribute Flattening options : nice for basic GIS Relational option: acceptable for DBMS – Generic geometry (GM_Object, GM_Primitive) May be kept in one feature type : PostGre/PosGIS Has to be split into several feature types (point, line, surface): ESRI – …

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE ELF investigation The options to be chosen depend on the use case – Content : need to keep whole content? => keeping whole potential content of INSPIRE may lead to huge number of “flatten” attributes (e.g. GN) – Structure

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE ELF investigation Examples: Heterogeneous requirements No common simplified logical model in ELF (until now) Change detectionGeneralisationBaseMap ContentWhole content Simplified content Flat / Relational Flat TN propertiesTo be kept as feature types To be transformed into attributes (at least those used in decision process) To be transformed into attributes

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Main findings INSPIRE GML data – Is interoperable – But not (easily) usable by tools It looks very difficult to have a common logical model adapted to all use cases, to all client applications and keeping all potential INSPIRE data A logical model that is usable by tools may be not so “simple” for users (e.g huge number of attributes or of relations) Communities may develop their own logical models that might be recognised (i.e. registered) by MIG – => several logical models for same conceptual one – Lack of interoperability ?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Topics for discussions Have you found client application for INSPIRE data? Have you found other means to facilitate use of INSPIRE data? What MIG/ARE3NA should do: – Propose official “simple” logical model(s)? Which options? – limited content acceptable? – …. – Push software editors to upgrade their tools? Fund open-source tools? – Other solutions?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Examples of implementation topics Temporal aspects

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Theory: INSPIRE mechanism for incremental updates Most of INSPIRE data models include:  Inspire identifier – unique – persistent  Temporal attributes related to the data base life-cycle – beginLifespanVersion – endLifespanVersion Users can get incremental updates (e.g. evolutions between t 1 and t 2 ) just by querying on temporal attributes  beginLifespanVersion after t 1 and before t 2  to get new (created) objects or new versions of modified objects  endLifespanVersion after t 1 and before t 2  to get old (deleted) objects or old versions of modified objects Versioning of objects

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Practice: many issues Unique and persistent Inspire identifiers – Local identifier Persistent identifiers missing in source data Persistent identifiers lost during the transformation process » Split features » Merge features Additional identifiers required by transformation process, e.g. When transforming attribute to feature type – TN properties – AD components – Namespace Recommendation to use http URI How to ensure domain persistency?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Practice: many issues Temporal attributes May be missing in source data May be no longer reliable due to transformation process – More data in source than in INSPIRE » Overdetections – Main source data + ancillary data to fill INSPIRE (e.g. by joining tables) » underdetections Many data producers deliver only valid data (by regular releases) but do not give access to historical data => Users can’t get information about old /deleted objets

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Topics for discussions Do you have implemented delivery of incremental update for INSPIRE data? – With INSPIRE mechanism or with other solution? Have you met issues to ensure unique and persistent identifiers for INSPIRE data? Are you implementing identifiers as http URI? Do you provide temporal information for INSPIRE data? – beginLifespanVersion? – endLifespanVerson? Anything MIG should do about temporal aspects?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Examples of implementation topics Big objects

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE What is ”big” object Definition: large real world entity represented at large scale – High level AU (country), StandingWater (lake) – Road,Watercourse,...

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE What are the issues? Issue 1 : data volume – object ”big” by its number of vertices – => big number of coordinates couples (2D data) or triples (2,5D data) – => big volume of data – => object difficult to handle and to transfer When does it occurs? – Objects defined by direct geometry – Ex: country (AU), big lake (StandingWater in HY)

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Issue: – For large scale data, most users interested in level 3 (département) and lower levels – Download by predefined data sets Does not look relevant to provide levels 1 and 2 in all predefined data sets – Direct access (WFS) User may forget to select AU levels and get data (country, region) they do not want What are the issues? Issue 2 : deliver more data than expected by users Commune Arrondissement Département Région Etat 1 ts Level 2 nd Level 3 rd Level 4 th Level 5 th Level

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE What are the issues? Issue 3 : deliver no data at all – Aggregate objects defined by their components Road A = set of road links {1, 2, 3, 4, 5, 6, 7, 8} User request by bounding box -Will get only road links 2, 3, 4, 5 -Will the client application be able to build the road A only from this limited set of road links -Yes? -No?

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE What is potential solution? Potential solution (request for change in INSPIRE) – For upper levels AU that may be derived from lower ones, offer choice Provide geometry or Provide association from the lower level Model ”big” objects from ”small” ones – Indirect geometry – Link from small to big RoadLinkRoad Users may reconstruct « big » objects according to their needs Geometry: GM_Curve

CONNECTING YOU TO THE AUTHORITATIVE GEO-INFORMATION FRAMEWORK FOR EUROPE Topics for discussions Have you also met issues when transforming and serving “big” objects? – Which kind of issues? – Which data? Themes? – Potential solutions? Would you be in favour of changes in INSPIRE data models?