[Geoserver-users] WFS 1.1.0 and BBOX with KVP vs. inside Filter

Jukka_Rahkonen · July 28, 2011, 6:21pm

Hi,

Can it really be so that in WFS 1.1.0 the meaning of BBOX given without projection is different when using http GET Key Value Pair (&BBOX=...) than when using http POST and BBOX given inside a Filter? I have understood that in the latter case if BBOX is given without srsName the default is the same than the default srsName of the FeatureType. Now I have been reading from the standard that if the BBOX is given withour crsuri as a KVP then the default is WGS84. If this is the case I feel it is a bit odd but because it is WFS standard I would not be surprised.

Excerpt 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].

-Jukka Rahkonen-

Andrea_Aime4 · July 28, 2011, 7:48pm

On Thu, Jul 28, 2011 at 8:21 PM, Rahkonen Jukka
<Jukka.Rahkonen@anonymised.com> wrote:

Hi,

Can it really be so that in WFS 1.1.0 the meaning of BBOX given without projection is different when using http GET Key Value Pair (&BBOX=...) than when using http POST and BBOX given inside a Filter? I have understood that in the latter case if BBOX is given without srsName the default is the same than the default srsName of the FeatureType. Now I have been reading from the standard that if the BBOX is given withour crsuri as a KVP then the default is WGS84. If this is the case I feel it is a bit odd but because it is WFS standard I would not be surprised.

Excerpt 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].

We've have had the current behavior (using the declared srs, not
wgs84) for years without complaints,
changing it now would result in a massive backwards compatibility breakage.

I would be ok to have this insane behavior (wgs84 for everything
unless otherwise specified) only if it has its own flag and the
admin is ready to shoot himself on the foot.
I doubt very many clients would work against projected data if that
behavior was followed to the letter

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Jukka_Rahkonen · July 29, 2011, 6:17am

Hi,

Thanks. So I'll pretend I've never read the 1.1.0 standard and, bona fide, continue to suppose that BBOX behaves like it does with version 1.0.0.

-Jukka Rahkonen-

Andrea Aime wrote:

On Thu, Jul 28, 2011 at 8:21 PM, Rahkonen Jukka
<Jukka.Rahkonen@anonymised.com> wrote:
> Hi,
>
> Can it really be so that in WFS 1.1.0 the meaning of BBOX
given without projection is different when using http GET Key
Value Pair (&BBOX=...) than when using http POST and BBOX
given inside a Filter? I have understood that in the latter
case if BBOX is given without srsName the default is the same
than the default srsName of the FeatureType. Now I have been
reading from the standard that if the BBOX is given withour
crsuri as a KVP then the default is WGS84. If this is the
case I feel it is a bit odd but because it is WFS standard I
would not be surprised.
>
> Excerpt 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].

We've have had the current behavior (using the declared srs, not
wgs84) for years without complaints,
changing it now would result in a massive backwards
compatibility breakage.

I would be ok to have this insane behavior (wgs84 for everything
unless otherwise specified) only if it has its own flag and the
admin is ready to shoot himself on the foot.
I doubt very many clients would work against projected data if that
behavior was followed to the letter

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Andrea_Aime4 · July 29, 2011, 7:41am

On Fri, Jul 29, 2011 at 8:17 AM, Rahkonen Jukka
<Jukka.Rahkonen@anonymised.com> wrote:

Hi,

Thanks. So I'll pretend I've never read the 1.1.0 standard and, bona fide, continue to suppose that BBOX behaves like it does with version 1.0.0.

As usual I have strong opinions
However, if someone really wants that flag and has tight control over
the clients accessing the WFS, and those work the
way the standard was written... well, why not?
It just seems a rather narrow use case

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Jukka_Rahkonen · July 29, 2011, 8:21am

Andrea Aime wrote:

On Fri, Jul 29, 2011 at 8:17 AM, Rahkonen Jukka
<Jukka.Rahkonen@anonymised.com> wrote:
> Hi,
>
> Thanks. So I'll pretend I've never read the 1.1.0 standard
and, bona fide, continue to suppose that BBOX behaves like it
does with version 1.0.0.

As usual I have strong opinions
However, if someone really wants that flag and has tight control over
the clients accessing the WFS, and those work the
way the standard was written... well, why not?
It just seems a rather narrow use case

I can see from our server logs that there are some real world clients sending WFS 1.0.0 requests with GET and BBOX as KVP but nobody has been hitting our server by using the combination of WFS 1.1.0 + http GET + BBOX. I believe it would be a really bad idea to make such a client because obviously the BBOX coordinates should still be reversed with some srsNames when using WFS 1.1.0 and nobody could ever make that work with all the projections and against all the different WFS server marks. Thus this is more a theoretical issue and mainly makes mad people like me who are making some hand written requests to be sent through a browser. The http requests with KVP are rather a lot easier to read in tutorials than those with url-encoded filters. At least for me, just compare
&BBOX=3307900,6909392,3541041,7085366
with something like
FILTER=%3Cogc%3AFilter+xmlns%3Aogc%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22+xmlns%3Agml%3D%22http%3A%2F%2Fwww.opengis.net%2Fgml%22%3E%3Cogc%3ABBOX%3E%3Cogc%3APropertyName%3Eway%3C%2Fogc%3APropertyName%3E%3Cgml%3AEnvelope%3E%3Cgml%3AlowerCorner%3E232956.28352295642+6611434.046334767%3C%2Fgml%3AlowerCorner%3E%3Cgml%3AupperCorner%3E358186.6317651436+6766767.843673633%3C%2Fgml%3AupperCorner%3E%3C%2Fgml%3AEnvelope%3E%3C%2Fogc%3ABBOX%3E%3C%2Fogc%3AFilter%3E

-Jukka-

Andrea_Aime4 · July 29, 2011, 8:44am

On Fri, Jul 29, 2011 at 10:21 AM, Rahkonen Jukka
<Jukka.Rahkonen@anonymised.com> wrote:

Andrea Aime wrote:

On Fri, Jul 29, 2011 at 8:17 AM, Rahkonen Jukka
<Jukka.Rahkonen@anonymised.com> wrote:
> Hi,
>
> Thanks. So I'll pretend I've never read the 1.1.0 standard
and, bona fide, continue to suppose that BBOX behaves like it
does with version 1.0.0.

As usual I have strong opinions
However, if someone really wants that flag and has tight control over
the clients accessing the WFS, and those work the
way the standard was written... well, why not?
It just seems a rather narrow use case

I can see from our server logs that there are some real world clients sending WFS 1.0.0 requests with GET and BBOX as KVP but nobody has been hitting our server by using the combination of WFS 1.1.0 + http GET + BBOX. I believe it would be a really bad idea to make such a client because obviously the BBOX coordinates should still be reversed with some srsNames when using WFS 1.1.0 and nobody could ever make that work with all the projections and against all the different WFS server marks. Thus this is more a theoretical issue and mainly makes mad people like me who are making some hand written requests to be sent through a browser. The http requests with KVP are rather a lot easier to read in tutorials than those with url-encoded filters. At least for me, just compare
&BBOX=3307900,6909392,3541041,7085366
with something like
FILTER=%3Cogc%3AFilter+xmlns%3Aogc%3D%22http%3A%2F%2Fwww.opengis.net%2Fogc%22+xmlns%3Agml%3D%22http%3A%2F%2Fwww.opengis.net%2Fgml%22%3E%3Cogc%3ABBOX%3E%3Cogc%3APropertyName%3Eway%3C%2Fogc%3APropertyName%3E%3Cgml%3AEnvelope%3E%3Cgml%3AlowerCorner%3E232956.28352295642+6611434.046334767%3C%2Fgml%3AlowerCorner%3E%3Cgml%3AupperCorner%3E358186.6317651436+6766767.843673633%3C%2Fgml%3AupperCorner%3E%3C%2Fgml%3AEnvelope%3E%3C%2Fogc%3ABBOX%3E%3C%2Fogc%3AFilter%3E

He he, yep, OGC xml filters are painful.
The easy way out is, I guess, to add the fifth parameter, the crs, to
your requests, and forget
the 4 values version ever existed.

And yeah, I agree that making a protocol were the clients needs a full
fledged EPSG database
to determine the proper axis order has been a mistake on OGC part, it
basically killed away
fully atomated light clients, requiring to hand configure each
instance of them for the limited
set of EPSG codes that one needs (and which has to be foreseen in advance).
Or they could resurrect the coordinate transformation service, but
with an extra showing all
available codes and details of them such as the axis order, projection
and the like: a light
client could then consult it to get the required information.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------