[owslib-devel] wfs 1.1.0 client implementation

[Jachym Cepicky]

Dear all,

as you might already know, WFS 1.1.0 client-side implemntation in
various software packages is my hobby for these days. Now I approached
to owslib and would have some questions/proposals to getfeature method:

1) accept bounding box parameter *always* in
[mineast,minnorth,maxeast,maxnorth] coordinates order

2) always append information about SRS to the BBOX, default is the
default one from capabilities

3) always append srsname to the request, default is the default from
capabilities

4) formulate the request with propper axis order,

examples:

epsg:4326 -> &BBOX=minx,miny,maxx,maxy,epsg:4326&SRSNAME=epsg:4326
urn:ogc:def:crs:EPSG::4326 ->
&BBOX=miny,minx,maxy,maxx,urn:ogc:def:crs:EPSG::4326&SRSNAME=urn:ogc:def:crs:EPSG::4326


Current behaviour:

getfeature() method accepts bbox=[], srsname=String and passes it to the
URL without any check. at least srsname should be checked, if it is
supported (based on capabilites document) or not. User have to be aware
of the form, he hands over SRSNAME parameter ("epsg:4326" versus
"urn:ogc:def:crs:...") and give the "propper" coords order by hand.

Proposed behaviour:
user gives *always* bbox coords in minx,miny,maxx,maxy form
no matter which SRS encoding he uses, owslib checks against capabilities
which form is supported, uses the propper one and if needed, swaps the
coordiantes in the request.

what do you think?

-- 
Jachym Cepicky
Help Service - Remote Sensing s.r.o.
jachym.cepicky at gmail.com | jachym at hsrs.cz
http://les-ejk.cz | http://bnhelp.cz

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/owslib-devel/attachments/20120321/481cd595/attachment.pgp>