[Geoserver-devel] SOS 2.0 Implementation

GeoServer GeoServer Developer
1

After spending a few days experimenting and skilling up on SOS, I found the approach I have taken is totally off track. I kept treating SOS 2.0 as wfs because they look similar. I kept trying to kick/push/punch sos into wfs trying to reuse all the wfs library such as featuresource, GetFeature etc etc.

I tried modifying sos request into a wfs request, wrapping a wfs response out into a sos response. Totally the wrong approach.

I am starting to feel that the work required to do this is alot bigger then I has initially imagined. For a start, perhaps the right way to approach this is to have its own SOSFeatureSource, its own iterator, basically its own GT module. It own set of configuration (how ? at the moment I am clueless due as our use case require WaterML schema which is complex).

It should also have its own GetSOSFeature to handle getObservation request. My knowledge in the spatial domain are still limited and therefore would like to put my thoughts out there.

Please enlighten!!!

Thanks

Victor Tey

2

On Fri, Oct 5, 2012 at 9:07 AM, <Victor.Tey@anonymised.com> wrote:

After spending a few days experimenting and skilling up on SOS, I found the approach I have taken is totally off track. I kept treating SOS 2.0 as wfs because they look similar. I kept trying to kick/push/punch sos into wfs trying to reuse all the wfs library such as featuresource, GetFeature etc etc.

I tried modifying sos request into a wfs request, wrapping a wfs response out into a sos response. Totally the wrong approach.

I am starting to feel that the work required to do this is alot bigger then I has initially imagined. For a start, perhaps the right way to approach this is to have its own SOSFeatureSource, its own iterator, basically its own GT module. It own set of configuration (how ? at the moment I am clueless due as our use case require WaterML schema which is complex).

It should also have its own GetSOSFeature to handle getObservation request. My knowledge in the spatial domain are still limited and therefore would like to put my thoughts out there.

What you suggest is the same approach I took for CSW, even if in some ways it’s quite similar to
WFS as well (GetRecords looks a lot like GetFeature).
I’ve tried to reuse as many classes/concepts as possible, like, records are represented as feature
and feature collection, but did not force the whole thing to be a DataStore, created a CatalogStore
instead, trying to keep it as simple as possible again.

The whole service level is custom, and while it has similarities with WFS, it’s not the same thing
and trying to go for an adaptation would have been indeed rather ugly

In my case I have no configuration but I’d suggest to think about it separating what you
need to configure at the data source level (which should be pluggable, something that could
be replaced) with the service configuration level, which should be stored in a SOSInfo object

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it