INSPIRE Thematic Clusters

AC-MF Default encoding in TG

152 Views

AC-MF Default encoding in TG

Started by Ilkka RINNE Replies (5)

Hi,

I just noticed the default encoding of the AC-MF datasets in the TG AC-MF v3.0 is a bit confusing if not entirely wrong:

9.3.1.2. Default encoding(s) for application schema Atmospheric Conditions and
Meteorological Geographical Features

Name: Atmospheric Conditions and Meteorological Geographical Features GML Application Schema
Version: 3.0,
Specification: D2.8.III.13-14 Data Specification on Atmospheric Conditions and Meteorological Geographical Features – Technical Guidelines
Character set: UTF-8 

All the AC-MF data offered using INSPIRE Download Services must follow this GML Application
Schema for encoding the Observation instances within the feature collection results of the Get Spatial
Objects operations.


The xml schema document is available on the INSPIRE website http://inspire.ec.europa.eu

As we all probably know, the AC-MF does not really define any data model or XML Schema of it's own, it used the O&M TG SpecialisedObservations directly. There is an XML Schema file at https://inspire.ec.europa.eu/schemas/ac-mf/4.0/AtmosphericConditionsandMeteorologicalGeographicalFeatures.xsd but it's only a placeholder, and defines no schema types or elements (it does not even import the SpecialisedObservations namespace from https://inspire.ec.europa.eu/schemas/omso/3.0/SpecialisedObservations.xsd, only the INSPIRE base!).

This is probably just an error in the TG document that should be fixed.

Replies

    • Public

    By Katharina SCHLEIDT

    Hi Ilkka,

    The same strangeness also applies to OF, also just provides a schema stub including the base types (probably a default in the Shapechange configuration used). In the marine domain we do have Sea Regions providing relevant features; however OF and SR seem semi-disjunct, with no clear guidance to interlinkages (also towards EF, for more, see https://themes.jrc.ec.europa.eu/discussion/view/177682/ef-and-referencing-other-inspire-themes)

    To my understanding the difference between the atmospheric and oceanographic bits are that in oceanography, agreed upon physical regions exist, whereas in meteorology, there are no persistant physical features (we have had some interesting meteo discussions on if the geometry carrying feature couldn't actually be provided as a result, i.e. the location of a cloud of radiation. Interesting approach for such an "ethereal" domain, but currently just thoughts).

    What's also missing is the tie-in to EF; while AC/MF and OF point to the specialized observations, many people do not realize that the provision of information on the EF that made these observations is also required (its implicitely logical based on available data and INSPIRE requirements, but nowhere explicitly stated)

    But, back to your original question - while I'm not really happy with the way it currently stands, I'm also not quite sure how to make it better. While we could replace the inclusion of INSPIRE base with the specialized observations, it seams easier to just directly rely on the specialized observation schema available under the INSPIRE omso namespace. On a non-technical level, we can provide information on how to do this right. On a technical level - well, quite open for your thoughts!

    :)

    Kathi

    • Public

    By Keiran MILLARD

    Would you like the history on why we are where are?

    Back in the very, very early days of Inspire we had SR, OF, MF, and AC.  There was one sentence that defined their scope and an objectives to write technical guidance for each.  These ‘one sentence scopes’ were quite abstract therefore also was the difference between SR and OF for example.

    In the marine domain we took the approach to ensure a clear distinction between SR and OF (different use cases).  In the atmospheric domain the opposite approach was taken and the two themes were merged.  One thing that was recognised was that both OF and MF were essentially describing observations so it was agreed to do this in the same way using O&M.  Unfortunately there wasn’t time to agree (because it wasn’t mature enough) what this O&M implementation would look like, beyond the stubs for the specialized observation types.

    There was then a particular activity that looked at developing O&M in Inspire that lead to (a) an update of the GCM to include a common approach to coverages and also (I believe) realization of the EF data specification we now know and love.  However, the OF and AC-MF data specifications were not updated.  The intent was, I believe, to rely on the specialized observation schema available under the INSPIRE omso namespace as you suggest.

    Keiran

     

    • Public

    By Keiran MILLARD

    A more radical suggestion.

    My understanding was that in its original incarnation EF did not consider the results of observation - just the description of the observation process/activity/facility.  I say 'just' - but a data set of EMF's is actually very valuable and in my opinion one of the most important Inspire themes.  The observation themselves were to reside in their respective themes.

    Now, with EF describing the same coverages as OF, do we need a distinct OF theme?  Or do we just need a better way of describing the way observed oceanographic data is described by EF (an EF annex). The same could apply to any theme that is primarily dealing with observational/sampled data.  If this was done in a modular way it would also allow other thematic observations to be included that are currently 'theme-less', e.g. timeseries of flow at river gauging stations (not part of HY).

    If there was just the one specification it would make service deployment easier, and potentially simplify Inspire to data providers also.

     All the best

    Keiran

     

    • Public

    By Katharina SCHLEIDT

    Hi Keiran!

    Many thanks for digging to the roots if this issue! :)

    Some more history to complete the picture:

    In EF, we had a similar but at the same time opposite problem. We also had the ominous few lines from the directive, responsibility for environmental monitoring facilities across ALL media, and the issue of if "includes observation and measurement" really means the actual data in addition to the classic spatial stuff. The EF Spec is seen as vague by some, but it had to support all types of observations and measurements, ranging from sensors to biodiversity observations by humans to satellite observations. We saw that some themes included observational data within their scope, while other environmental domains such as air quality remained themeless.

    As we saw that some of the other themes also included this observation and measurement data, and wanted to avoid that each of these themes did their own thing, we badgered JRC until they set up the X-TWG to assure a common approach for O&M stuff [correction to above where you state coverages] with members from EF as well as other interested data themes, foremost the OF and AC-MF groups; this lead to the observational model in the GCM. It was a mad dash to get everything coordinated across themes, just in time finalization of the central O&M specs jointly with the various thematic dataspecs. I remember the final version of the coverage specs in the GCM (different group, led by Peter Baumann) were finally finalized just as we finalized our parts, I really wanted to take a good look at all our specialized observations in light of this, but just no longer had the time.

    All things considered, I believe we did a good job considering the possibilities, but as you state, there are quite a few things that could/should be done differently. Now that the concept of providing measurement data within the scope of an SDI has settled a bit, I also believe it would be worth revisiting some of these issues; this is also highly relevant in light of both the coverage models that we never fully integrated into the observational models, as well as other newer developments such as TimeseriesML (it's always bothered me that the atmospheric models require inclusion of WaterML 2.0!). As I've identified quite a few other glitches with the provision of specialized observations under INSPIRE (see my various posts over the last few months), I'm very much hoping that JRC will allow us the opportunity to fix at least some of the more pressing issues hindering data provision!

    :)

    Kathi

    • Public

    By Ilkka RINNE

    Kathi & Keiran,

    Thanks for the review of the history of the OF & AC-MF TGs. As a member of the AC-MF TWG, I remember the busy times bringing it all together.

    Don't know about the OF, but at AC-MF TWG we are well aware of the O&M TG work lead by Kathi, and decided to use the OMSO schema as-is as our data model. This is why I'm surprised to still find that the actual default encoding statement still refers to the AC-MF Schema.

    The OF 3.0 TG actually does this a bit better, even thought the reference is made to the OF TG:

    Default encoding
    Name: Specialised Observations GML Application Schema
    Version: version 3.0,
    Specification: D2.8.III.15 Data Specification on Oceanographic geographical features – Technical
    Guidelines
    Character set: UTF-8
    The xml schema document is available on the INSPIRE website http://inspire.ec.europa.eu

    IMHO both the OF & AC-MF TGs should contain the following default encoding instead:

    Default encoding
    Name: Specialised Observations GML Application Schema
    Version: version 3.0,
    Specification: D2.9 Guidelines for the use of Observations & Measurements and Sensor Web Enablement-related standards in INSPIRE
    Character set: UTF-8
    The xml schema document is available on the INSPIRE schema repository at https://inspire.ec.europa.eu/schemas/omso/3.0/

    As this is already implied in both specs, does not change any of the requirements, and clears the contradiction at least in AC-MF TG, this should be done as a corrigendum.