European Commission logo
INSPIRE Community Forum

How to request specific observations types from SOS servers?

Dear all,

During the maintenance process of D2.9 and the development of the Inspire SOS reference implementation (as part of MIWP-7a), the following question came up:

How shall a client discover which (INSPIRE) observation types are supported by a SOS server? And how can a client specify which observation type shall be used by the SOS server to encode a GetObservation response? For example, a client might only support the PointObservation so that it needs to force the SOS server to return the resulting observation in the observation type it supports.

Our idea would be to add an additional request parameter for the GetObservation operation such as "resultType" where a client can define the expected observation type the SOS shall return. If we decide to go for this option, the supported observation types would be listed in the Capabilities document of the SOS.

What are your thoughts about this approach? Due to the deadlines we have for our work, we need your input before the end of the month (November 2015).

Best regards

Simon Jirka

  • Ilkka RINNE

    This is a good question. Quickly reading the SOS 2.0 spec about the supported observation types, it seems to me that the server must list all the observationTypes it supports in the Capabilities document, and the details for each can be requested using DescribeObservationType operation. However, as each ObservationOffering may be declared by the server to be available in more than one observationType, there should be a way for the client to select the most appropriate one, as you said.

    I'm just wondering if this would be a change request to the OGC SOS SWG? I suppose we could initially add it as an additional INSPIRE requirement, but there would be a considerable technology risk for the software and data providers, because the INSPIRE solution might not eventually be approved as-is by the OGC SOS SWG. I'm guessing that some SOS server providers may not be willing to introduce this functionality before it's part of the OGC SOS standard.

  • Alessandro SARRETTA

    By Alessandro SARRETTA

    Thank you Simon for starting this discussion and sharing it here. I hope other inputs from the members of the cluster could help its solution.

    If the "resultType" additional request parameter for the GetObservation operation would be added, is your suggestion to add it to D2.9 and SOS reference implementation, or to start some procedure to add it directly to the SOS standard?

    In this regard the question from Ilkka is pertinent and I thank also him for his contribution.

  • Simon JIRKA

    Dear Ilkka, dear Alessandro,

    Thanks a lot for your replies.

    The listing of the supported observation types in the SOS Capabilities is something which we definitively need. The SOS 2.0 standard has already the observationType element in the description of observation offerings so that we could use this. What would be useful is to indicate the default observation type which is used for returning the observations of a specific offering.

    The DescribeObservationType operation is not part of the SOS 2.0 standard. This operation was included in SOS 1.0.0 but in SOS 2.0 this was removed. If we use URIs for identifying the supported observation types such a dedicated operation would not be necessary, as we could directly resolve the URIs pointing to the observation type definitions.

    What is missing is an additional request parameter to specify which observation type is expected by a client. The SOS 2.0 standard include the following note on this topic (page 32): “NOTE Observations returned by the SOS might be encoded with different observation types and result types. For the client, such responses are difficult to parse. This issue is not addressed here. It might be solved in future through an extension which allows requesting only certain observation / result types. However, such a mechanism would put the burden of observation / result type transformation on the SOS server.”

    Thus, I think it would be important to work on such an extension. As a first step, this should be something which is included and specified in the Technical Guidance which describes how to use the SOS as an INSPIRE Download Service. After that, the extension could be advanced to an OGC document (Best Practice/Standard). We ight think about specifying this as an additional requirements class for SOS servers that shall be used as INSPIRE Download Services.

    Best regards

Environmental Monitoring & Observations

Environmental Monitoring & Observations

Environmental Monitoring Facilities, Observations and Measurements