New OWSLib interfaces test

[Dominic Lowe-2]

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_interfaces.txt

and the interface definitions here:
http://trac.gispython.org/lab/browser/OWSLib/trunk/owslib/interfaces.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.

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).

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.
_______________________________________________
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
> 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?

> 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?

> 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.

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

[Dominic Lowe-2]

Hi Tom,

Comments inline:



On Tuesday 22 September 2009 14:41:36 Kralidis,Tom [Ontario] wrote:

> > -----Original Message-----
> > From: community-bounces@...
> > [mailto:community-bounces@...] 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
> > Community@...
> > http://lists.gispython.org/mailman/listinfo/community


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

[Kralidis,Tom [Ontario]]

 

> -----Original Message-----
> From: Dominic Lowe [mailto:dominic.lowe@...]
> 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: community-bounces@...
> > > [mailto:community-bounces@...] 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
> > > Community@...
> > > http://lists.gispython.org/mailman/listinfo/community
>
>
>

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

[Dominic Lowe-2]

Hi Tom,

Sorry for the delay in replying.

> 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.
>

Looks good. I haven't tried it out yet but will do when I get a chance.

On Wednesday 07 October 2009 19:58:24 Kralidis,Tom [Ontario] wrote:
> > 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.


I'm not going to be able to do anything on it for a couple of weeks anyway,
but it would be quite nice to get a new release out soon. There have been a
lot of fixes and developments so the 3.1 easy install is now a bit out of
date.

So basically I think if you do get a chance to work on SOS soon then we should
keep it in, if not, then we should move it.

I think I will move the WFS 2.0 stuff to an experimental branch anyway.

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

[Kralidis,Tom [Ontario]]

 

> -----Original Message-----
> From: Dominic Lowe [mailto:dominic.lowe@...]
> Sent: Tuesday, 13 October 2009 11:06
> To: Kralidis,Tom [Ontario]
> Cc: gispython.org community projects
> Subject: Re: [Community] New OWSLib interfaces test
>
> Hi Tom,
>
> Sorry for the delay in replying.
>
> > 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.
> >
>
> Looks good. I haven't tried it out yet but will do when I get
> a chance.
>
> On Wednesday 07 October 2009 19:58:24 Kralidis,Tom [Ontario] wrote:
> > > 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.
>
>
> I'm not going to be able to do anything on it for a couple of
> weeks anyway, but it would be quite nice to get a new release
> out soon. There have been a lot of fixes and developments so
> the 3.1 easy install is now a bit out of date.
>
> So basically I think if you do get a chance to work on SOS
> soon then we should keep it in, if not, then we should move it.
>

I've been bogged down in the last week or so, so I would say +1 to moving WFS 2.0 and SOS 1.0.0 to an experimental release when we cut a new release.

> I think I will move the WFS 2.0 stuff to an experimental
> branch anyway.
>
> Cheers
> Dom
>
_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Dominic Lowe-2]

On Wednesday 14 October 2009 16:47:20 Kralidis,Tom [Ontario] wrote:
> I've been bogged down in the last week or so, so I would say +1 to moving
> WFS 2.0 and SOS 1.0.0 to an experimental release when we cut a new release.

Okay, sounds like a plan.

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

[Sean Gillies-2]

On Oct 15, 2009, at 10:45 AM, Dominic Lowe wrote:

> On Wednesday 14 October 2009 16:47:20 Kralidis,Tom [Ontario] wrote:
>> I've been bogged down in the last week or so, so I would say +1 to  
>> moving
>> WFS 2.0 and SOS 1.0.0 to an experimental release when we cut a new  
>> release.
>
> Okay, sounds like a plan.
>

I've brought this up before, but didn't get a yes or no: how about  
making owslib a namespace package? Then owslib.sos could be released  
separately from owslib.wms (and owslib.core?), when ready and as needed.

Cheers,

--
Sean

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

[Dominic Lowe-2]

On Thursday 15 October 2009 09:55:15 Sean Gillies wrote:

> On Oct 15, 2009, at 10:45 AM, Dominic Lowe wrote:
> > On Wednesday 14 October 2009 16:47:20 Kralidis,Tom [Ontario] wrote:
> >> I've been bogged down in the last week or so, so I would say +1 to
> >> moving
> >> WFS 2.0 and SOS 1.0.0 to an experimental release when we cut a new
> >> release.
> >
> > Okay, sounds like a plan.
>
> I've brought this up before, but didn't get a yes or no: how about
> making owslib a namespace package? Then owslib.sos could be released
> separately from owslib.wms (and owslib.core?), when ready and as needed.
>

Actually this is a good idea... it would simplify the release process in the
long run.

That's a yes from me. :)

Cheers
Dom

> Cheers,
>
> --
> Sean
>
> _______________________________________________
> Community mailing list
> Community@...
> http://lists.gispython.org/mailman/listinfo/community


_______________________________________________
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
> Dominic Lowe
> Sent: Thursday, 15 October 2009 05:32
> To: community@...
> Subject: Re: [Community] New OWSLib interfaces test
>
> On Thursday 15 October 2009 09:55:15 Sean Gillies wrote:
> > On Oct 15, 2009, at 10:45 AM, Dominic Lowe wrote:
> > > On Wednesday 14 October 2009 16:47:20 Kralidis,Tom
> [Ontario] wrote:
> > >> I've been bogged down in the last week or so, so I would
> say +1 to
> > >> moving WFS 2.0 and SOS 1.0.0 to an experimental release
> when we cut
> > >> a new release.
> > >
> > > Okay, sounds like a plan.
> >
> > I've brought this up before, but didn't get a yes or no: how about
> > making owslib a namespace package? Then owslib.sos could be
> released
> > separately from owslib.wms (and owslib.core?), when ready
> and as needed.
> >
>
> Actually this is a good idea... it would simplify the release
> process in the long run.
>
> That's a yes from me. :)
>

+1

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

[Dominic Lowe-2]

Okay, that's 3 yes votes..

I've had a first attempt at doing this in a branch:
http://trac.gispython.org/lab/changeset/1465

I've created stub packages for owslib_wms and owslib_wcs, with owslib
(hopefully) acting as a namespace package for both. They each have a setup.py
and can be made into eggs.

However I'm not 100% sure I've got it right, so please try it out and let me
know. Sean - do you have some experience of creating namespace packages?

For convenience I've built eggs in the ./eggsrepo/ directory so if you check
out the branch you should be able to do.

easy_install -U -f <pathto>/eggsrepo/ OWSLib

Which will install the OWSLib egg and it's dependencies: OWSLib_WMS and
OWSLib_WCS eggs.

You should be able to do this as before:
>>> from owslib.wms import WebMapService
>>> from owslib.wcs import WebCoverageService


However if you do:
>>> import owslib
you get owslib from the OWSLib_WMS egg. Is that correct? I guess it's just
where it was imported first?

Cheers,
Dom




On Thursday 15 October 2009 13:00:50 Kralidis,Tom [Ontario] wrote:

> > -----Original Message-----
> > From: community-bounces@...
> > [mailto:community-bounces@...] On Behalf Of
> > Dominic Lowe
> > Sent: Thursday, 15 October 2009 05:32
> > To: community@...
> > Subject: Re: [Community] New OWSLib interfaces test
> >
> > On Thursday 15 October 2009 09:55:15 Sean Gillies wrote:
> > > On Oct 15, 2009, at 10:45 AM, Dominic Lowe wrote:
> > > > On Wednesday 14 October 2009 16:47:20 Kralidis,Tom
> >
> > [Ontario] wrote:
> > > >> I've been bogged down in the last week or so, so I would
> >
> > say +1 to
> >
> > > >> moving WFS 2.0 and SOS 1.0.0 to an experimental release
> >
> > when we cut
> >
> > > >> a new release.
> > > >
> > > > Okay, sounds like a plan.
> > >
> > > I've brought this up before, but didn't get a yes or no: how about
> > > making owslib a namespace package? Then owslib.sos could be
> >
> > released
> >
> > > separately from owslib.wms (and owslib.core?), when ready
> >
> > and as needed.
> >
> >
> > Actually this is a good idea... it would simplify the release
> > process in the long run.
> >
> > That's a yes from me. :)
>
> +1
>
> ..Tom

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