European Commission logo
INSPIRE Community Forum

Point Time Series Observation example

Hello everybody,

My name is Arvids Ozols and I am assist to Latvian Hydro Ecological Institute to arange their data accordance INSPIRE guidelines of themes 15 in Latvia.

We think that the data of sea monitoring data should be arranged in the shema of PointTimeSeriesObservations. 

Each point have an information about temperature, salinity, secchi, oxygen and Ph on different depths. Measurments are done 4 times annualy.

I do not really understand how to properly arrange this data accordance the Guidelines for the use of Observations & Measurements” (D2.9.O&M-swe-3.0) , target is to create data in GML format. ‚Äč

I'm using FME Workbench for data transformation.

Could someone post an example with a GML file that is prepared to accordance the requirements of the D2.9.O&M-swe-3.0 specification? 

I can not find just one example on INSPIRE Geoportal or INSPIRE Thematic Clusters website! 

Thank you very much.



Latvian Geospatial Information Agency

P.S. Positions of the Baltic sea Montoring stations are pulished in the HELCOM website, section of Hydrographical stations frequency times a year :


  • Ilkka RINNE

    Hi Arvids,

    Finnish Meteorological Institute publishes lots of meteo/sea/air quality data in INSPIRE O&M format through their WFS. Their WFS is free, but requires registration to get an API key, so I'm copying two example responses below.

    If you do the effort to register (in Finnish) at, you can do these requests yourself, just replace the <APIKEY> with your API key.

    The example data is not exactly what you have, but close: Wave and water temperature observations from buoys. Available parameters are significant wave height, wave direction, deviation of wave direction, modal period and water temperature. Some buoys return only temperature values. Time step is 30 minutes.

    Option 1: PointTimeSeries with WaterML TimeValuePairs<APIKEY>/wfs/eng?SERVICE=WFS&REQUEST=GetFeature&STOREDquery_id=fmi::observations::wave::timevaluepair

    PointTimeSeries with WaterML TimeValuePairs

    Option 2: GridSeriesObservations with MultiPointCoverage<APIKEY>/wfs/eng?SERVICE=WFS&REQUEST=GetFeature&STOREDquery_id=fmi::observations::wave::multipointcoverage

      GridSeriesObservations with MultiPointCoverage

  • Ilkka RINNE

    Since you have measurements taken at different depths, you may want to consider using either ProfileObservation (if the measurements are considered to be done at the "same" time for all depths), or TrajectoryObservation (if measurements at each depth have their own timestamp).

    I don't have a real TrajectoryObservation example at hand, but FMI WFS is offering weather observations from different heights of a few radio masts as ProfileObservations:<APIKEY>/wfs?service=WFS&request=GetFeature&storedquery_id=fmi::observations::weather::mast::multipointcoverage&place=helsinki

    Mast weather observations as a collection of ProfileObservations


    • In this example there is a separate ProfileObservations for each observed parameter at different heights at each observing time instant, since not all parameters are measured at the same heights. If they were, they could be included in a single ProfileObservation for a single observing time instant.
    • The domains in the MultiPointCoverage results here are 1-dimensional SimpleMultiPoints with a linear referencing srs specific to each mast: this means, that the coordinates for each result point only consist of the length from the bottom of the mast to the instrument along the mast curve. The linear referencing srs for one of the masts is available at (although the coordinates seem to be given in a wrong srs)
    • The spatial sampling feature shape is provided in 3-dim (regular) srs ( with just the bottom and the top points.
  • Arvids OZOLS

    Hi Ilkka!

    I did not expect that you will answer exactly!  

    Well, Spatineo holds a hand on the pulse of web services! smiley

    Thank you very much for the quick response!

    I am currently study downloaded files.

    If someone already had a FME * .fmw document, then it would be a real miracle! Now the picture becomes clearer! Nothing, we do it!

    Big thanks!

    Best regards,


    P.S. Ilkka, this are first examples about this theme! Congrats!

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Hi Arvids, Hi Ilkka,

    Some questions and comments:

    @Arvids: while I can't tell for certain, I can't currently find you in the observational cluster (hard to search). While it is the first marine example, we do have some terrestrially wet PointTimeSeriesObservation examples out on our best practice page (look for Borehole):

    From the description above, you will also need to provide Environmental Monitoring Facility Features for the Baltic sea Montoring stations (so also join the EF group within the observational cluster!); this facility should in turn be referenced from the Observation, relevant XML snippet from the Borehole example:

        <om:NamedValue xmlns:om="; xmlns:xlink="; xmlns:xsi=""&gt;
            <om:name xlink:href="RelatedMonitoringFeature"/>
            <om:value xmlns:ns="; xlink:href="; xsi:type="ns:ReferenceType"/>

    FoI - Sampled Feature: within the INSPIRE O&M Guidelines, we have a recomendation (/rec/inspire-om-core/featureOfInterest-sampledFeature) to provide a high-level sampledFeature for context (if a concrete sampledFeature is provided, then this in turn can have the high-level sampledFeature referenced). Example: <sf:sampledFeature xlink:href="; xlink:title="Aquifer"/>

    More bits in the next post - this is getting too long!



  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    OK, next bit - the observedProperty (took me a bit to figure the finnish and get an APIKEY)

    My worries here are that the CompositeObservableProperty was foreseen for, well, Composite Observable Properties. Idea was that when there are several strongly linked values coming from one measurement device these must be provided together, standard example is wind speed/direction.

    From my understanding of the URI referencing the property:<APIKEY>/meta?observableProperty=observation&amp;param=ModalWDi&amp;language=eng

    It is actually referencing an individual obervable property via param (so in the example refers to ModalWDi, this is also one of the components returned in the CompositeObservableProperty) but lets say in a creative manner! ;)

    Also, the CompositeObservableProperty returned is still based on the old draft schema (I caught it because I was wondering why there isn't an xlink to an external codelist for the basePhenomenon), the new schema version (foreseeing an xlink here) is available from:



  • Ilkka RINNE

    Hi Kathi, all,

    I'm trying to answer the questions with a bit of a background and implementation details for the referred FMI WFS implementation for those who are interested.

    The FMI WFS server has some peculiarities (it's based on response templates, returns what I call transient features created on-the-fly based on the requests etc.), but it's pretty reliable and fast. By transient I mean that the returned Observation features are only created at request time based in the request parameters. Unfortunately this means that the feature IDs are generated on the fly and not usable for referencing the particular features in the future, so the GetFeatureByID stored query does not do anything sensible.

    The server is based on the recently open-sourced high-performance SmartMet data server ( built from scratch at FMI. The WFS functionality is provided by the WFS plugin (

    SmartMet WFS uses stored queries a bit "creatively": The implementors at FMI wanted to use a single WFS endpoint for a multitude of different datasets, so they decided to deploy them using stored-query-per-dataset paradigm: The stored query fully defines what data is used for creating the GetFeature response, and which response template is used for it (including the Observation kind, process, result etc.). The code run for each stored query is not exposed in the DescribeStoredQuery, and it would probably not even be possible to formulate them using Filter Encoding. The regular GetFeature functionality with free FE query expressions were added a bit later.

    The naming schema used in the FMI stored queries (fmi::observations::wave::timevaluepair) is just to describe the data type and the response encoding. For many point datasets they have implemented three alternatives for the returned data structure: the WaterML base time value pair (timevaluepair), the compact and versatile, but not so "XML-friendly" GridSeriesObservation with MultiPointCoverage result (multipointcoverage), and the Simple Feature version to be used for simple cases like WMS rendering (simple). Some of these are observsation data, some are predicted data using numerical atmospheric/sea/air-quality dispersion models.

    The an up-to-date list of all the the stored queries (and the datasets) are available at

    About the CompositeObservableProperty use: As you know well, the O&M Observation model only allows a single observedProperty per Observation instance. Forcing a separate Observation features for each weather parameter (temperature, air pressure, wind speed & direction etc.) was considered much too verbose. To solve this the way the system was built was that when using GridSeriesObservations users are able to choose which parameters they want to get, and values for all those parameters at a single point at different times would be packed inside a single GridSeriesObservation object. To allow identifying the returned parameters, there had to be a simple way to generate a CompositeObservableProperty including only the included parameters, so a script was created to create these on-the-fly based on the given parameter IDs:<APIKEY>/meta?observableProperty=observation&param=minimumtemperature,maximumtemperature

    returns a CompositeObservabeProperty with only minimum and maximum temperature properties. 

    The same script is also used providing the swe:field values for the gmlcov:rangeType of the MultiPointCoverage result.

    For time-value pair encoding, each PointSeriesObservation only contains data for a single parameter, but the same script is used to provide the observedProperty value for implementation convenience: the CompositeObservableProperty consisting only of a single Observable Property is returned when the "param" request parameter list only contains one entry. 

    It seems that you Kathi found a bug there, because this does not seem to work when the ampersands are provided using named HTML entities (<APIKEY>/meta?observableProperty=observation&amp;param=minimumtemperature,maximumtemperature): When done like this the script defaults to returning all the known properties, thus the long list you got. To get the names used for predicted parameters, you could similarly use<APIKEY>/meta?observableProperty=forecast

    The FMI INSPIRE WFS service was launched already in May 2013, thus some of the schemas used there are still old versions, like the OMOP 2.9 you spotted. This should be fixed of course.

This discussion is closed.

This discussion is closed and is not accepting new comments.

Marine & Atmosphere

Marine & Atmosphere

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