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....@csiro.au> 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&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.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:jdeol...@opengeo.org]
> Sent: Monday, 17 September 2012 11:30 PM
> To: Chris Holmes
> Cc: Tan, Florence (CESRE, Kensington); andrea.a...@geo-solutions.it;
> 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 <chol...@opengeo.org> 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....@csiro.au> 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....@csiro.au | 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.
>
>
------------------------------------------------------------------------------
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
