News > OGC
News' image preview

Michael Lutz and Athina Trakas decided to spice up the OGC Europe forum slot at the Delft Technical Meeting by asking for position papers around the question “What if we would start implementation of INSPIRE again today?”

Michael Lutz and Athina Trakas decided to spice up the OGC Europe forum slot at the Delft Technical Meeting by asking for position papers around the question “What if we would start implementation of INSPIRE again today?”

Participants of the workshop engage in discussions, Photo by Michael Lutz

More than 40 participants joined the workshop and first of all, saw eight three-minute presentations with a wide range of suggestions:

  • Satish Sankaran (Esri Inc.) asked “What are the right metrics to measure success?”, and suggested that adoption rates could be improved if people could contribute to the infrastructure without requiring full compliance.
  • Paul van Genuchten (GeoCAT) highlighted the potential of INSPIRE linked data as explored in the GeoNovum testbed Geo4Web.
  • Thijs Brentjes (Geonovum) suggested a set of data specifications with a simple base, with no mandatory extensions, built on top of existing (INSPIRE) SDI. He also suggested to use additional encodings with the objective of making INSPIRE usable by web developers.
  • Sylvain Grellet (BRGM) also suggested that adoption would be easier with alternative encodings (SF, JSON, …). He was the first presenter to suggest different levels or labels for compliance. Sylvain also said that joint funding of development should be organised from the start on, instead of leaving everything to the implementers. Sylvain also suggested to better organise aspects such as trainings and hackathons.
  • Clemens Portele (Interactive Instruments) explained how important stability and reliability are for a major infrastructure project like INSPIRE. He suggested to improve specifications through small, iterative changes. It should be possible to make these changes in an agile, fast, usage driven way. He briefly outlined the work done by Geonovum and Interactive Instruments on making data accessible to web applications and suggested to put facades or proxies on top of the existing INSPIRE infrastructure.
  • Thorsten Reitz (wetransform) focused on the user experience of applications built directly to manage and explore INSPIRE data and services and explained that with most of the investment going to backend infrastructure, these leave a lot to be desired would be essential to show the value of the infrastructure.
  • A representative of Natural Resources Canada explained the objectives of the Maps for HTML standards working group and explained that adding capabilities such as MapML would foster usage and adoption.
  • Peter Bauman (Rasdaman GmbH) asked “What if our services could talk?” but wasn’t able to join in person.

These three recurring topics emerged:

  1. tiered or more flexible compliance,
  2. usage of web standards and improvements to data usability and
  3. adding proxy layers on top of the INSPIRE infrastructure.
Participants of the workshop engage in discussions, Photo by Michael Lutz

Following this agenda setting, we split up in four groups to discuss several key questions, using the World Cafe methodology:

  • What standards and technologies should the infrastructure be based on?
  • What architectural pattern would you recommend? What should be the main components of the infrastructure?
  • How would you organise the implementation process and make it cost-efficient?
  • How would you ensure a wide adoption and use of the infrastructure?

Athina and Michael asked me to facilitate the group discussion around the third question - “How would you organise the implementation process and make it cost-efficient?” Our objective was to define 2-3 recommendations and to suggest follow-up actions. As facilitator, I asked the following questions, and a lively discussion ensued:

What is the very first thing that should happen in the implementation process?

  • Define criteria for success early on (not “only” for compliance)
  • Define Interoperability (when is data interoperable -> when it us useable in clients), “General” interoperability isn’t the goal, usage is!
  • Provide end product specifications for high value use cases to large numbers of users
  • Define success for concrete users in addition to the overall objective

If you had one year to implement INSPIRE from scratch, how would you do it?

  • Start with simple data models, manage complexity (necessary vs. unnecessary, e.g. in ISO and metadata), expand over time with new use cases
  • Follow pragmatic approaches
  • Use a well-defined set of interfaces that are already proven (mainstream IT industry)
  • Follow trend in industry towards RESTful mechanisms
  • Focus on pushing data out (e.g. as done in Copernicus)

What is the process to continuously coordinate implementation and make re-use possible?

  • Use agile methods such as iterative development
  • Keep users in close involvement
  • Identify anything
  • Keep existing infrastructure, build agile infrastructure on top, then let the market choose what works
  • Transparency, make it available
  • The metric could be: How many users to you have? Users drive continual improvement?

How can implementation of key components be coordinated in an efficient way?

  • Coordinate development of core components early on, in particular validation and registries (e.g. code lists, extensions)
  • Common components should be coordinated; Harmonisation may be such an issue
  • No mandatory components, but all components for a reference implementation should be available
  • Make sure that requirements that are specific to INSPIRE are really understood well - Value vs. effort/costs on very specific INSPIRE requirements?
  • Clarify the business case for the implementation coordinator - is that organisation paid for by taxes?
  • Countries see lots of liability and low central investment
  • Central funds/investments is low compared to the overall investments required for implementation and compared to COPERNICUS
  • Harmonisation across INSPIRE and Copernicus currently looks like a Godzilla vs. King Kong fight, will be difficult to achieve effectively
Participants of the workshop engage in discussions, Photo by Michael Lutz

We then consolidated recommendations:

  1. We should treat INSPIRE not as separate infrastructure, but rather as integrated with existing products and processes, e.g. by extending national models to meet additional INSPIRE requirements
  2. Cost effective: INSPIRE not as something specific, but as a general infrastructure and be a natural part of what we are doing
  3. We would reframe INSPIRE in the context of the Open Data Movement to limit competition between INSPIRE and Open Data / Linked Open Data
  4. We also make sure products are designed from the user experience first
  5. We have to orient implementation guidance towards implementer’s questions and problems (“How to provide a bridge in INSPIRE” –> can’t be answered by a professional)
  6. Have a library of reference implementations to describe how it’s done for all annexes

… and Follow-Up actions:

  1. Collect reference implementations as concrete guides and publish those
  2. Provide compliance levels (?) as a means to get in easily
  3. Find how to react to new uses cases in an agile way

A side discussion that came up in our group as well as in at least two of the other three groups was what it meant to be compliant really, but I’ll leave that for another post ☺.

All in all, I really enjoyed the highly interactive format of the What if…? Workshop and the productive discussions, which was not just rehashing of previously discussed issues. Thanks to Athina and Michael!

(more)

News' image preview

At wetransform, we’re dedicated to make open standards work for our users and customers. The members of our team have been involved with standardization projects such as CityGML, INSPIRE, 3D Portrayal Services and SoilML at their previous organisations like Esri and Fraunhofer. We want to continue to contribute to effective, open standards.

At wetransform, we’re dedicated to make open standards work for our users and customers. The members of our team have been involved with standardization projects such as CityGML, INSPIRE, 3D Portrayal Services and SoilML at their previous organisations like Esri and Fraunhofer. We want to continue to contribute to effective, open standards.

OCG Meeting

We have therefore joined the Open Geospatial Consortium (OGC) and just taken part in our first Technical Committee (TC) Meeting. We will, in particular, contribute to Smart Cities standardization and we will also work on the actual standardization process and documentation. In both areas, we believe that the data-driven design tools we’re building will help to create better standards, faster.

I joined the 99th OGC TC meeting in Dublin from Monday Evening to Wednesday afternoon. I attended the Europe Forum, the Smart Cities ad-hoc meeting as well as sessions on 3D, such as the CityGML SWG meeting and the 3DIM Domain Working Group’s sessions. Here are a couple of highlights from each of these sessions:

  1. Europe Forum: Michael Lutz (JRC) told us about their development of central tools for validation and conformity testing of INSPIRE data. For this purpose, they are putting a lot of effort into building a complete set of Schematron validation rules, which are now available under https://github.com/inspire-eu-validation. Michael explained that developing the validation rules “was a really valuable exercise to validate and clarify the technical guidance”. I think this is an important insight and think that we should also apply it to the INSPIRE extensions methodology project.

  2. Smart Cities Ad-Hoc: Without doubt, “Smart Cities” is one of the most hyped concepts de jour. Bart de Lathouwer presented a lot of different standardization bodies and projects such as ESPRESSO, FCP1/buildingSmart, ITU-T SG20 and the JTC1/WG11 smart cities working group where the OGC is involved. It seems that everybody wants to make their claim, so there is certainly going to be overlap, over- and underspecification and some general confusion about what we are actually standardizing when we work to build smart cities.

  3. CityGML SWG: One of the big wins that CityGML had was the establishment of their four semantic levels of detail. The concept is realtively easy to understand, and even organisations that don’t implement the format adopt the terminology. However, one of the core goals of the current CityGML 3.0 work is to rework part of the “multiple representation framework”. The main objective is to decouple interior and exterior level of detail. Looks like we’ll have three interior and three exterior levels in the future!

  4. 3D Information Models Working Group: To me, the most interesting presentation was about standards used for simulation and modelling, particularly in the defense sector. In that space groups like the Simulation Interoperability Standards Organisation work to build smaller standards, open systems and architectures which distribute capabilities to lightweight services.

(more)