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