[TinyOWS-users] Correct way to give BBOX as KVP with WFS 1.1.0

[Rahkonen Jukka]

Hi,

This one gives me features:

[1] http://hip.latuviitta.org/cgi-bin/tinyows?service=wfs&version=1.1.0&request=GetFeature&typename=lv:municipalities&BBOX=246700,6780800,436400,6924000

This one doesn't
[2] http://hip.latuviitta.org/cgi-bin/tinyows?service=wfs&version=1.1.0&request=GetFeature&typename=lv:municipalities&BBOX=246700,6780800,436400,6924000,EPSG:3067

The result is an error
<ows:ExceptionText>Bad parameters for Bbox, must be Xmin,Ymin,Xmax,Ymax</ows:ExceptionText></ows:Exception>

However, I am reading from the OGC WFS 1.1.0 standard (OGC 04-094)

14.3.3 Bounding box
The bounding box parameter, BBOX, is included in this specification for convenience as a shorthand representation of the very common a bounding box filter which would be expressed in much longer form using XML and the filter encoding described in [3]. A BBOX applies to all feature types listed in the request.
The KVP encoding for a bounding box is defined in subclause 10.2.3 of normative reference [15]. The general form of the parameter is:
BBOX=lcc1,lcc2,...,lccN,ucc1,ucc2,...uccN[,crsuri]
where lcc means Lower Corner Coordinate, ucc means Upper Corner Coordinate and crsuri means the URI reference to the coordinate system being used. This encoding allows N coordinates for each corner listed in the order of the optional crsuri. If the crsuri is not specified then the 2-D coordinates shall be specified using decimal degrees and WGS84 as described in [15].

Should I understand this so that my request [2] should give me results and that [1], which is a correct WFS 1.0.0 BBOX, is not a correct  WFS 1.1.0 BBOX because without crsuri BBOX should be interpreted to mean a WGS84 box and then obviously extents 246700,6780800,436400,6924000 are rather wide?

-Jukka Rahkonen-