<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 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@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:"\@SimSun";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
 /* List Definitions */
 @list l0
        {mso-list-id:1743134032;
        mso-list-type:hybrid;
        mso-list-template-ids:1169074916 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:.25in;
        text-indent:-.25in;}
@list l1
        {mso-list-id:1829786298;
        mso-list-type:hybrid;
        mso-list-template-ids:-2085965782 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:.25in;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</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>Hi,<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>As we know, the WMS defined the axis order reverse in the
latest version spec (1.3.0) for some EPSG codes. Accordingly, we should send
different BBox value to servers if it exposes the same data between 1.3.0 and
previous versions.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>With the Layer CS and Map CS definition in 1.3.0, the layer
CRS that the BBOX applies to on query is the underlying data that we&#8217;re
querying. But, once the data is selected, the WMS server projects it into the
Map using the Projection of geographic CRSs into Map CS process. What
we&#8217;re querying and the data that we&#8217;re seeing coming back are in
different coordinate systems.<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>But currently, WMS provider doesn&#8217;t handle it at all. It
make no difference between 1.3.0 and previous version. So for some layer in WMS
1.3.0 server, the data we get through WMS provider isn&#8217;t correct (send wrong
BBox to servers and the data got is not what client wanted).<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal><b>[Solutions]<o:p></o:p></b></p>

<p class=MsoNormal><b>Expose the WMS version information and leave it to FDO client<o:p></o:p></b></p>

<p class=MsoListParagraph style='margin-left:.25in;text-indent:-.25in;
mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>1.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Have
a custom command in WMS provider to return the actual version being connected. <o:p></o:p></p>

<p class=MsoNormal>The problem is that BBox in WMS provider is used in two
places:<o:p></o:p></p>

<p class=MsoNormal>&nbsp;- Construct the BBox parameter string to send to
server.<o:p></o:p></p>

<p class=MsoNormal>&nbsp;- Construct the Bounds information (FdoWmsRect)which
used to read the data later.<o:p></o:p></p>

<p class=MsoNormal>If we leave it to FDO client, then we end up with very
custom client code that knows that it&#8217;s using WMS, knows to get the WMS
version, and then has to use some CS library to look up the epsg code if we get
one (at last, pass the reversed BBox value to FDO). What&#8217;s more, after
client got the FeatureReader returned by WMS provider, it still needs to have
some custom codes which knows the Bounds in it is not right and reverse it
while reading the raster data in some case.<o:p></o:p></p>

<p class=MsoNormal>And also iIt makes the WMS provider less generic and harder
to code against and maintain in a uniform, consistent manner with other
providers.<o:p></o:p></p>

<p class=MsoNormal><b><o:p>&nbsp;</o:p></b></p>

<p class=MsoNormal><b>Handle it in WMS provider so that clients don&#8217;t
have to worry about any of this<o:p></o:p></b></p>

<p class=MsoNormal>To handle it in WMS provider, we need to know which EPSG
code need to be reversed while sending BBox parameter. Ideally, it would be
good if the provider could get some sort of indication from the server. But I
don&#8217;t expect the server will expose this information related in its
capability file. Because it&#8217;s part of the EPSG&#8217;s definition and the
name of the code name is already enough from the server&#8217;s view.<o:p></o:p></p>

<p class=MsoNormal>There are two ways to get this information: <o:p></o:p></p>

<p class=MsoListParagraph style='margin-left:.25in;text-indent:-.25in;
mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>2.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Have
a simple configuration file in WMS provider which indicates the axis order of
specific EPSG code. The disadvantage is that we&#8217;d have to maintain and
keep correct.<o:p></o:p></p>

<p class=MsoListParagraph style='margin-left:.25in;text-indent:-.25in;
mso-list:l0 level1 lfo2'><![if !supportLists]><span style='mso-list:Ignore'>3.<span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span><![endif]>Get
ESPG code definition from Web, we can send a request to <a
href="http://www.epsg-registry.org/">http://www.epsg-registry.org/</a> with a
code name and it will return the definition with GML format, then we parse it
and get its axes order information. The disadvantage is that we can&#8217;t
promise this server&#8217;s stability and also can&#8217;t make sure users have
internet access (if users are in the LAN). <o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Have a discussion with Orest and Greg, we are leaning
towards the configuration file option. &nbsp;Is there any new ideas or comments
on this issue and the solutions?<o:p></o:p></p>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Thanks,<o:p></o:p></p>

<p class=MsoNormal>Leo Dai<o:p></o:p></p>

</div>

</body>

</html>