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.rahko...@mmmtike.fi> 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 > > ------------------------------------------------------- > ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
