<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Jukka.<br>
I agreed with you that if the srs is epsg it should always repeort
the correct axis order, but this , as report me from Olivier, seem
to be a standard "defacto" (a standard coming from bottom).<br>
This is confirmed from this doc from Geoserver:<br>
<br>
<a class="moz-txt-link-freetext" href="http://docs.geoserver.org/latest/en/user/services/wfs/basics.html">http://docs.geoserver.org/latest/en/user/services/wfs/basics.html</a><br>
<br>
Where is reported this rule:<br>
<br>
<table class="docutils" border="1">
<thead valign="bottom"><tr class="row-odd">
<th class="head">Representation</th>
<th class="head">Assumed axis order</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even">
<td><tt class="docutils literal"><span class="pre">EPSG:xxxx</span></tt></td>
<td>longitude/latitude (x/y)</td>
</tr>
<tr class="row-odd">
<td><tt class="docutils literal"><span class="pre"><a class="moz-txt-link-freetext" href="http://www.opengis.net/gml/srs/epsg.xml#xxxx">http://www.opengis.net/gml/srs/epsg.xml#xxxx</a></span></tt></td>
<td>longitude/latitude (x/y)</td>
</tr>
<tr class="row-even">
<td><tt class="docutils literal"><span class="pre">urn:x-ogc:def:crs:EPSG:xxxx</span></tt></td>
<td>latitude/longitude (y/x)</td>
</tr>
</tbody>
</table>
<br>
So established that this is the rule, my second question is:<br>
A request with an srs espressed as a urn should have the coords in
reversed axis order ?<br>
<br>
Actually tinyows need the request coords in not-reversed axis order
however.<br>
<br>
A.<br>
<br>
<div class="moz-cite-prefix">Il 15/03/2016 22:58, Rahkonen Jukka
(MML) ha scritto:<br>
</div>
<blockquote
cite="mid:d2d2dc37fb5a499aa03caf7f94ab8fe6@C119S212VM022.msvyvi.vaha.local"
type="cite">
<pre wrap="">Hi,
With EPSG:3003 the coordinates should never ever be reversed because it is officially an Easting-Northing system as you can see from <a class="moz-txt-link-freetext" href="http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3003">http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3003</a>
AXIS["easting (X)",east,ORDER[1]],
AXIS["northing (Y)",north,ORDER[2]],
So if you will find a difference in using WMS 1.1.x vs. 1.3.0 or WFS 1.0 vs. 1.1 or SRS in short format vs. long format with EPSG:3003 that's a bug.
-Jukka Rahkonen-
Andrea Peri wrote:
Hi,
thx to Olivier. I understand that the TinyOWS has a rule inherited from OGC that when the srs is in short version (ie: EPSG:3003) the axis are not reversed.
Instead when the srs is with long form (ie:
urn:x-ogc:def:crs:EPSG:3003) the axis are always reversed.
A last question I have is about the input.
Infact this rule seem to be supported also in input request.
So when the srs is espressed in the request in long form , I guess, the cocordinates should be given in reversed order.
But instead tinyows seem to accept instead the coordinate in not reversed axis order.
I post a sample :
This is the post example:
<?xml version="1.0" encoding="UTF-8"?><wfs:GetFeature xmlns:sita=<a class="moz-txt-link-rfc2396E" href="http://www.regione.toscana.it/">"http://www.regione.toscana.it/"</a>
xmlns:ogc=<a class="moz-txt-link-rfc2396E" href="http://www.opengis.net/ogc">"http://www.opengis.net/ogc"</a>
xmlns:wfs=<a class="moz-txt-link-rfc2396E" href="http://www.opengis.net/wfs">"http://www.opengis.net/wfs"</a>
xmlns:ows=<a class="moz-txt-link-rfc2396E" href="http://www.opengis.net/ows">"http://www.opengis.net/ows"</a>
xmlns:xlink=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/1999/xlink">"http://www.w3.org/1999/xlink"</a>
xmlns:gml=<a class="moz-txt-link-rfc2396E" href="http://www.opengis.net/gml">"http://www.opengis.net/gml"</a> handle="GeoTools 11.4 WFS DataStore" maxFeatures="10" outputFormat="text/xml; subtype=gml/3.1.1"
resultType="results" service="WFS" version="1.1.0"> <wfs:Query srsName="urn:ogc:def:crs:EPSG::3003"
typeName="sita:listacomunirtpoly">
<ogc:Filter>
<ogc:Intersects>
<ogc:PropertyName>geometry</ogc:PropertyName>
<gml:Polygon srsDimension="2" srsName="urn:x-ogc:def:crs:EPSG:3003">
<gml:exterior>
<gml:LinearRing srsDimension="2">
<gml:posList>1625601.65 4842775.06 1696384.15 4842775.06
1696384.15 4871929.04 1625601.65 4871929.04 1625601.65 4842775.06</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</ogc:Intersects>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>
That is callable using this curl call:
curl -H "Content-Type: text/xml" -0 -X POST -d @req2.xml <a class="moz-txt-link-rfc2396E" href="http://www502.regione.toscana.it/wfsvector/com.rt.wfs.RTmap/wfs">"http://www502.regione.toscana.it/wfsvector/com.rt.wfs.RTmap/wfs"</a>
As noticeable.
The request has the coords in not reversed order, the srs is in the long form, and the response is with coords in reversed order.
I guess the tinyows should accept the coords in reversed order to be totally coherent with the rule that the long srs form will reverse axis.
Any thought ?
2016-03-14 17:00 GMT+01:00 Andrea Peri <a class="moz-txt-link-rfc2396E" href="mailto:aperi2007@gmail.com"><aperi2007@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I experience this issue.
When asking to the tinyows a getfeature with an intersects with a
polygon and returning in epsg:3003 it return the result with the right
axis order if the request is done with GET method.
Instead it return exchange coords if the request is in POST method.
Is know this issue ?
Thx.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
</pre>
</blockquote>
<pre wrap="">
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
mapserver-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapserver-users@lists.osgeo.org">mapserver-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapserver-users">http://lists.osgeo.org/mailman/listinfo/mapserver-users</a>
</pre>
</blockquote>
<br>
</body>
</html>