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 > [email protected] > http://lists.gispython.org/mailman/listinfo/community _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
