add support for OGC WMS 1.3.0

[tomkralidis]

(carrying on from #25)

This includes support for namespaces WMS Capabilities XML, as well as coordinate order handling, etc.

[keas]

Hey Tom,
do you have any new information about support for WMS 1.3.0?

I'd love to use your lib. ;)

[tomkralidis]

hi @keas thanks for the info. No movement on this one yet. Contributions (patches, pull requests) are more than welcome to make this happen. A good start would be to start with what's in wms.py.

[roomthily]

Hi, is there still interest in adding support for WMS 1.3.0?

[tomkralidis]

@roomthily I would say yes there is significant interest. Contributions are welcome.

[roomthily]

Cheers.

I have a mostly working version, but had a question about the SRS/CRS handling in the current 1.1.1 class (returns one from what could be many?) and working up a few more doctest examples. I'm hoping to have something ready end of the week/early next week.

Are there any sort of contribution guidelines?

[jachym]

Hi,

just noting: be aware of the axis order issue (Y,X for some coordinate
systems)

J

út 3. 3. 2015 v 19:45 odesílatel roomthily notifications@github.com
napsal:

Cheers.

I have a mostly working version, but had a question about the SRS/CRS
handling in the current 1.1.1 class (returns one from what could be many?)
and working up a few more doctest examples. I'm hoping to have something
ready end of the week/early next week.

Are there any sort of contribution guidelines?

Reply to this email directly or view it on GitHub
#25 (comment).

[tomkralidis]

@roomthily this is great news! As far as contributing, I would suggest a clean PR against latest master (no merges/rewriting history) with:

• implementation
  • backwards compatibility: for WMS, I'm guessing this would mean making owslib/wms.py a stub which defaults to 1.1.1 unless specified otherwise by the caller
• tests (I would suggest 2 or more WMS servers to have tests against, which are stable and won't have downtime issues
• documentation (for some case we just import the doctests themselves into our Sphinx setup)

Having said this, we really should have contribution guidelines in a CONTRIBUTING.txt file.

[roomthily]

No worries - the WMS happy path is set up like the WFS/WCS.

If you have some good examples of the axis issues, please let me know and
thanks for the heads up!

Cheers.

On Tue, Mar 3, 2015 at 12:13 PM, Tom Kralidis notifications@github.com
wrote:

@roomthily https://github.com/roomthily this is great news! As far as
contributing, I would suggest a clean PR against latest master (no
merges/rewriting history) with:

• implementation
  • backwards compatibility: for WMS, I'm guessing this would mean
    making owslib/wms.py a stub which defaults to 1.1.1 unless
    specified otherwise by the caller
    • tests (I would suggest 2 or more WMS servers to have tests against,
      which are stable and won't have downtime issues
• documentation (for some case we just import the doctests themselves
  into our Sphinx setup)

Having said this, we really should have contribution guidelines in a
CONTRIBUTING.txt file.

—
Reply to this email directly or view it on GitHub
#25 (comment).

[roomthily]

So my CRS question relates to the BoundingBox element handling in the ContentMetadata. The existing code for WMS 1.1.1 returns the first BoundingBox (etree find) even though it's valid to have multiple BoundingBox element (I don't have a live service example right at hand for this). It's also valid to have multiple elements in the 1.3.0, from the National Atlas (in the airports1m layer):

<BoundingBox CRS="CRS:84"
            minx="-176.646" miny="17.7016" maxx="-64.8017" maxy="71.2854" />
<BoundingBox CRS="EPSG:4326"
            minx="17.7016" miny="-176.646" maxx="71.2854" maxy="-64.8017" />
<BoundingBox CRS="EPSG:2163"
            minx="-7.13345e+06" miny="-3.00665e+06" maxx="3.72355e+06" maxy="4.23839e+06" />

For backwards compatibility, I can do the same - return the first element - but Im curious if this was an intentional choice?

[tomkralidis]

@roomthily +1 for backwards compatibility. We could also introduce a crs_list type attribute if we want to cover this.

[ChrisBarker-NOAA]

As noted in #266 -- we get a failure on WMS 1.3 -- of course, the real solution is in the works with 1.3 support, but in the meantime, it would be nice to get a better error i.e. on first access. OWSlib should check the version of the server ,and return a nice useful NotImplementedError or something, rather than a random failure.

Maybe I'll try a patch for that as a fisrt step / contribution -- would that belong in wms.py?

[tomkralidis]

Given that we are so close to landing OGC WMS 1.3 here, IMHO it would be better to put effort into fixing the remaining issues (PR is here: #223) which then provides both 1.1.1 and 1.3.0 support. Having said this you could probably put some detection in https://github.com/geopython/OWSLib/blob/master/owslib/wms.py#L85 which would figure out it's a WMS 1.3.

[roomthily]

Ah, so close but still waiting on me :(? It is possible that I will have
time to deal with the suggestions octoberish but not earlier.

For NotImplemented, if it's added for one service + version, it should be
added for any others not supported. Two cents...

roomthily

On Tuesday, July 28, 2015, Tom Kralidis notifications@github.com wrote:

Given that we are so close to landing OGC WMS 1.3 here, IMHO it would be
better to put effort into fixing the remaining issues (PR is here: #223
#223) which then provides both
1.1.1 and 1.3.0 support. Having said this you could probably put some
detection in
https://github.com/geopython/OWSLib/blob/master/owslib/wms.py#L85 which
would figure out it's a WMS 1.3.

—
Reply to this email directly or view it on GitHub
#25 (comment).

[ChrisBarker-NOAA]

It is possible that I will have time to deal with the suggestions octoberish but not earlier.

darn.

And yes, a version check would be good everywhere, but you've got to start somewhere!

[roomthily]

I know, the version check would have been very handy for us this spring as
well.

Still no promises before October, but I may be able to find some little
chunks of time to make progress before then unless there's going to be
some major-ish release between now and then?

On Tue, Jul 28, 2015 at 9:43 AM, Chris Barker notifications@github.com
wrote:

It is possible that I will have time to deal with the suggestions
octoberish but not earlier.

darn.

And yes, a version check would be good everywhere, but you've got to start
somewhere!

—
Reply to this email directly or view it on GitHub
#25 (comment).

[tomkralidis]

Nothing planned at this point.

Sent from my iPhone

On Jul 28, 2015, at 11:50, roomthily notifications@github.com wrote:

I know, the version check would have been very handy for us this spring as
well.

Still no promises before October, but I may be able to find some little
chunks of time to make progress before then unless there's going to be
some major-ish release between now and then?

On Tue, Jul 28, 2015 at 9:43 AM, Chris Barker notifications@github.com
wrote:

It is possible that I will have time to deal with the suggestions
octoberish but not earlier.

darn.

And yes, a version check would be good everywhere, but you've got to start
somewhere!

—
Reply to this email directly or view it on GitHub
#25 (comment).

—
Reply to this email directly or view it on GitHub.

[ChrisBarker-NOAA]

I took a look at wms.py, line 85 -- but I thikn we need to do it before then -- the reader barfs out.

But I noticed something -- the user is passing in a version number (Or a default is being used), so the first check should be right there -- if anon-supported version is asked for, then an error should be raised right there.

Then, I think in the Reader code, we'll have to do the check early. Not sure if I"ll get any time to look at this more :-(

[roomthily]

Ah, there's two patterns - there's a parent WxS factory/router class that
may include version info and then there's just WxS classes as you describe.
But certainly straightforward for both cases to verify and bail.

roomthily

On Wed, Jul 29, 2015 at 3:45 PM, Chris Barker notifications@github.com
wrote:

I took a look at wms.py, line 85 -- but I thikn we need to do it before
then -- the reader barfs out.

But I noticed something -- the user is passing in a version number (Or a
default is being used), so the first check should be right there -- if
anon-supported version is asked for, then an error should be raised right
there.

Then, I think in the Reader code, we'll have to do the check early. Not
sure if I"ll get any time to look at this more :-(

—
Reply to this email directly or view it on GitHub
#25 (comment).

[tomkralidis]

With the 1.3 work perhaps version negotiation should go in the factory?

Sent from my iPhone

On Jul 29, 2015, at 18:06, roomthily notifications@github.com wrote:

Ah, there's two patterns - there's a parent WxS factory/router class that
may include version info and then there's just WxS classes as you describe.
But certainly straightforward for both cases to verify and bail.

roomthily

On Wed, Jul 29, 2015 at 3:45 PM, Chris Barker notifications@github.com
wrote:

I took a look at wms.py, line 85 -- but I thikn we need to do it before
then -- the reader barfs out.

But I noticed something -- the user is passing in a version number (Or a
default is being used), so the first check should be right there -- if
anon-supported version is asked for, then an error should be raised right
there.

Then, I think in the Reader code, we'll have to do the check early. Not
sure if I"ll get any time to look at this more :-(

—
Reply to this email directly or view it on GitHub
#25 (comment).

—
Reply to this email directly or view it on GitHub.

[roomthily]

So I'm going to put my user hat on for a minute and just ask this - please
do all of the NotImplemented if you do one.

Part of why I started implementing 1.3.0 was to get as many OGC versions
supported in a single place as I could. For our needs, metadata
harmonization is key, instantiation and that kind of general api
harmonization is key. We haven't offered that back (it doesn't extend to
the data access requests) but it matters when building on top of owslib.
It's just a higher cognitive load and a more error prone process to have to
interact with an api that changes behavior based on service or version or
whatever.

So please consider just taking care of the set in this.

roomthily

On Wednesday, July 29, 2015, Tom Kralidis notifications@github.com wrote:

With the 1.3 work perhaps version negotiation should go in the factory?

Sent from my iPhone

On Jul 29, 2015, at 18:06, roomthily <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Ah, there's two patterns - there's a parent WxS factory/router class that
may include version info and then there's just WxS classes as you
describe.
But certainly straightforward for both cases to verify and bail.

roomthily

On Wed, Jul 29, 2015 at 3:45 PM, Chris Barker <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');>
wrote:

I took a look at wms.py, line 85 -- but I thikn we need to do it before
then -- the reader barfs out.

But I noticed something -- the user is passing in a version number (Or
a
default is being used), so the first check should be right there -- if
anon-supported version is asked for, then an error should be raised
right
there.

Then, I think in the Reader code, we'll have to do the check early. Not
sure if I"ll get any time to look at this more :-(

—
Reply to this email directly or view it on GitHub
<#25 (comment)
.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#25 (comment).

[Jenselme]

Any progress on that issue? I am also interested in WMS 1.3.0 support.

[roomthily]

Yeah, sorry, job change.

Will need to rebase again but I think it's at tracking down a couple of
services for the tests (getmap side). There was at least one of the 1.3.0
options that I thought should be tested but wasn't able to find in the wild
(last fall). Will have to double-check exactly what those were - maybe not
a big deal if no one's really using them after, what, 5 years :(.

On Thu, Apr 7, 2016 at 3:43 AM, Julien Enselme notifications@github.com
wrote:

Any progress on that issue? I am also interested in WMS 1.3.0 support.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#25 (comment)

Soren Scott
Research Coder
The Ronin Institute for Independent Scholarship
soren.scott@ronininstitute.org

just a head's up - taking a bit of a sabbatical so if i don't
get back to you right away, no worries.

[ChrisBarker-NOAA]

Indeed.

And while I am all for complete testing, mostly-there with a few untested features would be much better than no support.

[tomkralidis]

At long last, now implemented in master via #343. Thanks @roomthily!

[ChrisBarker-NOAA]

Awesome news - -thanks all!