[owslib-devel] wfs 11 and srsname encoding

[Jachym Cepicky]

Hi,

your understandings of the functionality is right.

having csrs specified in the bbox parameter of the request is optional
(page 95 of wfs 1.1.0 in OGC 04-094). E.g. mapserver is looking after
that (and dealing with it). Note: in general, it is not "the fifth"
argument but "the last one".. but owslib still assumes, we are in the
2Dspace (we should change this in the future, but has anybody seen any
3D-WFS server around?).

and yes, it *should* be possible to specify the bbox in one SRS and
obtain results in another (according to srsname)

wfs 1.1. cleary says for the bbox:

crsuri means the URI reference to the coordinate system being used.
If the crsuri is not specified then the 2-D coordinates shall be
specified using decimal degrees and WGS84 as described in [15].

srsname:

This parameter is used to specify a WFS-
supported SRS that should be used for
returned feature geometries. The value
may be the DefaultSRS or any of the
OtherSRS values that a WFS declares it
supports in the capabilities document. The
SRS may be indicated using EPSG codes
or the URL form defined in [2]. If the
parameter is not specified then the value of
the DefaultSRS for the feature type being
queried shall be used.

this is how it *should* work. But implementation can be something else.

J


On 30.3.2012 12:17, Dominic Lowe wrote:
> Hi Jachym,
> 
> I haven't tested the patch, but just to check my understanding:
> 
> I'm interpreting from the examples that the purpose of the fifth 
> parameter is to specify the CRS used for the bounding box? Is that correct?
> If so does this mean you can make a request in one CRS (using the fifth 
> parameter) and request the response is delivered in another (using the 
> 'srsName')?
> 
> (Is this supported by WFS 1.1.0? I have seen the concept of request and 
> response CRS in some OGC specs - can't remember which offhand now).
> 
> Cheers,
> Dom
> 
> 
> On 29/03/12 01:05, jachym.cepicky at gmail.com wrote:
>> Hi,
>>
>> according to my last email, I'm attaching patch to this topic.
>>
>> The patch fill do format propper getfeature request for WFS 1.1.0 server:
>>
>> 1) It will always add 5th parameter to bbox (if not given) in the format
>> supported by the server
>> 2) Always format srsname parameter in the format supported by the server
>> 3) Assume, bbox coordinate are given in the east,north axis order and
>> re-order them in a case, this is needed.
>> 4) Check, if the srsname given as parameter input is supported by the
>> server and select the proper form for it (code or urn)
>>
>> examples:
>>
>>>>> from owslib.wfs import WebFeatureService as WFS
>>>>> w = WFS("http://bnhelp.cz/ows/crwfs",version="1.1.0")
>> Example 1:
>>>>> f = w.getfeature("okresy",srsname="epsg:4326")
>> will produce URL "....typename=okresy&srsname=urn:ogc:def:crs::4326"
>>
>> because of "epsg:4326" is not supported by the server, but the URN form is
>>
>> Example 2:
>>>>> f = w.getfeature("okresy",srsname="epsg:4326",bbox=[14,49,17,51])
>> will produce
>> "....typename=okresy&srsname=urn:ogc:def:crs::4326&bbox=49,14,51,17,urn:ogc:def:crs::4326"
>>
>> It will take the default SRS (in propper form) for given feature type
>> and re-order bbox coordinates according to it
>>
>> Example 3:
>> f =
>> w.getfeature("okresy",srsname="epsg:4326",bbox=[14,49,17,51,'epsg:4326'])
>>
>> will produce the same as above
>>
>> Any comments?
>>
>> Jachym
>>
> 

-- 
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/20120330/ed565b40/attachment.pgp>