INSPIRE Thematic Clusters

OF or SR for a list of elements on the Sea Bottom?

44 Views
  • Public

OF or SR for a list of elements on the Sea Bottom?

Started by Nicolas de Ville de Goyet Replies (11)

Hello everyone,

 I’m currently working on the MSFD (Marine Strategic Framework Directive) reporting of 2018. Although it is not mandatory before 2020, I try to create INSPIRE compliant datasets to learn and create good practices.

In the recommendation published by the European Commission DG Environment for the publication of datasets under MSFD article 19(3) they suggest to publish the data corresponding to criteria D6C1 (Spatial extent of loss of seabed) in the theme Sea Region (SR) or Oceanographic geographical features (OF).

The dataset is a list of all the elements present in the sea bottom (cables, posts, wrecks,…) with their geometry. I try first with the OF schema where each element is described as a PointObservation and is part of a PointObservationCollection. Here under is an example of one of the PointObservation:

  <gml:featureMember>

    <omso:PointObservationCollection gml:id="OM.PointObservationCollection.D6C1_Physical_Losses">

      <gml:metaDataProperty xlink:href="http://metadata.naturalsciences.be/3d887763-9ab1-4207-9f7b-46e457541391"></gml:metaDataProperty>

      <gml:identifier codeSpace="http://inspire.ec.europa.eu/ids">http;//spatial.naturalsciences.be/OM/PointObservationCollection/D6C1_Physical_Losses</gml:identifier>

      <omor:inspireId>

        <base:Identifier>

          <base:localId>OM.PointOservationCollection.D6C1_Physical_Losses</base:localId>

          <base:namespace>be.rbins</base:namespace>

          <base:versionId>2018-07-27T 12:00:00</base:versionId>

        </base:Identifier>

      </omor:inspireId>

<omor:member xlink:href="#OM.PointObservation.D6C1_Physical_Losses.PL_Measuring_Piles_and_Radar_Stations.MOW_2_Appelzak"></omor:member>

    </omso:PointObservationCollection>

  </gml:featureMember>

 

<gml:featureMember>

    <omso:PointObservation gml:id="OM.PointObservation.D6C1_Physical_Losses.PL_Measuring_Piles_and_Radar_Stations.MOW_2_Appelzak">

      <gml:metaDataProperty xlink:href="http://odnature.naturalsciences.be/mumm/" xlink:title="Koninklijk Belgisch Instituut voor Natuurwetenschappen (KBIN), Operationele Directie Natuurlijk Milieu (OD-Natuur), Beheerseenheid Mathematisch Model van de Noordzee (BMM)"></gml:metaDataProperty>

      <gml:identifier codeSpace="http://inspire.ec.europa.eu/ids">http://spatial.naturalsciences.be/D6C1_Physical_Losses/PL_Measuring_Piles_and_Radar_Stations/MOW_2_Appelzak</gml:identifier>

      <gml:name>MOW_2_Appelzak</gml:name>

      <gml:location>

        <gml:Polygon gml:id="_514acce1-b8f0-4309-9a95-3db84ab57dce" srsName="http://www.opengis.net/def/crs/EPSG/0/3035" srsDimension="2">

          <gml:exterior>

            <gml:LinearRing>

              <gml:posList>3160559.553562563 3854423.404113588 3160562.6796959047 3854423.2121156845 3160565.59353598 3854422.0647828025 3160568.009855852 3854420.074423859 3160569.692129287 3854417.4358690255 3160570.475683632 3854414.4073984055 3160570.2838191064 3854411.2854597904 3160569.135316715 3854408.3756502853 3160567.142599855 3854405.962802339 3160564.5007295366 3854404.2831023484 3160561.4683104204 3854403.500971077 3160558.3421768695 3854403.6929690004 3160555.4283366445 3854404.8403020212 3160553.012016731 3854406.8306611674 3160551.3297433774 3854409.4692161917 3160550.5461892113 3854412.4976869165 3160550.7380539435 3854415.6196255116 3160551.8865564903 3854418.529434879 3160553.8792733913 3854420.942282622 3160556.5211436367 3854422.6219824227 3160559.553562563 3854423.404113588</gml:posList>

            </gml:LinearRing>

          </gml:exterior>

        </gml:Polygon>

      </gml:location>

      <om:phenomenonTime xlink:title="http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unknown"></om:phenomenonTime>

      <om:resultTime>

        <gml:TimeInstant gml:id="_fc6a2412-a17c-44e0-8094-6a444411462c">

          <gml:timePosition>http://inspire.ec.europa.eu/codelist/VoidReasonValue/Unknown</gml:timePosition>

        </gml:TimeInstant>

      </om:resultTime>

      <om:procedure xsi:nil="true"/>

      <om:observedProperty xlink:href="http://inspire.ec.europa.eu/featureconcept/Pole" xlink:title="Pole"></om:observedProperty>

      <om:featureOfInterest xsi:nil="true"/>

      <om:result>Pole</om:result>

    </omso:PointObservation>

  </gml:featureMember>

But some questions remains:

  • Where should I put the geometry of each element? What is exactly the difference between FeatureOfInterest and location?
  • I have the following error message in the ETF validator although I use the value “unknown” from the VoidReasonValue codelist. How should it be coded??

The following properties of the feature have an empty value: phenomenonTime. While this is valid against the XML schema, this is not valid according to the GML model. Please correct the process that generates the GML documents.

- Does it seems to you a good example of an INSPIRE compliant GML file?

And in a more general way, is it fine to use the PointObservation to describe a list of objects that are present on the sea bottom? I could maybe also use the SeaBedArea featuretype from the Sea Region theme but in that one there isn’t an InspireID in the schema. I’m not sure how that featuretype should be used if the most important info is not present in the schema…

So I’m a bit confused about the best choice that can be made to publish such dataset.

Any help would be welcome!
Thanks a lot,

Cheers,

Nicolas de Ville

 

Replies

    • Public

    By Begoña Vila Taboada

    Hello Nicolas,

    In our TWG, we have discussed this same topic, and the truth is that we have not reached a single conclusion, that is, that your example could fit both 15 and 16 Inspire Themes.


    Personally, I think the simplest solution would be to characterize it as a Sea Region. But it is true that Inspire does not see it that way, perhaps because when the Technical Guidelines were written, the subject of marine litter and the MSFD were not critical subjects.

    In fact, a few months ago I opened a ticket dealing with this topic because in my point of view it has a lot of potential: https://themes.jrc.ec.europa.eu/discussion/view/183885/seabedarea-and-marine-litter.

    I'm afraid I have not been very helpful, Nicolas. But I hope that we all open a debate and we finally know how to deal with this issue.

    Regards,

    Begoña

    • Public

    By Nicolas de Ville de Goyet

    Hello Begoña,

    Thanks for your reply. At least I know I haven't missed the obvious solution and I feel less lonely in this ocean of guidelines and open questions.

    Maybe (surely?) someone else will join this discussion to elaborate a solution!

    Cheers,

    Nicolas

    • Public

    By Katharina SCHLEIDT

    Hi Nicolas,

    this is an interesting application of O&M Observations! I don't think it was thought of when the OF/SR data specification was designed, but as O&M can also be utilized to provide information on observations of species, why not provide observations on sea litter!

    Have to had time to read D2.9? Also check the examples provided in the Observations Cluster for GML encoding and O&M insights. 

    To your questions/issues:

    • phenomenonTime error: you can't just provide the xlink:title, correct encoding is something like:

                <gml:TimeInstant gml:id="_fc6a2412-a17c-44e0-8094-6a444411462c">
                        <gml:timePosition indeterminatePosition="unknown"/>
                </gml:TimeInstant>

    • Now to the tricky O&M bits (please take a good look at the species examples in D2.9!). The Geometry shouldn't be in the Observation location, but instead, this is your featureOfInterest (FoI). The FoI can either be provided inline, or as a separate feature, that would allow further Observations to be attached (i.e. litter removed)
    • For your observedProperty, something along the line of http://inspire.ec.europa.eu/featureconcept/Pole will be required. If there isn't a code list for sea litter, than either you can maybe motivate JRC to have one created or more likely, one of the EU marine networks should make something available that can be referenced by URI for sea litter types
    • You've left the procedure empty, here you should provide information on how the sea litter was located/identified/observed, utilizing the INSPIRE Process type. While commonly describing some physio-chemical technical assay methodology, it can also utilized to describe manual surveys.

    Hope this helps!

    :)

    Kathi

    • Public

    By Keiran MILLARD

    Hi All,

    First of all, it would be good to clarify the nature of your  data set as this will determine the best data specification to use.

    If your dataset is a collection of polygons or point, with each polygon or point representing a status of seabed loss then you could use the FT SeaBedArea and for each and assign a value form the code list SeaBedCoverValue.  Of course these values would need to be created.  The could be a % loss for each polygon, e.g. "25% habitat loss".  A similar approach could be achieved using MarineContour.

    Alternatively and still using SeaBedCoverValue, values could be created like 'litter', 'spoil ground', 'pipeline' and rules agreed that any SeaBedArea that carries these attributes = lost habitat

    Best regards

    Keiran

    • Public

    By Keiran MILLARD

    Continuing the discussion, an alternative would be to use a grid (OF Theme) and each value of the grid is a % of seabed loss in the grid cell.

    The best approach really depends on the nature of your source dataset and how a 'loss of seabed' dataset is to be defined.  The SR and OF data specifications are really aim at the target dataset, rather than the source.

    Best regards

    Keiran

     

     

    • Public

    By Nicolas de Ville de Goyet

    Hello Keiran, Hello katharina,

    Thanks for both your inputs!

    In the end I chose to publish the data as polygons under the SR SeaBedArea INSPIRE theme. This allows to be quite precise in the determination of the areas that were lost. To overcome the problem of the absence of InspireId attribute in the SR schema I used the deprecated INSPIRE gml file export in Hale that allow to add the localID and the namespace.

    The grid would have been a good solution too but if one wants to keep the details of the data, the cell size must be quite small, with the problem of creating heavy files (500mb for a simple representation of the Belgian Part of the North Sea).

    Have a good day.
    Cheers,

    Nicolas

    • Public

    By Katharina SCHLEIDT

    A note on adding the inspireId - while I find it quite strange that some SR features carry this attribute while others don't (@Keiran: what happened here?), I'd worry about adding it as you will need to either create a new XSD or will be providing invalid XML. Is there some rationalle behind adding the inspireId (i.e. do you use some referencing scheme depending on it), or is this just for completeness (inspireId is not required in Annex II & III)

    As to your statement on the size of gridded representations, this is why in the observational world we tend to forego WFS and utilize SOS and WCS, as these OGC services allow for spatio-temporal subsetting. Thus, while the entire coverage may still be large (coverage encoding does tighten things up quite a bit), as the user can request the segment they require, and the data becomes manageable again

    :)

    • Public

    By Nicolas de Ville de Goyet

    The idea with the InspireId is partly for completeness but also to have a referencing possibility in the future (in case it is needed). Beside in the Sea Region data specification v3 page.31 it is mentioned that the InspireId is mandatory for the Sea Area (Multiplicity = 1). Is it an "exception" in the Annex II & III or do I misunderstand something?

    • Public

    By Katharina SCHLEIDT

    Hi Nicolas,

    several bits:

    • The requirement for inclusion of an InspireId (optional in Annex II & III) pertained to creating the data specifications, relevant to the TWGs convened for this purpose. In most cases, they added an InspireId to all featureTypes, but this was not mandatory. For you as a data provider, compliance is evaluated against the Implementing Rules (IRs), further described in the DataSpecifications. Thus if the IRs and DataSpecs include an attribute, you must provide, if not, it's not required.
    • You refer to the specification for the featureType SeaArea, which includes an InspireId. However, you've been discussing the featureType SeaBedArea, which does not include an InspireId (scroll on to p. 32).
    • InspireId and referencing: very relevant point, but unfortunately still not clarified how this is to be done. We have the InspireId (and gml:id and gml:identifier) as identifiers, we have xlink:href for referencing, but in the middle there's still a bit of a hole. More info in our WS on practical INSPIRE in Antwerp Tuesday 9:00, or also in last year's presentation: https://themes.jrc.ec.europa.eu/file/view/148857/practicing-practical-inspire-ws-presentation

    Leaves the question open why SeaBedArea and SeaSurfaceArea are in no way related to SeaArea (they're both derived from MarineLayer, that weems disjunct from the rest of the model)

    @Keiran: can you tell us what happened here? Did something get lost in the data modelling (i.e. derivation from SeaArea to MarineLayer)?

    :)

    Kathi

    • Public

    By Keiran MILLARD

    Hi Kathi,

    "@Keiran: can you tell us what happened here? Did something get lost in the data modelling (i.e. derivation from SeaArea to MarineLayer)?"

    This really made me think!

    The rationale is that a MarineLayer is distinct from a SeaArea and so they are best modelled as separate objects.  For example an oil slick (MarineLayer) existing in the North Sea (SeaArea).  Clearly these are distinct objects and these objects may have different attributes.  For example a SeaArea should be constant with time, but a MarineLayer may be transient (an oil slick will move and change size).   The MarineLayer may also be distributed over multiple SeaAreas, for example; marine seabed litter for all EU waters.

    At the time we felt this gave the most flexibility and could be refined as use cases came along.

    Hope that helps

    Keiran

     

     

     

     

     

     

Marine and Atmosphere Cluster

Marine and Atmosphere Cluster

Oceanographic Geographical Features, Sea Regions, Atmospheric Conditions and Meteorological Geographical Features