European Commission logo
INSPIRE Community Forum

Implementation of OF data model with O&M

  • General

    The INSPIRE Community Forum is now part of the INSPIRE helpdesk system, based on GitHub (, so please start there any new discussions.

    The current platform will remain available in read only mode in its current form and URL address until 31/01/2021, then its content will be archived and then published in a different URL which will be announced when it becomes available.

This discussion started by Keiran Millard touches various aspect of the implementation of OF data specifications in a Marine Spatial Data Infrastructure that are related to the O&M world.

In particular I want to highlight here few of them:

  • the second question raises the issue that "some of the collection in Ocean is not a measurement but a sample of something". And the question is: "how do I store the water samples collected in the ocean, into my Spatial Data Infrastructure until my colleagues do some measurements, and respecting the UML defined in the data specification?"
  • the third question relates to HALE – The HUMBOLDT Alignment Editor but I think is relevant in general. In particular the question is dealing with Trajectiories and the mandatory request to fill the Phenomenon Time as Time Period.
  • the fourth question is related to the use of processUsed and observedProperty
  • the sixth question is about how to store movies and photos in OF, but I think this is relevant also for O&M.

Do you have any clear view on that or similar doubts?

  • Ilkka RINNE

    I'm not an ocean expert really and know nothing about the HALE tool, but i think the measurement-in-progress observations do not have to be published as INSPIRE data, only the when the actual results of the measurements are available. Thus the water sample descriptions would not necessarily have to fit into the INSPIRE data models.

    Still it may be useful to publish the information about the samples taken using the SamplingFeature - SampledFeature O&M model already before the samples have been analysed. An obvious candidate for this would be the SF_Specimen class, which is intended for modelling specimens taken and possibly stored separately from the measurements (observations) created using them.

    These sampling features are geospatial features with both geometry via the sampledFeature property referring to the location/area/trace where the sample was taken from, and non-spatial properties describing other properties of the specimen that could be of interest when searching for interesting specimens. As they are features, the natural way to encode them is GML (while others can be used) and the service type would the Download Service (WFS probably recommended).

    When the actual measurements are made at a later time (using the OF theme Specialized Observation types), they could re-use the previously defined SF_Specimen instances as values for their featureOfInterest property (or link to them using xlink:href pointing the GML file or the WFS GetFeature request).

    About the TrajectoryObservation's time properties in the case of collecting samples first and later analysing them: The phenomenon time period would be defining the time during which the sample was taken. The resultTime is the time when the Observation was made, that is, when the specimen was analysed and the result was created or made available (typically in the lab).

    The fourth question was about the process and the properties. The process in this case would describe the entire process used for creating the Observation instance: This would include the description of from how the specimen were taken, up to analysing process used for creating the result. The observedProperty contains a single or a combined description of which properties of the sampling feature or it's sampled feature were analysed (what information the analysts were trying to discover). The observed properties should usually match the fields (and their quantities) contained in the result of the created Observation instance.

    The question about storing images or photos, would need further details, but I see no problem for using an image as the encoding for the GridCoverage type result if the data of the image is meant to be interpreted as a data grid with values mapped to different geospatial points. If the whole image or photo is meant to be the result of the Observation at a single geospatial point, then where would have to some instructions how to interpret the image (what are the observed properties that are quantified within the data contained in the image).

    Movies are basically a series of image scenes, and depending on whether a movie is created while moving the camera along a trajectory or keeping it at the same location, the suitable Observation types are probably a TrajectoryObservation or GridSeriesObservation/PointTimeSeriesObservation.

    I hope this helps.

  • Simon TEMPLER

    On the HALE related question (copied from the answer I gave to the original question):

    No, you don't need to fill all attributes in this case, indeed you should only provide one of them.

    You may have noted that the common parent of TimeInstant and TimePeriod in this case is a choice, which you can recognise by the question mark. A choice allows only one of its children to be present (see also the HALE documentation on schema elements).

    So in combination the choice and the red asteriks tell you, that you need to provide one of TimeInstant, TimePeriod, TimeEdge or TimeNode.

    Though the HALE help explains both choices and mandatory attributes, the consequences if they occur in combination may not be clear, so I will update the HALE help with a hint concerning this case for the next release.

This discussion is closed.

This discussion is closed and is not accepting new comments.

Environmental Monitoring & Observations

Environmental Monitoring & Observations

Environmental Monitoring Facilities, Observations and Measurements