Fwd: Re: [SOS-2.0.SWG] Questing regarding SOS database design

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Fwd: Re: [SOS-2.0.SWG] Questing regarding SOS database design

Chandan Kumar Rana
Hi Team,

Please give me suggestions on how to proceed, for the questions mentioned in the mail chain.

Thanks & Regards,
Chandan Rana
---------- Forwarded message ----------
From: Christoph Stasch <[hidden email]>
Date: 03-Mar-2017 9:19 PM
Subject: Re: [SOS-2.0.SWG] Questing regarding SOS database design
To: Chandan Kumar Rana <[hidden email]>
Cc: "[hidden email]" <[hidden email]>

Dear Chandan,

I'd suggest to send your mail to the 52°North Sensor Web mailing list [1], since your questions seem to be specific to the 52°North SOS implementation.

Best regards,


2017-03-02 21:25 GMT+01:00 Chandan Kumar Rana via SOS-2.0.SWG <[hidden email]>:
Hi Team,

I was going through the SOS implementation of 52 north group for a couple of days. I examined the database model that is being used for storing observations in O&M model.

I have couple of doubts here, I will be glad if anyone can help me out here.

1. I am implementing a client that will use SOS and SOS-T for data storage and discovery. I have some observation data that I want to ingest into the database model that 52 north SWE implementation uses.

2. My single observationis like this, it contains multiple parameters for example single observation at an instance gives me data such as

air pressure, air temperature, water temperature  and I have quality control flag for all these parameters let's say air temperature QC flag and so on.

Then I have different maintenance parameter for the same observation as well, such as battery voltage at the time of observation, sensor tilt angle etc.

Along with that some parameters let's say, water temperature might have an array of values for the same observation across different depths.

3. So as you can see (correct me if I am wrong) this kind of observation does not quite fit into the O&M model of single parameter and single result. My question is how this can be implemented using SOS and SOS-T.

4. If this kind of observation data is supported with SOS O&M model then what will be SOS and SOS-T request structure to insert or read an observation. And if someone can explain how this will be stored in the database model that 52north has implemented.

5. The last question is about the filter capabilities of SOS, let's assume I am able to store the above observation data in the db. Is there a way to filter data based on any of these observation parameter.

For example queries like, I want water temperature for all the observations for a certain time period where filter by comparing air pressure value or quality flag > some value

These seems really odd use cases but are these possible with the current implementation of SOS and SOS-T ?

Thanks & Regards
Chandan Rana
Mail to: [hidden email]
GitHub: rc-chandan

SOS-2.0.SWG mailing list
[hidden email]


Dr. Christoph Stasch
52°North GmbH, Martin-Luther-King-Weg 24
48155 Muenster, Germany
tel. <a href="tel:%2B49%20%280%29251%20396371%20-32" value="&#43;4925139637121" style="color:rgb(17,85,204); font-size:12.8px">+49 (0)251 396371 - 32
fax: <a href="tel:%2B49%20%280%29251%20396371%20-11" value="&#43;4925139637111" style="color:rgb(17,85,204); font-size:12.8px">+49 (0)251 396371 -11

SWE mailing list
[hidden email]
Please respect our mailing list guidelines:
Reply | Threaded
Open this post in threaded view

Re: Fwd: Re: [SOS-2.0.SWG] Questing regarding SOS database design

Carsten Hollmann
Hi Chandan,

the modeling/mapping of your data to O&M should also consider the
querying of the data.

Would you usually query all parameter as a single observation or would
you query for individual parameter, e.g. air pressure or air temperature?

If you would like to store all parameter as a single observation into
the SOS, the O&M 2.0 standard defines the ComplexObservation.
This observation contains a swe:DataRecord where you could define the
single parameter values in the swe:field as SWE-types (e.g. swe:Count,
swe:Quantity, ...). The SWE-types also have defined a swe:Quality
element where the QC flag could be stored.
But in this case you have only one query parameter (observedProperty)
for all single parameters of the observation. Querying only the air
temperature values, for example, would not be possible.

The array of values for different depths might be modeled as
swe:DataRecord in the swe:DataRecord of the ComplexObservation. Then the
values for each depth are stored in a new swe:field.

The maintenance parameter could be defined as om:parameter with
name-value pairs.

If you would to store the single parameters as separate observations,
you could use the om:parameter to store the QC flag or the depths data.
Depending on how often the maintenance parameters are changed, this
information could be part of the sensor description and if a parameters
is changed, you could update the sensor description via the
UpdateSensorDescription operation.

The 52N SOS supports the O&M ComplexObservation and the single parameter
(swe:fields) would be stored as separate observation in the database.
They are linked together in the compositeobservation table.

The om:parameter is supported in the development version (4.4.x) [1] of
the 52N SOS which would be released in the next quarter.

Next to the transactional operation (InsertObservation) the 52N SOS also
supports the result handling operations (InsertResult/-Template and
GetResult/-Template). The result handling operations could be used to
insert observation values into the SOS and the values are stored as
observation could also be queried via GetObservation.

The result filtering for certain values (question 5) is not yet defined
for the OGC SOS 2.0 and it is not yet implemented for the 52N SOS
because there was so far no requirement for this.

The defined filter parameters for the OGC SOS 2.0 are:
- offering
- procedure
- observedProperty
- featureOfInterest
- temporal filter (all values for a certain time or period)
- spatial filtering

Since the SOS is driven by the requirements of projects and the
community it may be that some features are not yet implemented since
there was so far no requirement for it.

Hence the storage of the quality flags are not yet supported by the 52N
SOS, unless they are stored as om:parameter.

But if the full quality flag is a requirement for you and you are
interested in implementing this feature, you are welcome to become a
contributor of the 52°North SOS [2].

Otherwise you could create a GitHub issue [3] for this and perhaps there
is a project or a contributor with the same requirement where/by which
it would be implemented.

For more information about the 52N SOS please read the wiki page [4].

If you have further questions feel free to ask.


[0] http://schemas.opengis.net/om/2.0/examples/complexObservation3.xml
[1] https://github.com/52North/SOS/tree/develop
[2] http://52north.org/about/get-involved
[3] https://github.com/52North/SOS/issues
SWE mailing list
[hidden email]
Please respect our mailing list guidelines: