OWSLib SOS and interface additions extensions

[Kralidis,Tom [Ontario]]

Hi: I've started to work on this, and am putting forth
ISensorObservationService(IService).

As an example, here is an example SOS GetCapabilities:

http://devgeo.cciw.ca/cgi-bin/mapserv/sostest?service=SOS&version=1.0.0&
request=GetCapabilities

The SOS output maps nicely to the exising internal OWSLib model for
ServiceIdentification (nice work guys!).  The OWS Common XML is
structured differently, but I've fitted this into ServiceIdentification.

Same thing for OperationsMetadata.  SOS always returns text/xml so I
will hardcode formatOptions.

For ServiceProvider, OWS Common does add more, which I have added in
owslib/sos.py.  I will have to go over w*s.py and def None vals for
those.  General question: where the property exists in the interface
def, but not in the given spec, do we None these or just do nothing?

SOS advertises (and implements) Filter 1.1.0.  I propose to start
classing this as IFilterCapabilities?  Note owslib/wfs.py, implementing
WFS 1.0.0, uses Filter 1.0.0.  So we'll make a generic internal model
which can apply to 1.0.0 and 1.1.0.  Comments?

Now, for SOS ContentMetadata; SOS's ContentMetadata consists of a list
of ObservationOfferings (ObservationOfferingList).

Each ObservationOffering has:

id: ""
name: ""
Description: ""
srs: []
boundingBox: {srs: "", bbox: []}
timePeriod: {}
procedure: [] # this is the list of, say, stations, measuring said
Observation
observedProperty: [CompositePhenomenon: [] ]
responseFormat: ""
resultModel: []
responseMode: ""

We can certainly map some of these to IContentMetadata.  Any
comments/objections on classing
ISensorContentMetadata(IContentMetadata)?

Thanks

..Tom
_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Sean Gillies]

Kralidis,Tom [Burlington] wrote:

> Hi: I've started to work on this, and am putting forth
> ISensorObservationService(IService).
>
> As an example, here is an example SOS GetCapabilities:
>
> http://devgeo.cciw.ca/cgi-bin/mapserv/sostest?service=SOS&version=1.0.0&
> request=GetCapabilities
>
> The SOS output maps nicely to the exising internal OWSLib model for
> ServiceIdentification (nice work guys!).  The OWS Common XML is
> structured differently, but I've fitted this into ServiceIdentification.
>
> Same thing for OperationsMetadata.  SOS always returns text/xml so I
> will hardcode formatOptions.
>
> For ServiceProvider, OWS Common does add more, which I have added in
> owslib/sos.py.  I will have to go over w*s.py and def None vals for
> those.  General question: where the property exists in the interface
> def, but not in the given spec, do we None these or just do nothing?
>

If you feel anything is lacking in the interfaces, please add them to
the interfaces. Our approach is to be complete, but more terse than, the
OGC XML specifications. You've probably already got the flavor from
looking through the code.

Let's reserve None for the null case. If a service has no provider at
all (pardon the nonsensical example), return None. If it's the case that
the class doesn't provide all of the interface, I think it's okay to let
an exception be raised. We can discuss with Dominic whether we'd rather
let it be an AttributeError or a NotImplemented error.

> SOS advertises (and implements) Filter 1.1.0.  I propose to start
> classing this as IFilterCapabilities?  Note owslib/wfs.py, implementing
> WFS 1.0.0, uses Filter 1.0.0.  So we'll make a generic internal model
> which can apply to 1.0.0 and 1.1.0.  Comments?
>

So I guess this will lead to implementing OGC Filter?

> Now, for SOS ContentMetadata; SOS's ContentMetadata consists of a list
> of ObservationOfferings (ObservationOfferingList).
>
> Each ObservationOffering has:
>
> id: ""
> name: ""
> Description: ""
> srs: []
> boundingBox: {srs: "", bbox: []}
> timePeriod: {}
> procedure: [] # this is the list of, say, stations, measuring said
> Observation
> observedProperty: [CompositePhenomenon: [] ]
> responseFormat: ""
> resultModel: []
> responseMode: ""
>
> We can certainly map some of these to IContentMetadata.  Any
> comments/objections on classing
> ISensorContentMetadata(IContentMetadata)?
>
> Thanks
>
> ..Tom

That's the right approach.

Sean

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Kralidis,Tom [Ontario]]

 

> -----Original Message-----
> From: community-bounces@...
> [mailto:community-bounces@...] On Behalf Of
> Sean Gillies
> Sent: 05 September, 2008 1:46 PM
> To: gispython.org community projects
> Subject: Re: [Community] OWSLib SOS and interface additions extensions
>
> Kralidis,Tom [Burlington] wrote:
> > Hi: I've started to work on this, and am putting forth
> > ISensorObservationService(IService).
> >
> > As an example, here is an example SOS GetCapabilities:
> >
> >
> http://devgeo.cciw.ca/cgi-bin/mapserv/sostest?service=SOS&version=1.0

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Dominic Lowe]

Hi Tom, Sean,

> > (TOM)  General question: where the property exists in the interface
> > def, but not in the given spec, do we None these or just do nothing?
>


> (SEAN) Let's reserve None for the null case. If a service has no provider at
> all (pardon the nonsensical example), return None. If it's the case that
> the class doesn't provide all of the interface, I think it's okay to let
> an exception be raised. We can discuss with Dominic whether we'd rather
> let it be an AttributeError or a NotImplemented error.


I'm glad you brought this up as it's been nagging me that it's not consistent
across OWSLib (and I've added to the inconsistency in many cases...)

I agree with reserving None for the null case. I like the idea of raising
NotImplemented for properties that exist in the interface but not in the
given spec, and raising AttributeError for attributes that are just wrong
e.g. wfs.banana

Cheers,
Dominic

On Friday 05 September 2008 18:45:37 Sean Gillies wrote:

> Kralidis,Tom [Burlington] wrote:
> > Hi: I've started to work on this, and am putting forth
> > ISensorObservationService(IService).
> >
> > As an example, here is an example SOS GetCapabilities:
> >
> > http://devgeo.cciw.ca/cgi-bin/mapserv/sostest?service=SOS&version=1.0.0&
> > request=GetCapabilities
> >
> > The SOS output maps nicely to the exising internal OWSLib model for
> > ServiceIdentification (nice work guys!).  The OWS Common XML is
> > structured differently, but I've fitted this into ServiceIdentification.
> >
> > Same thing for OperationsMetadata.  SOS always returns text/xml so I
> > will hardcode formatOptions.
> >
> > For ServiceProvider, OWS Common does add more, which I have added in
> > owslib/sos.py.  I will have to go over w*s.py and def None vals for
> > those.  General question: where the property exists in the interface
> > def, but not in the given spec, do we None these or just do nothing?
>
> If you feel anything is lacking in the interfaces, please add them to
> the interfaces. Our approach is to be complete, but more terse than, the
> OGC XML specifications. You've probably already got the flavor from
> looking through the code.
>
> Let's reserve None for the null case. If a service has no provider at
> all (pardon the nonsensical example), return None. If it's the case that
> the class doesn't provide all of the interface, I think it's okay to let
> an exception be raised. We can discuss with Dominic whether we'd rather
> let it be an AttributeError or a NotImplemented error.
>
> > SOS advertises (and implements) Filter 1.1.0.  I propose to start
> > classing this as IFilterCapabilities?  Note owslib/wfs.py, implementing
> > WFS 1.0.0, uses Filter 1.0.0.  So we'll make a generic internal model
> > which can apply to 1.0.0 and 1.1.0.  Comments?
>
> So I guess this will lead to implementing OGC Filter?
>
> > Now, for SOS ContentMetadata; SOS's ContentMetadata consists of a list
> > of ObservationOfferings (ObservationOfferingList).
> >
> > Each ObservationOffering has:
> >
> > id: ""
> > name: ""
> > Description: ""
> > srs: []
> > boundingBox: {srs: "", bbox: []}
> > timePeriod: {}
> > procedure: [] # this is the list of, say, stations, measuring said
> > Observation
> > observedProperty: [CompositePhenomenon: [] ]
> > responseFormat: ""
> > resultModel: []
> > responseMode: ""
> >
> > We can certainly map some of these to IContentMetadata.  Any
> > comments/objections on classing
> > ISensorContentMetadata(IContentMetadata)?
> >
> > Thanks
> >
> > ..Tom
>
> That's the right approach.
>
> Sean
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community