Hi Tom, Comments inline:
On Tuesday 22 September 2009 14:41:36 Kralidis,Tom [Ontario] wrote: > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of > > Dominic Lowe > > Sent: Thursday, 17 September 2009 08:44 > > To: gispython.org community projects > > Subject: [Community] New OWSLib interfaces test > > > > Hi all, > > > > I have just added a new test to OWSLib to check that all service types > > (WMS/WCS/WFS/CSW) comply with the OWSLib OWSCommonesque > > service definitions. > > > > the test is here: > > http://trac.gispython.org/lab/browser/OWSLib/trunk/tests/ows_i > > nterfaces.txt > > > > and the interface definitions here: > > http://trac.gispython.org/lab/browser/OWSLib/trunk/owslib/inte > > rfaces.py > > > > You can run this test from the tests directory using: > > python runalldoctests.py -t ows_interfaces.txt > > > > It doesn't pass yet - but it's close! There are some issues > > with the way contents is implemented in CSW - it uses a list, > > the others use a dictionary. > > The WCS also has a couple of attribute issues I need to look at. > > True. Currently, CSW stores GetRecords (you're talking about GetRecords > output, right?) in a list, i.e. self.results['records'][0].title > > Would we want something like self.results['record1'].title? That's what all the other services do so it makes sense to align their behaviour. (Although the interfaces specify a list.. but I think this was from earlier thinking and needs updating). It would be good to add an items() method to the CSW object (like this: http://trac.gispython.org/lab/browser/OWSLib/trunk/owslib/wms.py#L128) That will enable you to retrieve records just by doing csw['record1']. > > > We may also want to consider if the interfaces are still > > correct - IContentMetadata particularly seems a bit WMS > > specific now (e.g. has a 'styles' attribute). > > I think we need two high level interfaces (one for services, one for > contents), for Capabilities at least. Ideas: > > Services: we could model after OWS Common, which is what most (those who > aren't, will) OWS's are leveraging for service metadata. > > So any OWS will have service metadata per OWS Common, and house Filter > Capabilities as well. Respective services will then extend the > "contents" metadata per their spec. > > Thoughts? I agree this is a good approach. Sean has already modelled the service interfaces here (http://trac.gispython.org/lab/browser/OWSLib/trunk/owslib/interfaces.py) after OWS Common - but with a pythonic interpretation. I think the issue though is that the iContentMetadata interface may be too WMS specific now. > > > Also I am sure this cross-service test could be expanded > > greatly - feel free to improve upon what's there. > > > > Cheers > > Dom > > > > > > p.s. Just realised I've completely missed off SOS - not > > sure where this is up to? Is it working? I couldn't see any > > tests for it. > > I haven't worked on SOS for awhile, I'll look into this when I get a > chance. > Maybe for now we should put SOS into an "owslib.experimental" package along with WFS 2.0? That way they don't hold us back from making a new release (they could still be in the release but in the 'experimental' package.) Cheers Dom > > _______________________________________________ > > Community mailing list > > [email protected] > > http://lists.gispython.org/mailman/listinfo/community _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
