> -----Original Message----- > From: Dominic Lowe [mailto:[email protected]] > Sent: Thursday, 24 September 2009 04:29 > To: Kralidis,Tom [Ontario] > Cc: gispython.org community projects > Subject: Re: [Community] New OWSLib interfaces test > > 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']. >
I've changed the output model for query responses to be dictionaries. Check out http://trac.gispython.org/lab/changeset/1464 and let me know if this makes sense. > > > > > 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/int > erfaces.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.) > Is this blocking a release? If yes, I would suppport this. If there are other issues, I may have some time in the next couple of weeks to lock down SOS support. > 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
