[owslib-devel] wfs 1.1.0 client implementation

[Dominic Lowe]

Hi Tom, Jachym,

My interpretation was that Jachym's proposal is to ALWAYS use minx, 
miny, maxx, maxy in the OWSLib api regardless of the order in any CRS 
(specified or not specified) - is that correct? And owslib sorts out the 
correct ordering 'under the hood'.

It makes sense I think - I suppose my only concern is that OWSLib now 
has to understand certain CRSs.
What happens if a user wants to make a request for a CRS that is 
understood by the WFS, but not by OWSLib?  - this should still be 
possible so do we need to provide a mechanism for letting the user 
determine axis order in the case where the srs is not known to OWSLib, 
but is understood by the user and WFS?

(e.g. a 'switchXY' boolean argument)

Cheers
Dom



It makes sense and saves
On 21/03/12 20:52, tomkralidis at hotmail.com wrote:
>
> Jachym: thanks for the info.  This seems fair enough.  So by default x/y is expected unless srsname is passed, at which point validated against supported srsname's, and then axis order is set by the Crs object.
>
> ..Tom
>
>
> ----------------------------------------
> Date: Wed, 21 Mar 2012 00:03:24+0100
From: jachym.cepicky@gmail.com
To: owslib-devel@lists.sourceforge.net
Subject:[owslib-devel] wfs 1.1.0 client implementation


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@gmail.com| jachym@hsrs.cz
http://les-ejk.cz| http://bnhelp.cz


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
owslib-devel mailing list
owslib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owslib-devel
 		 	   		
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> owslib-devel mailing list
> owslib-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owslib-devel


-- 
Scanned by iCritical.