[owslib-devel] wfs 1.1.0 client implementation

[Jachym Cepicky]

hi,
thanks for your reaction (do not get much of them to these topic)

On 22.3.2012 11:02, Dominic Lowe wrote:
> 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'.

correct

> 
> It makes sense I think - I suppose my only concern is that OWSLib now 
> has to understand certain CRSs.

OWSLib has IMHO very good implementation of various formats and forms of
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)

Agreed, but we would have to make deeper analysis of this issue. More
user parameters to getfeature() method would be good solution.

I'll try to prepare some patch and test it against some servers I have
at hand (mapserver, geoserver, something weird, integraph, ..) and will see

j

> 
> 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,
&#1
3;
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
> 
> 

-- 
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/20120322/162b36b7/attachment.pgp>