[Geoserver-devel] Sensor Observation Service (SOS) Implementation In GeoServer

GeoServer GeoServer Developer
1

Hi Andrea and Justin,

I will be working on SOS implementation in GeoServer in last quarter of this year and currently doing some scoping work and studying on GeoServer source code to see how I can implement it. Have a chat with Ben just now and he pointed me to both of you and hope to get some pointers / helps from both of you on some of thougths I have on how to implement SOS in GeoServer.

FYI, I have deployed a copy of 52NorthSOS in our test server that generate some time series observations information [1]. I found that the GetCapabilities and GetObservations output are very much similar to WFS GetCapabilities and GetObservations output. e.g. The SOS observation output from SOS is basically a WFS output that wraps in a SOAP envelope body (correct me if I am wrong…).

While studying the GetCapabilities implementation for WFS in GeoServer, I can see a lot of complex implementations including the use of Eclipse Modeling Framework in GeoTools to generate the WFS model (well, i don’t fully understand the whole implementation yet… ).

So, my thought would be since SOS output is just WFS output wraps in a SOAP envelope body and rather than creating from scratch a whole new service for SOS in GeoServer/GeoTools, we can make use of the existing WFS and App-Schema modules to generate a SOS output - making implementation simpler. Wonder if this is possible ? And if possible, how do I achieve this - writing SOAP implementation in GeoServer ?

[1] http://services-test.auscope.org/52nSOSv350/testClient-SOSv2.html

Note :
Eventhough I have few years GeoServer deployment experience but honestly speaking, I am still very new with GeoServer development and hoping to find some “mentors” or “sifus” who are willing to help or point me to the right direction with this SOS implementation in GeoServer project.

Thanks & Regards,

Florence Tan
Research Projects Officer | ASRDC
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8802 | Fax: +61 8 6436 8555
florence.tan@anonymised.com | www.csiro.au
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.

2

Another library you might refer to and potentially incorporate is https://code.google.com/p/ows-service-framework/

Mike Botts, who lead spec development of SWE stuff, has been building up that library. And we’ve talked with him a few times about eventually incorporating it in to the GeoServer/GeoTools code base.

Not sure if the code can be easily incorporated in its existing state, but it is license compatible, and at the very least could be inspiration.

On Mon, Sep 17, 2012 at 5:45 AM, <Florence.Tan@anonymised.com> wrote:

Hi Andrea and Justin,

I will be working on SOS implementation in GeoServer in last quarter of this year and currently doing some scoping work and studying on GeoServer source code to see how I can implement it. Have a chat with Ben just now and he pointed me to both of you and hope to get some pointers / helps from both of you on some of thougths I have on how to implement SOS in GeoServer.

FYI, I have deployed a copy of 52NorthSOS in our test server that generate some time series observations information [1]. I found that the GetCapabilities and GetObservations output are very much similar to WFS GetCapabilities and GetObservations output. e.g. The SOS observation output from SOS is basically a WFS output that wraps in a SOAP envelope body (correct me if I am wrong…).

While studying the GetCapabilities implementation for WFS in GeoServer, I can see a lot of complex implementations including the use of Eclipse Modeling Framework in GeoTools to generate the WFS model (well, i don’t fully understand the whole implementation yet… ).

So, my thought would be since SOS output is just WFS output wraps in a SOAP envelope body and rather than creating from scratch a whole new service for SOS in GeoServer/GeoTools, we can make use of the existing WFS and App-Schema modules to generate a SOS output - making implementation simpler. Wonder if this is possible ? And if possible, how do I achieve this - writing SOAP implementation in GeoServer ?

[1] http://services-test.auscope.org/52nSOSv350/testClient-SOSv2.html

Note :
Eventhough I have few years GeoServer deployment experience but honestly speaking, I am still very new with GeoServer development and hoping to find some “mentors” or “sifus” who are willing to help or point me to the right direction with this SOS implementation in GeoServer project.

Thanks & Regards,

Florence Tan
Research Projects Officer | ASRDC
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8802 | Fax: +61 8 6436 8555
florence.tan@anonymised.com | www.csiro.au
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Hi Florence,

As discussed in the meeting I don’t think either Andrea or myself is up to speed on SOS so having a nice overview of the spec would be helpful. The same way Andrea did for CSW. With that we will be in a better situation to provide architectural guidance.

That said, the same approach taken for CSW might be nicely applied here as well. Essentially coming with a back end interface to encapsulate the core service implementation details behind. This way we don’t necessarily have to tie things to a WFS / app-schema implementation, but can easily build one.

$0.02

-Justin

On Mon, Sep 17, 2012 at 6:30 AM, Chris Holmes <cholmes@anonymised.com> wrote:

Another library you might refer to and potentially incorporate is https://code.google.com/p/ows-service-framework/

Mike Botts, who lead spec development of SWE stuff, has been building up that library. And we’ve talked with him a few times about eventually incorporating it in to the GeoServer/GeoTools code base.

Not sure if the code can be easily incorporated in its existing state, but it is license compatible, and at the very least could be inspiration.

On Mon, Sep 17, 2012 at 5:45 AM, <Florence.Tan@anonymised.com> wrote:

Hi Andrea and Justin,

I will be working on SOS implementation in GeoServer in last quarter of this year and currently doing some scoping work and studying on GeoServer source code to see how I can implement it. Have a chat with Ben just now and he pointed me to both of you and hope to get some pointers / helps from both of you on some of thougths I have on how to implement SOS in GeoServer.

FYI, I have deployed a copy of 52NorthSOS in our test server that generate some time series observations information [1]. I found that the GetCapabilities and GetObservations output are very much similar to WFS GetCapabilities and GetObservations output. e.g. The SOS observation output from SOS is basically a WFS output that wraps in a SOAP envelope body (correct me if I am wrong…).

While studying the GetCapabilities implementation for WFS in GeoServer, I can see a lot of complex implementations including the use of Eclipse Modeling Framework in GeoTools to generate the WFS model (well, i don’t fully understand the whole implementation yet… ).

So, my thought would be since SOS output is just WFS output wraps in a SOAP envelope body and rather than creating from scratch a whole new service for SOS in GeoServer/GeoTools, we can make use of the existing WFS and App-Schema modules to generate a SOS output - making implementation simpler. Wonder if this is possible ? And if possible, how do I achieve this - writing SOAP implementation in GeoServer ?

[1] http://services-test.auscope.org/52nSOSv350/testClient-SOSv2.html

Note :
Eventhough I have few years GeoServer deployment experience but honestly speaking, I am still very new with GeoServer development and hoping to find some “mentors” or “sifus” who are willing to help or point me to the right direction with this SOS implementation in GeoServer project.

Thanks & Regards,

Florence Tan
Research Projects Officer | ASRDC
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8802 | Fax: +61 8 6436 8555
florence.tan@anonymised.com | www.csiro.au
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

4

Thanks Justin & Chris for the feedback.

Before going into the overview of the Sensor Observation Service (SOS) Specification, would like to give brief background info about the rise of the SOS implementation in GeoServer :

=================
Brief Background

Last financial year, we did some review on a few open source SOS services available e.g. 52North, MapServer and Deegree and concluded that 52North SOS is the best option as it is the only SOS that support SOS 2.0 specification with good implementation documentation. However, it is still not the best solution with the limitations such as:
=> only support PostgreSQL DB at the moment
=> require good understanding of their database schema for database mapping
=> feeding data require good knowledge of sql or other feeder tool (e.g. ETL, script, etc)
=> limited to only OM result model that tie to SWE Common model at that moment, it now has a branch with OM result model that tie to WaterML model
=> any changes required in the result mapping require changes in the source code
=> manual mapping of sensor information using sensorML schema

The above limitations are something we hope to resolve by implementing the SOS service in GeoServer as we know that GeoServer :
=> support broad selection of data stores
=> able to use existing datastore without altering it
=> flexibility of creating different OM result model - base on the concept of Application Schema configuration file
=> similar to creating the Observation using Application Schema configuration file concept, sensor information can be published thru a standard configuration file

Additional to above review, we also did some comparison with the time series observation results published through GeoServer WFS (version 1.1 as Application Schema only support up to 1.1 now) and 52NorthSOS (SOS version 2.0), some observations recorded and comments from users :
=> In WFS1.1, there is no concept of observation, procedure, observedProperty, time or number of records, however, a complex feature could be specified that contains all of these concepts, such as WaterML.
=> When it comes to huge amount of time-series observation, SOS is the better option as there is option of filter by time range / time period
=> user is able to find out the bounding box time range of the dataset from the SOS GetCapabilities operation and making filter request easier
=> a good presentation by 52NorthSOS comparing SOS1.0 and WFS1.1 @ http://2010.foss4g.org/presentations/3800.pdf

===========================================================
Overview summary of the SOS 2.0 Specification (OGC 12-006)

SOS Standard Overview - The standard defines a web service interface for the discovery and retrieval of real time or archived data (particular time-series observations) produced by all kinds of sensors like mobile or stationary as well as in-situ or remote sensors. The requirements classes defined by the SOS 2.0 standard :

Core : GetCapabilities, DescribeSensor and GetObservation
Transactional : Insert Capabilities, Sensor Insertion, Sensor Delition, Observation insertion
Result Handling : Result insertion, Result Retrieval
Enhanced Operations : Observation retrieval by ID, FeatureOfInterest Retrieval
Filter Operations : Spatial filters, Temporal Filters
Binding : XML Encoding, SOAP Binding, Core KVP Binding, GetFeatureOfInterest KVP Binding, Result Retrieval KVP binding

For a start, will concentrate on the following minimum requirements standard :
Core Opertations : GetCapabilities, DescribeSensor and GetObservation
Filter Operations : Spatial filter (BBOX), Temporal Filter (TEquals, During)

From the SOS2.0 specification Annex D - Relationship to Other OGC Web Service Standards - describes the relationships between SOS and WFS and how to couple the two. There are two type of relationships as below :

(1) Relationship between SOS and WFS where WFS is providing feature of interest - SOS providing O&M observations for certain feature of interest and the features are provided by an external WFS.
(2) Relationship between SOS and WFS where SOS is encapsulating WFS - SOS is using a WFS at the backend for handling the feature of interest. SOS offers both the observations as well as the features of interest.

Option 1 is preferred where SOS will be used mainly for providing O&M observations.

====================================================================
Core Operations: GetCapabilities, DescribeSensor and GetObservation

--------------------
(1) GetCapabilities
--------------------
Overview - The GetCapabilities operation returns a service description containing information about the service interface (e.g. supported operations, service version) and the available sensor data (e.g. registered sensors, time period of available observations, spatial extent of features for which observations are available).

Request base on the OWS Common standard :
e.g. http://hostname/geoserver/ows?service=SOS&request=GetCapabilities&AcceptVersions=2.0.0

Response data type derives from OWS Common OWSServiceMetadata data type :
    - ServiceIdentification
    - ServiceProvider
    - OperationsMetadata
    - FilterCapabilities
    - Contents

Examples bundled in SOS 2.0 schema :
GetCapabilities request (SOAP binding) : http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1.xml
GetCapabilities response (SOAP binding) : http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1_response.xml

-------------------
(2) DescribeSensor
-------------------
Overview : The DescribeSensor operation returns a description of one specific sensor, sensor system or data producing procedure containing information like position of sensor, calibration, input- and outputs, etc. The response has to be either encoded in SensorML or in TML.

Request base on the OWS Common standard :

example 1 (with mandatory parameters ) :
http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=DescribeSensor&procedure=urn:ogc:object:Sensor:MyOrg:thermometer1
&procedureDescriptionFormat=http://www.opengis.net/sensorML/1.0.1

example 2 (with both mandatory and optional parameter) :
http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=DescribeSensor&procedure=urn:ogc:object:Sensor:MyOrg:thermometer1
&procedureDescriptionFormat=http://www.opengis.net/sensorML/1.0.1&validTime=2010-01-01T18:31:42Z

Examples bundled in SOS 2.0 schema :
DescribeSensor request : http://schemas.opengis.net/sos/2.0/examples/SOAP/DescribeSensor1_SOAP.xml

-------------------
(3) GetObservation
-------------------
Overview : The GetObservation operation returns a collection of observations. Each observation is composed of metadata, description of the phenomena being returned (parameter names, units of measure, reference systems) and values. The default and mandatory response format is base on O&M 2.0 specification.

Request base on the OWS Common standard :

example 1 (with mandatory parameters) :
http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=GetObservation

example 2 (with both mandatory and optional parameters) :
http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=GetObservation&offering=http://www.my_namespace.org/thermometer1_observations&observedProperty=http://sweet.jpl.nasa.gov/2.0/atmoThermo.owl#EffectiveTemperature&procedure=http://www.my_namespace.org/sensors/thermometer1&featureOfInterest=http://wfs.example.org?request=getFeature&amp;featureid=building1&namespaces=xmlns(sams,http://www.opengis.net/samplingSpatial/2.0),xmlns(om,
http://www.opengis.net/om/2.0)&spatialFilter=om:featureOfInterest/*/sams:shape,22.32,11.2,32.32,22.2,urn:ogc:def:crs:EPSG::4326&temporalFilter=om:phenomenonTime,2009-01-10T10:00:00Z/2009-01-10T11:00:00Z

Examples bundled in SOS 2.0 schema :
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps_response.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation2_obsProps_Procedure.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation2_obsProps_Procedure_response.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation3_foiIDFilter.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation3_foiIDFilter_response.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter_response.xml

==================
Filter Operations:

Overview : The filter capabilities is imported from OGC 09-026r1/ISO 1914. The minimum requirement stated in the SOS 2.0 specification:

Spatial Filter Opertor : BBOX
Temporal Filter : TEquals operator in conjunction with the TimeInstant type
                  During operator in conjunction with the TimePeriod type.

Example bundled in SOS 2.0 schema :
Spatial Filter : http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter.xml
Temporatl Filter (TimeInstant) : http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps.xml

I hope the above SOS 2.0 specification overview is clear enough to provide some basic understanding of SOS 2.0 standard. Do let me know if more information are needed.

Thanks & Regards,
Florence

________________________________

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Monday, 17 September 2012 11:30 PM
To: Chris Holmes
Cc: Tan, Florence (CESRE, Kensington); andrea.aime@anonymised.com; geoserver-devel@lists.sourceforge.net; Mike Botts
Subject: Re: [Geoserver-devel] Sensor Observation Service (SOS) Implementation In GeoServer

Hi Florence,

As discussed in the meeting I don't think either Andrea or myself is up to speed on SOS so having a nice overview of the spec would be helpful. The same way Andrea did for CSW. With that we will be in a better situation to provide architectural guidance.

That said, the same approach taken for CSW might be nicely applied here as well. Essentially coming with a back end interface to encapsulate the core service implementation details behind. This way we don't necessarily have to tie things to a WFS / app-schema implementation, but can easily build one.

$0.02

-Justin

On Mon, Sep 17, 2012 at 6:30 AM, Chris Holmes <cholmes@anonymised.com> wrote:

        Another library you might refer to and potentially incorporate is https://code.google.com/p/ows-service-framework/

        Mike Botts, who lead spec development of SWE stuff, has been building up that library. And we've talked with him a few times about eventually incorporating it in to the GeoServer/GeoTools code base.

        Not sure if the code can be easily incorporated in its existing state, but it is license compatible, and at the very least could be inspiration.

        On Mon, Sep 17, 2012 at 5:45 AM, <Florence.Tan@anonymised.com> wrote:

                                Hi Andrea and Justin,

                I will be working on SOS implementation in GeoServer in last quarter of this year and currently doing some scoping work and studying on GeoServer source code to see how I can implement it. Have a chat with Ben just now and he pointed me to both of you and hope to get some pointers / helps from both of you on some of thougths I have on how to implement SOS in GeoServer.

                FYI, I have deployed a copy of 52NorthSOS in our test server that generate some time series observations information [1]. I found that the GetCapabilities and GetObservations output are very much similar to WFS GetCapabilities and GetObservations output. e.g. The SOS observation output from SOS is basically a WFS output that wraps in a SOAP envelope body (correct me if I am wrong...).

                While studying the GetCapabilities implementation for WFS in GeoServer, I can see a lot of complex implementations including the use of Eclipse Modeling Framework in GeoTools to generate the WFS model (well, i don't fully understand the whole implementation yet... ).

                So, my thought would be since SOS output is just WFS output wraps in a SOAP envelope body and rather than creating from scratch a whole new service for SOS in GeoServer/GeoTools, we can make use of the existing WFS and App-Schema modules to generate a SOS output - making implementation simpler. Wonder if this is possible ? And if possible, how do I achieve this - writing SOAP implementation in GeoServer ?

                [1] http://services-test.auscope.org/52nSOSv350/testClient-SOSv2.html

                Note :
                Eventhough I have few years GeoServer deployment experience but honestly speaking, I am still very new with GeoServer development and hoping to find some "mentors" or "sifus" who are willing to help or point me to the right direction with this SOS implementation in GeoServer project.

                Thanks & Regards,

                Florence Tan
                Research Projects Officer | ASRDC
                CSIRO Earth Science and Resource Engineering

                Phone: +61 8 6436 8802 <tel:%2B61%C2%A08%C2%A06436%C2%A08802> | Fax: +61 8 6436 8555
                florence.tan@anonymised.com | www.csiro.au
                Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

                PLEASE NOTE
                The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

                Please consider the environment before printing this email.

                ------------------------------------------------------------------------------
                Live Security Virtual Conference
                Exclusive live event will cover all the ways today's security and
                threat landscape has changed and how IT managers can respond. Discussions
                will include endpoint security, mobile security and the latest in malware
                threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
                _______________________________________________
                Geoserver-devel mailing list
                Geoserver-devel@lists.sourceforge.net
                https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

Thanks Florence, this is helpful.

Just to reiterate what Justin was getting out, do try to not make the SOS stuff dependent at all on App Schema stuff. AppSchema is a great set of work for people with really complex requirements. It pushes the bounds of how much configuration is required for GeoServer (and I still do someday want to try to find a GUI that makes configuration of it easier, but that’s a huge task).

For SOS I’d ideally like to see it meet the normal standards of GeoServer configuration, which is that every thing is as easy as possible to configure in the standards. The approach should be ‘standard by default’. So the ideal would be is that ever vector featureType automatically has some representation in the SOS capabilities. If it doesn’t have quite the right elements it makes some guesses. If time is super important than maybe it only shows up if the ‘time’ tab of the resource is configured right, but shows up in SOS as soon as it is there. SOS does look like a more locked down schema, so maybe one or two properties need to be ‘mapped’/set. But that should be possible to do in the GUI. Perhaps at the extreme we drop in an ‘SOS’ tab in the wicket layer page GUI, that gives a gui to map the properties. But ideally it’s not SOS specific, and other future services could make use of the same mappings (time in particular is used by several, not sure of the others). And these mappings I believe should be done at an object level, not in some AppSchema mapping file. This will make it so more people can hack on it, instead of just those with experience with AppSchema. I understand that AppSchema is more than powerful enough to handle this, but I fear that everything looks like a nail with the hammer that is AppSchema.

And please try to avoid any text configuration files for setting up an SOS or configuring a SOS layer. I definitely understand if you don’t have the time for a full GUI, but I see it essential if we want to get SOS in to extensions or core (which I hope is your goal, it’d be a nice win). I do think if done right this work could help drive more datastores in GeoServer, coming direct from sensors, which then would automatically appear in WMS/WFS along with the more specific SOS. So like you would see particular datastores that are automatically configured for SOS - they don’t need to do any ‘mapping’ of properties because they know that certain fields are set in the source. So then like instead of convincing sensor providers to write generic connectors and then always having to do a mapping to get SOS they could just do something write a SOSDataStore that extends DataStore and is guaranteed to be configured by default for SOS, but also pops up with WFS and WMS, with time configured for animations (could be awesome if it also has some nice default SLD’s that are SOS aware).

Anyways, sorry for the dump, and some of my tech advice may be well outdated. But from a ‘product’ perspective I’d love to see SOS a top level GeoServer protocol, as I think if done right we can help promote SOS a lot, but only if we do some really nice stuff by default. I’m psyched you’re taking on this work, should be a nice improvement.

best regards,

Chris

On Tue, Sep 18, 2012 at 11:35 PM, <Florence.Tan@anonymised.com> wrote:

Thanks Justin & Chris for the feedback.

Before going into the overview of the Sensor Observation Service (SOS) Specification, would like to give brief background info about the rise of the SOS implementation in GeoServer :

=================
Brief Background

Last financial year, we did some review on a few open source SOS services available e.g. 52North, MapServer and Deegree and concluded that 52North SOS is the best option as it is the only SOS that support SOS 2.0 specification with good implementation documentation. However, it is still not the best solution with the limitations such as:
=> only support PostgreSQL DB at the moment
=> require good understanding of their database schema for database mapping
=> feeding data require good knowledge of sql or other feeder tool (e.g. ETL, script, etc)
=> limited to only OM result model that tie to SWE Common model at that moment, it now has a branch with OM result model that tie to WaterML model
=> any changes required in the result mapping require changes in the source code
=> manual mapping of sensor information using sensorML schema

The above limitations are something we hope to resolve by implementing the SOS service in GeoServer as we know that GeoServer :
=> support broad selection of data stores
=> able to use existing datastore without altering it
=> flexibility of creating different OM result model - base on the concept of Application Schema configuration file
=> similar to creating the Observation using Application Schema configuration file concept, sensor information can be published thru a standard configuration file

Additional to above review, we also did some comparison with the time series observation results published through GeoServer WFS (version 1.1 as Application Schema only support up to 1.1 now) and 52NorthSOS (SOS version 2.0), some observations recorded and comments from users :
=> In WFS1.1, there is no concept of observation, procedure, observedProperty, time or number of records, however, a complex feature could be specified that contains all of these concepts, such as WaterML.
=> When it comes to huge amount of time-series observation, SOS is the better option as there is option of filter by time range / time period
=> user is able to find out the bounding box time range of the dataset from the SOS GetCapabilities operation and making filter request easier
=> a good presentation by 52NorthSOS comparing SOS1.0 and WFS1.1 @ http://2010.foss4g.org/presentations/3800.pdf

===========================================================
Overview summary of the SOS 2.0 Specification (OGC 12-006)

SOS Standard Overview - The standard defines a web service interface for the discovery and retrieval of real time or archived data (particular time-series observations) produced by all kinds of sensors like mobile or stationary as well as in-situ or remote sensors. The requirements classes defined by the SOS 2.0 standard :

Core : GetCapabilities, DescribeSensor and GetObservation
Transactional : Insert Capabilities, Sensor Insertion, Sensor Delition, Observation insertion
Result Handling : Result insertion, Result Retrieval
Enhanced Operations : Observation retrieval by ID, FeatureOfInterest Retrieval
Filter Operations : Spatial filters, Temporal Filters
Binding : XML Encoding, SOAP Binding, Core KVP Binding, GetFeatureOfInterest KVP Binding, Result Retrieval KVP binding

For a start, will concentrate on the following minimum requirements standard :
Core Opertations : GetCapabilities, DescribeSensor and GetObservation
Filter Operations : Spatial filter (BBOX), Temporal Filter (TEquals, During)

From the SOS2.0 specification Annex D - Relationship to Other OGC Web Service Standards - describes the relationships between SOS and WFS and how to couple the two. There are two type of relationships as below :

(1) Relationship between SOS and WFS where WFS is providing feature of interest - SOS providing O&M observations for certain feature of interest and the features are provided by an external WFS.
(2) Relationship between SOS and WFS where SOS is encapsulating WFS - SOS is using a WFS at the backend for handling the feature of interest. SOS offers both the observations as well as the features of interest.

Option 1 is preferred where SOS will be used mainly for providing O&M observations.

====================================================================
Core Operations: GetCapabilities, DescribeSensor and GetObservation

(1) GetCapabilities

Overview - The GetCapabilities operation returns a service description containing information about the service interface (e.g. supported operations, service version) and the available sensor data (e.g. registered sensors, time period of available observations, spatial extent of features for which observations are available).

Request base on the OWS Common standard :
e.g. http://hostname/geoserver/ows?service=SOS&request=GetCapabilities&AcceptVersions=2.0.0

Response data type derives from OWS Common OWSServiceMetadata data type :

  • ServiceIdentification
  • ServiceProvider
  • OperationsMetadata
  • FilterCapabilities
  • Contents

Examples bundled in SOS 2.0 schema :
GetCapabilities request (SOAP binding) : http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1.xml
GetCapabilities response (SOAP binding) : http://schemas.opengis.net/sos/2.0/examples/core/GetCapabilities1_response.xml

(2) DescribeSensor

Overview : The DescribeSensor operation returns a description of one specific sensor, sensor system or data producing procedure containing information like position of sensor, calibration, input- and outputs, etc. The response has to be either encoded in SensorML or in TML.

Request base on the OWS Common standard :

example 1 (with mandatory parameters ) :
http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=DescribeSensor&procedure=urn:ogc:object:Sensor:MyOrg:thermometer1
&procedureDescriptionFormat=http://www.opengis.net/sensorML/1.0.1

example 2 (with both mandatory and optional parameter) :
http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=DescribeSensor&procedure=urn:ogc:object:Sensor:MyOrg:thermometer1
&procedureDescriptionFormat=http://www.opengis.net/sensorML/1.0.1&validTime=2010-01-01T18:31:42Z

Examples bundled in SOS 2.0 schema :
DescribeSensor request : http://schemas.opengis.net/sos/2.0/examples/SOAP/DescribeSensor1_SOAP.xml

(3) GetObservation

Overview : The GetObservation operation returns a collection of observations. Each observation is composed of metadata, description of the phenomena being returned (parameter names, units of measure, reference systems) and values. The default and mandatory response format is base on O&M 2.0 specification.

Request base on the OWS Common standard :

example 1 (with mandatory parameters) :
http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=GetObservation

example 2 (with both mandatory and optional parameters) :
[http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=GetObservation&offering=http://www.my_namespace.org/thermometer1_observations&observedProperty=http://sweet.jpl.nasa.gov/2.0/atmoThermo.owl#EffectiveTemperature&procedure=http://www.my_namespace.org/sensors/thermometer1&featureOfInterest=http://wfs.example.org?request=getFeature&amp;featureid=building1&namespaces=xmlns(sams,http://www.opengis.net/samplingSpatial/2.0),xmlns(om](http://hostname/geoserver/ows?service=SOS&version=2.0.0&request=GetObservation&offering=http://www.my_namespace.org/thermometer1_observations&observedProperty=http://sweet.jpl.nasa.gov/2.0/atmoThermo.owl#EffectiveTemperature&procedure=http://www.my_namespace.org/sensors/thermometer1&featureOfInterest=http://wfs.example.org?request=getFeature&amp;featureid=building1&namespaces=xmlns(sams,http://www.opengis.net/samplingSpatial/2.0),xmlns(om),
http://www.opengis.net/om/2.0)&spatialFilter=om:featureOfInterest/*/sams:shape,22.32,11.2,32.32,22.2,urn:ogc:def:crs:EPSG::4326&temporalFilter=om:phenomenonTime,2009-01-10T10:00:00Z/2009-01-10T11:00:00Z&spatialFilter=om:featureOfInterest/*/sams:shape,22.32,11.2,32.32,22.2,urn:ogc:def:crs:EPSG::4326&temporalFilter=om:phenomenonTime,2009-01-10T10:00:00Z/2009-01-10T11:00:00Z)

Examples bundled in SOS 2.0 schema :
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps.xml <http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps.xml>
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps_response.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation2_obsProps_Procedure.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation2_obsProps_Procedure_response.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation3_foiIDFilter.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation3_foiIDFilter_response.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter.xml
http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter_response.xml

==================
Filter Operations:

Overview : The filter capabilities is imported from OGC 09-026r1/ISO 1914. The minimum requirement stated in the SOS 2.0 specification:

Spatial Filter Opertor : BBOX
Temporal Filter : TEquals operator in conjunction with the TimeInstant type
During operator in conjunction with the TimePeriod type.

Example bundled in SOS 2.0 schema :
Spatial Filter : http://schemas.opengis.net/sos/2.0/examples/core/GetObservation4_spatialFilter.xml
Temporatl Filter (TimeInstant) : http://schemas.opengis.net/sos/2.0/examples/core/GetObservation1_obsProps.xml

I hope the above SOS 2.0 specification overview is clear enough to provide some basic understanding of SOS 2.0 standard. Do let me know if more information are needed.

Thanks & Regards,
Florence

From: Justin Deoliveira [mailto:jdeolive@anonymised.com]
Sent: Monday, 17 September 2012 11:30 PM
To: Chris Holmes
Cc: Tan, Florence (CESRE, Kensington); andrea.aime@anonymised.com; geoserver-devel@lists.sourceforge.net; Mike Botts
Subject: Re: [Geoserver-devel] Sensor Observation Service (SOS) Implementation In GeoServer

Hi Florence,

As discussed in the meeting I don’t think either Andrea or myself is up to speed on SOS so having a nice overview of the spec would be helpful. The same way Andrea did for CSW. With that we will be in a better situation to provide architectural guidance.

That said, the same approach taken for CSW might be nicely applied here as well. Essentially coming with a back end interface to encapsulate the core service implementation details behind. This way we don’t necessarily have to tie things to a WFS / app-schema implementation, but can easily build one.

$0.02

-Justin

On Mon, Sep 17, 2012 at 6:30 AM, Chris Holmes <cholmes@anonymised.com> wrote:

Another library you might refer to and potentially incorporate is https://code.google.com/p/ows-service-framework/

Mike Botts, who lead spec development of SWE stuff, has been building up that library. And we’ve talked with him a few times about eventually incorporating it in to the GeoServer/GeoTools code base.

Not sure if the code can be easily incorporated in its existing state, but it is license compatible, and at the very least could be inspiration.

On Mon, Sep 17, 2012 at 5:45 AM, Florence.Tan@anonymised.com wrote:

Hi Andrea and Justin,

I will be working on SOS implementation in GeoServer in last quarter of this year and currently doing some scoping work and studying on GeoServer source code to see how I can implement it. Have a chat with Ben just now and he pointed me to both of you and hope to get some pointers / helps from both of you on some of thougths I have on how to implement SOS in GeoServer.

FYI, I have deployed a copy of 52NorthSOS in our test server that generate some time series observations information [1]. I found that the GetCapabilities and GetObservations output are very much similar to WFS GetCapabilities and GetObservations output. e.g. The SOS observation output from SOS is basically a WFS output that wraps in a SOAP envelope body (correct me if I am wrong…).

While studying the GetCapabilities implementation for WFS in GeoServer, I can see a lot of complex implementations including the use of Eclipse Modeling Framework in GeoTools to generate the WFS model (well, i don’t fully understand the whole implementation yet… ).

So, my thought would be since SOS output is just WFS output wraps in a SOAP envelope body and rather than creating from scratch a whole new service for SOS in GeoServer/GeoTools, we can make use of the existing WFS and App-Schema modules to generate a SOS output - making implementation simpler. Wonder if this is possible ? And if possible, how do I achieve this - writing SOAP implementation in GeoServer ?

[1] http://services-test.auscope.org/52nSOSv350/testClient-SOSv2.html

Note :
Eventhough I have few years GeoServer deployment experience but honestly speaking, I am still very new with GeoServer development and hoping to find some “mentors” or “sifus” who are willing to help or point me to the right direction with this SOS implementation in GeoServer project.

Thanks & Regards,

Florence Tan
Research Projects Officer | ASRDC
CSIRO Earth Science and Resource Engineering

Phone: +61 8 6436 8802 tel:%2B61 8 6436 8802 | Fax: +61 8 6436 8555

florence.tan@anonymised.com | www.csiro.au
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, Kensington WA 6151

PLEASE NOTE
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference.

Please consider the environment before printing this email.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.