<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:BOCMML+TimesNewRoman;
        panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoListNumber, li.MsoListNumber, div.MsoListNumber
        {mso-style-name:"List Number\,List Number Char";
        mso-style-priority:99;
        margin:0in;
        margin-bottom:.0001pt;
        text-autospace:none;
        font-size:12.0pt;
        font-family:"BOCMML+TimesNewRoman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Unlike the unambiguous statement in WFS 1.1, WFS 2.0 doesn’t specify a default CRS for the
<o:p></o:p></p>
<p class="MsoNormal">BBOX param. So it would seem that interpreting a BBOX parameter without a CRS reference appended
<o:p></o:p></p>
<p class="MsoNormal">is problematic in WFS 2.0*. It also refers to WSC, cl. 10.2.3 (the text is unchanged from WSC 1.0), which states:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><blockquote cite=“http://portal.opengeospatial.org/files/?artifact_id=20040”><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:"BOCMML+TimesNewRoman","serif";color:black">If no CRS URI value is included, the applicable CRS must be either:
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:"BOCMML+TimesNewRoman","serif";color:black">a) Specified outside the bounding box, but inside a data structure that includes this bounding box, as specified for a specific OWS use of this bounding
 box type <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.5pt;font-family:"BOCMML+TimesNewRoman","serif";color:black">b) Fixed and specified in the Implementation Specification for a specific OWS use of the bounding box type.
<o:p></o:p></span></p>
<p class="MsoNormal"></blockquote><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">WFS 1.1 went with option (b) as noted previously. Since there is no KVP parameter to satisfy (a), and (b) is overlooked, it
<o:p></o:p></p>
<p class="MsoNormal">would seem that in WFS2 a BBOX param lacking a terminal CRS reference is invalid.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">* The WFS2 test suite currently doesn’t use the BBOX param, but uses FILTER instead so the issue has been
<o:p></o:p></p>
<p class="MsoNormal">avoided so far.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">--<o:p></o:p></p>
<p class="MsoNormal">Richard<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> CITE-Forum [mailto:cite-forum-bounces+rmartell=galdosinc.com@lists.opengeospatial.org]
<b>On Behalf Of </b>Andrea Aime<br>
<b>Sent:</b> Monday, 09 December, 2013 00:59<br>
<b>To:</b> Sebastian Goerke<br>
<b>Cc:</b> cite-forum@lists.opengeospatial.org<br>
<b>Subject:</b> Re: [CITE-Forum] Axis order change breaks standard compatibility in WFS 1.1?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On Mon, Dec 9, 2013 at 9:10 AM, Sebastian Goerke <<a href="mailto:goerke@lat-lon.de" target="_blank">goerke@lat-lon.de</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi Andrea,<br>
<br>
this issue is currently discussed on the WFS SWG. The problem here is:<br>
BBOX != BBOX Filter (following FE 1.1.0). The behaviour for the<br>
defaultSRS is also described within 9.2 of the WFS spec (and only<br>
meant for the xml representation)(What is described here is covered by<br>
the value of the KVP parameter FILTER).<br>
Section 14.3.3 of the spec describes the following (Describung the KVP<br>
parameter BBOX):<br>
<br>
If the crsuri is not specified then the 2-D coordinates shall be<br>
specified using decimal degrees and WGS84 as described in [15].<br>
<br>
15 is OWS Common. There it is mentioned, that the axis order for WGS<br>
84 is long/lat.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I see, found it. That's quite troublesome, as the WFS 1.1 spec and tests<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">have been around for so much time, and the tests forced implementors to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the current implementation too.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Imho the chance to change this test without causing major pain<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">in the "real world" is long gone.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<p class="MsoNormal"><br>
I totally agree your arguments regarding interoperability and that the<br>
testsuite worked the way it was for years (meaning that ALL certified<br>
products handle it the way we both expect it to work.).<br>
<br>
Both reference implementations are failing the test now. But I<br>
understand the argument from the standards view, that WGS 84 with<br>
long/lat order shall be used.<br>
<br>
We need a strategy here. The plan is, to discuss the general issue at<br>
today's CITE dev meeting:<br>
<br>
<a href="https://github.com/opengeospatial/teamengine/issues/16" target="_blank">https://github.com/opengeospatial/teamengine/issues/16</a><o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My suggestion... if a change really need to be made, fix this for later standards? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">For example, how about WFS 2.0? I'm sure GeoServer behaves in the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">same way as WFS 1.1 when hit with a BBOX in WFS 2.0<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">At the very least, the CITE tests for WFS 2.0 are fresh out no?<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That said, have an inconsistent behavior between the BBOX in KVP and the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">BBOX in XML is going to cause much paint down the road, at least the way<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">they are implemented now, they are consistent.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If I could have bee paid for the many times I had to explain about the various<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">axis order issues introduced by WFS 1.1 and WMS 1.3 (with all the people I<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">met so far expecting a easting/northing orientation, and claiming the software<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">was buggy because we use lat/lon instead) I could have bought a nice car by now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This is going to make things worse, not only the axis order is inconsistent with<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the rest of the standard, but the data is being queried in a SRS that is not its native one...<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Andrea<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">-- <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">==<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Our support, Your Success! Visit <a href="http://opensdi.geo-solutions.it" target="_blank">
http://opensdi.geo-solutions.it</a> for more information.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">==<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ing. Andrea Aime <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">@geowolf<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Technical Lead<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">GeoSolutions S.A.S.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Via Poggio alle Viti 1187<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">55054  Massarosa (LU)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Italy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">phone: +39 0584 962313<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">fax: +39 0584 1660272<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">mob: +39  339 8844549<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://www.geo-solutions.it" target="_blank">http://www.geo-solutions.it</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://twitter.com/geosolutions_it" target="_blank">http://twitter.com/geosolutions_it</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-------------------------------------------------------<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>