hi all,
how/where in geoserver configure *FORCE_AXIS_ORDER_HONORING to have lat,lon coordinates system by default ??
thanks.
*
--
Sébastien Geindre
DPREVI/AERO/DEV
sebastien.geindre __at__ meteo.fr
Sébastien Geindre ha scritto:
hi all,
how/where in geoserver configure *FORCE_AXIS_ORDER_HONORING to have lat,lon coordinates system by default ??
If you have to start GeoServer with the following command line argument
provided to the JVM:
-Dorg.geotools.referencing.forceXY=false
Beware, this requires you to have the data sources in lat/lon order too,
and will break all existing WFS 1.0 clients (that do expect data in lon/lat order).
Altenatively, you don't provide the above parameter, use "normal" lon/lat data sources (postgis, shapefiles) and use only WFS 1.1
for your data retrivial (for this to work fully, use a nightly from http://traffic.openplans.org/geoserver/trunk/).
Hope this helps
Cheers
Andrea
I detail my process, maybe something i dont get...
All my object deals about weather, community (most of it) describes them in lat,lon.
so, i 'commit' feature via wfs request : for example, an object with the following geometry : polygon in europe
<gml:Polygon srsName="urn:ogc:def:crs:EPSG:4326">
<gml:exterior>
<gml:LinearRing>
<gml:posList> 47.4930 0.323518 50.5014 0.139498 50.5014 4.92050 47.4930 4.73648 47.4930 0.323518 </gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
This polygon is in lat, lon.
I do not know how it is in postgis...
When i request them :
- they are in same order, great !
- Open layer draw them with lon,lat convention (around ethiopia !!)
- googleearth draw (via kml) with lat,lon (in europe, the right place!!)
Several question around this case :
will geo-operation be ok? intersection ? it seems to be...
so should i use the *FORCE_AXIS_ORDER_HONORING ?
does the reference to the srsName force geoserver to translate from lat,long to long,lat (WKT reader for postgis) ?
the real question is : when you specified espg 4326 projection , do you specify lat,lon or lon,lat coordinate system ?
thanks for your help.
Sébastien.
Andrea Aime a écrit :
Sébastien Geindre ha scritto:
hi all,
how/where in geoserver configure *FORCE_AXIS_ORDER_HONORING to have lat,lon coordinates system by default ??
If you have to start GeoServer with the following command line argument
provided to the JVM:
-Dorg.geotools.referencing.forceXY=false
Beware, this requires you to have the data sources in lat/lon order too,
and will break all existing WFS 1.0 clients (that do expect data in lon/lat order).Altenatively, you don't provide the above parameter, use "normal" lon/lat data sources (postgis, shapefiles) and use only WFS 1.1
for your data retrivial (for this to work fully, use a nightly from http://traffic.openplans.org/geoserver/trunk/).Hope this helps
Cheers
Andrea
--
Sébastien Geindre
DPREVI/AERO/DEV
sebastien.geindre __at__ meteo.fr
Sébastien Geindre ha scritto:
I detail my process, maybe something i dont get...
All my object deals about weather, community (most of it) describes them in lat,lon.
so, i 'commit' feature via wfs request : for example, an object with the following geometry : polygon in europe
<gml:Polygon srsName="urn:ogc:def:crs:EPSG:4326">
<gml:exterior>
<gml:LinearRing>
<gml:posList> 47.4930 0.323518 50.5014 0.139498 50.5014 4.92050 47.4930 4.73648 47.4930 0.323518 </gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>This polygon is in lat, lon.
I do not know how it is in postgis...
If you request stuff in urn:ogc:def:crs:EPSG:4326 you will get it
in lat/lon, all right
When i request them :
- they are in same order, great !
- Open layer draw them with lon,lat convention (around ethiopia !!)
OpenLayers uses the same convention as all other clients
- googleearth draw (via kml) with lat,lon (in europe, the right place!!)
No no, Google Earth pretends data in lon/lat as well. But it's specified
in the protocol clearly, so whatever you do you get them in lon/lat order as far as I know. Are you sure you're getting them in lat/lon in the KML?
See also the KML documentation, for example here:
http://code.google.com/apis/kml/documentation/kml_tags_21.html#point
It says:
<coordinates>...</coordinates> <!-- lon,lat[,alt] -->
Several question around this case :
will geo-operation be ok? intersection ? it seems to be...
so should i use the *FORCE_AXIS_ORDER_HONORING ?
No
does the reference to the srsName force geoserver to translate from lat,long to long,lat (WKT reader for postgis) ?
Yes, but that will happen only in the upper layers of the WFS stack,
not in the datastores.
the real question is : when you specified espg 4326 projection , do you specify lat,lon or lon,lat coordinate system ?
Always lon/lat, there is no storage mechanism using lat/lon afaik, only
the guys at OGC pretend lon/lat usage, and we give it only for
urn:ogc:def:crs:EPSG:xxxx format, and only for WFS 1.1, in order to
be compliant with the spec (this does not break us too much since
there are no WFS 1.1 clients around, and the new that will be developed
will have to deal with this axis order inversion thing).
If you grab the latest nightly and don't configure it in any special
way you'll have to:
* have your data stored in lon/lat order (we don't support the opposite
since nothing uses lat/lon order by default)
* if you use WFS 1.0 or WFS 1.1 but requesting data with EPSG:XXXX srs
you'll get back lon/lat
* if you use WFS 1.1 and use urn:ogc:def:crs:EPSG:xxxx form then you'll
get back lat/lon order (but then you're on your own, nothing can read
data with that axis order nowadays)
* KML output should be always generated in lon/lat order anyways since
that's what the KML spec says
* with OL you should use WFS 1.0 or, if you need WFS 1.1 capaibilities
for some reason, do specify srs in EPSG:XXXX format and ask for GML2
output format.
Does this make sense?
Cheers
Andrea
thanks Andrea !
- googleearth draw (via kml) with lat,lon (in europe, the right place!!)
No no, Google Earth pretends data in lon/lat as well. But it's specified
in the protocol clearly, so whatever you do you get them in lon/lat order as far as I know. Are you sure you're getting them in lat/lon in the KML?See also the KML documentation, for example here:
http://code.google.com/apis/kml/documentation/kml_tags_21.html#point
It says:
<coordinates>...</coordinates> <!-- lon,lat[,alt] -->
you are right !!
coordinates in kml are in lon, lat
my polygon is drawn in europe, everything normal.
does the reference to the srsName force geoserver to translate from lat,long to long,lat (WKT reader for postgis) ?
Yes, but that will happen only in the upper layers of the WFS stack,
not in the datastores.
ok it means that in postgis it is store in lon,lat...
and geoserver, anwser to wfs request, reformat from lon,lat to lat,lon, that's it ?
the real question is : when you specified espg 4326 projection , do you specify lat,lon or lon,lat coordinate system ?
Always lon/lat, there is no storage mechanism using lat/lon afaik, only
the guys at OGC pretend lon/lat usage, and we give it only for
urn:ogc:def:crs:EPSG:xxxx format, and only for WFS 1.1, in order to
be compliant with the spec (this does not break us too much since
there are no WFS 1.1 clients around, and the new that will be developed
will have to deal with this axis order inversion thing).If you grab the latest nightly and don't configure it in any special
way you'll have to:
* have your data stored in lon/lat order (we don't support the opposite
since nothing uses lat/lon order by default)
* if you use WFS 1.0 or WFS 1.1 but requesting data with EPSG:XXXX srs
you'll get back lon/lat
* if you use WFS 1.1 and use urn:ogc:def:crs:EPSG:xxxx form then you'll
get back lat/lon order (but then you're on your own, nothing can read
data with that axis order nowadays)
* KML output should be always generated in lon/lat order anyways since
that's what the KML spec says
* with OL you should use WFS 1.0 or, if you need WFS 1.1 capaibilities
for some reason, do specify srs in EPSG:XXXX format and ask for GML2
output format.Does this make sense?
yes, when i request wfs without specify any srs, i obtain the response in lat,lon.is it because of WFS 1.1 ???
<wfs:GetFeature xsi:schemaLocation="*http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd*" version="*1.1.0*" service="*WFS*">
but the response is int lat,lon
<wims:geometry>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
46.7893 2.51153 46.9345 2.39409 47.0812 2.40141 47.1788 2.32256 47.3265 2.32977 47.4259 2.41886 47.4752 2.37923 47.4741 2.21062 47.5234 2.17075 47.5232 2.12856 47.5726 2.08857 47.772 2.09746 47.8222 2.14216 47.8225 2.18461 47.8729 2.22947 47.8745 2.48456 47.8247 2.52437 47.6749 2.51631 47.6253 2.55594 47.6755 2.601 47.6764 2.72806 47.6269 2.76749 47.5772 2.76456 47.5278 2.80388 47.4782 2.80094 47.429 2.84015 47.4293 2.88229 47.3312 2.96041 47.3315 3.00248 47.3813 3.04772 47.4803 3.0541 47.5803 3.14513 47.5818 3.31435 47.632 3.36022 47.9824 3.38551 48.0824 3.30733 48.082 3.26456 48.1823 3.186 48.1815 3.1003 48.2821 3.02125 48.2818 2.97832 48.3322 2.93864 48.4851 2.94846 48.5881 3.04151 48.5892 3.17119 48.5384 3.21082 48.5392 3.2972 48.4379 3.37604 48.4387 3.46226 48.4902 3.50929 48.492 3.68198 48.4414 3.72101 48.3904 3.71687 48.3399 3.75579 47.9355 3.72306 47.8857 3.76167 47.7355 3.74959 47.5847 3.61063 47.583 3.44131 47.5329 3.3954 47.4837 3.43407 47.2859 3.41977 47.1867 3.32877 47.1848 3.119 47.0859 3.02888 47.0856 2.98703 47.0363 2.94217 47.0356 2.85857 47.0842 2.81966 47.0839 2.77782 47.0346 2.73319 46.8881 2.72487 46.7902 2.63624 46.7893 2.51153
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
Cheers
Andrea
--
Sébastien Geindre
DPREVI/AERO/DEV
sebastien.geindre __at__ meteo.fr
Sébastien Geindre ha scritto:
thanks Andrea !
- googleearth draw (via kml) with lat,lon (in europe, the right place!!)
No no, Google Earth pretends data in lon/lat as well. But it's specified
in the protocol clearly, so whatever you do you get them in lon/lat order as far as I know. Are you sure you're getting them in lat/lon in the KML?See also the KML documentation, for example here:
http://code.google.com/apis/kml/documentation/kml_tags_21.html#point
It says:
<coordinates>...</coordinates> <!-- lon,lat[,alt] -->you are right !!
coordinates in kml are in lon, lat
my polygon is drawn in europe, everything normal.does the reference to the srsName force geoserver to translate from lat,long to long,lat (WKT reader for postgis) ?
Yes, but that will happen only in the upper layers of the WFS stack,
not in the datastores.ok it means that in postgis it is store in lon,lat...
and geoserver, anwser to wfs request, reformat from lon,lat to lat,lon, that's it ?
Exactly, you got it. It's a special case of reprojection.
the real question is : when you specified espg 4326 projection , do you specify lat,lon or lon,lat coordinate system ?
Always lon/lat, there is no storage mechanism using lat/lon afaik, only
the guys at OGC pretend lon/lat usage, and we give it only for
urn:ogc:def:crs:EPSG:xxxx format, and only for WFS 1.1, in order to
be compliant with the spec (this does not break us too much since
there are no WFS 1.1 clients around, and the new that will be developed
will have to deal with this axis order inversion thing).If you grab the latest nightly and don't configure it in any special
way you'll have to:
* have your data stored in lon/lat order (we don't support the opposite
since nothing uses lat/lon order by default)
* if you use WFS 1.0 or WFS 1.1 but requesting data with EPSG:XXXX srs
you'll get back lon/lat
* if you use WFS 1.1 and use urn:ogc:def:crs:EPSG:xxxx form then you'll
get back lat/lon order (but then you're on your own, nothing can read
data with that axis order nowadays)
* KML output should be always generated in lon/lat order anyways since
that's what the KML spec says
* with OL you should use WFS 1.0 or, if you need WFS 1.1 capaibilities
for some reason, do specify srs in EPSG:XXXX format and ask for GML2
output format.Does this make sense?
yes, when i request wfs without specify any srs, i obtain the response in lat,lon.is it because of WFS 1.1 ???
Exatly. The WFS 1.1 standard say that if not srs is requested, the declared one should be used. And the declared one is in the urn:ogc:def:crs:EPSG:xxxx (otherwise we would not pass the wfs 1.1
cite tests), so it's lat/lon.
The OGC requirements will screw up every known client, but what can I
do? I already complained and they told me that I should have to look
outside of the GIS field where everybody else is using lat/lon.
Oh well...
Cheers
Adrea
so i can see that if i request data using a certain SRS i can control the
order of the lat/longs coming back, but what about when i make a getfeature
request with a non-geometry filter ? is there a way to stick to long/lat for
those ?
e.g.
<?xml version="1.0"?>
<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:gml="http://www.opengis.net/gml" version="1.1.0" outputFormat="GML2">
<wfs:Query typeName="ntlis:ROAD_CENTRELINES">
<ogc:Filter>
<ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\\">
<ogc:PropertyName>ROAD_NAME</ogc:PropertyName>
<ogc:Literal>GREVILLEA</ogc:Literal>
</ogc:PropertyIsLike>
<ogc:Intersects>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>
will always come lat/long now and this breaks everything.
-ivan
aaime wrote:
Sébastien Geindre ha scritto:
thanks Andrea !
- googleearth draw (via kml) with lat,lon (in europe, the right
place!!)No no, Google Earth pretends data in lon/lat as well. But it's specified
in the protocol clearly, so whatever you do you get them in lon/lat
order as far as I know. Are you sure you're getting them in lat/lon in
the KML?See also the KML documentation, for example here:
http://code.google.com/apis/kml/documentation/kml_tags_21.html#point
It says:
<coordinates>...</coordinates> <!-- lon,lat[,alt] -->you are right !!
coordinates in kml are in lon, lat
my polygon is drawn in europe, everything normal.does the reference to the srsName force geoserver to translate from
lat,long to long,lat (WKT reader for postgis) ?Yes, but that will happen only in the upper layers of the WFS stack,
not in the datastores.ok it means that in postgis it is store in lon,lat...
and geoserver, anwser to wfs request, reformat from lon,lat to lat,lon,
that's it ?Exactly, you got it. It's a special case of reprojection.
the real question is : when you specified espg 4326 projection , do
you specify lat,lon or lon,lat coordinate system ?Always lon/lat, there is no storage mechanism using lat/lon afaik, only
the guys at OGC pretend lon/lat usage, and we give it only for
urn:ogc:def:crs:EPSG:xxxx format, and only for WFS 1.1, in order to
be compliant with the spec (this does not break us too much since
there are no WFS 1.1 clients around, and the new that will be developed
will have to deal with this axis order inversion thing).If you grab the latest nightly and don't configure it in any special
way you'll have to:
* have your data stored in lon/lat order (we don't support the opposite
since nothing uses lat/lon order by default)
* if you use WFS 1.0 or WFS 1.1 but requesting data with EPSG:XXXX srs
you'll get back lon/lat
* if you use WFS 1.1 and use urn:ogc:def:crs:EPSG:xxxx form then you'll
get back lat/lon order (but then you're on your own, nothing can read
data with that axis order nowadays)
* KML output should be always generated in lon/lat order anyways since
that's what the KML spec says
* with OL you should use WFS 1.0 or, if you need WFS 1.1 capaibilities
for some reason, do specify srs in EPSG:XXXX format and ask for GML2
output format.Does this make sense?
yes, when i request wfs without specify any srs, i obtain the response
in lat,lon.is it because of WFS 1.1 ???Exatly. The WFS 1.1 standard say that if not srs is requested, the
declared one should be used. And the declared one is in the
urn:ogc:def:crs:EPSG:xxxx (otherwise we would not pass the wfs 1.1
cite tests), so it's lat/lon.The OGC requirements will screw up every known client, but what can I
do? I already complained and they told me that I should have to look
outside of the GIS field where everybody else is using lat/lon.
Oh well...Cheers
Adrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/beta3-to-beta4-%3A-FORCE_AXIS_ORDER_HONORING-tp13708899p15079152.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
and yes sorry that request is broken but you get the idea.
ivanprice wrote:
so i can see that if i request data using a certain SRS i can control the
order of the lat/longs coming back, but what about when i make a
getfeature request with a non-geometry filter ? is there a way to stick to
long/lat for those ?e.g.
<?xml version="1.0"?>
<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:gml="http://www.opengis.net/gml" version="1.1.0"
outputFormat="GML2">
<wfs:Query typeName="ntlis:ROAD_CENTRELINES">
<ogc:Filter>
<ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\\">
<ogc:PropertyName>ROAD_NAME</ogc:PropertyName>
<ogc:Literal>GREVILLEA</ogc:Literal>
</ogc:PropertyIsLike>
<ogc:Intersects>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>will always come lat/long now and this breaks everything.
-ivan
aaime wrote:
Sébastien Geindre ha scritto:
thanks Andrea !
- googleearth draw (via kml) with lat,lon (in europe, the right
place!!)No no, Google Earth pretends data in lon/lat as well. But it's
specified
in the protocol clearly, so whatever you do you get them in lon/lat
order as far as I know. Are you sure you're getting them in lat/lon in
the KML?See also the KML documentation, for example here:
http://code.google.com/apis/kml/documentation/kml_tags_21.html#point
It says:
<coordinates>...</coordinates> <!-- lon,lat[,alt] -->you are right !!
coordinates in kml are in lon, lat
my polygon is drawn in europe, everything normal.does the reference to the srsName force geoserver to translate from
lat,long to long,lat (WKT reader for postgis) ?Yes, but that will happen only in the upper layers of the WFS stack,
not in the datastores.ok it means that in postgis it is store in lon,lat...
and geoserver, anwser to wfs request, reformat from lon,lat to lat,lon,
that's it ?Exactly, you got it. It's a special case of reprojection.
the real question is : when you specified espg 4326 projection , do
you specify lat,lon or lon,lat coordinate system ?Always lon/lat, there is no storage mechanism using lat/lon afaik, only
the guys at OGC pretend lon/lat usage, and we give it only for
urn:ogc:def:crs:EPSG:xxxx format, and only for WFS 1.1, in order to
be compliant with the spec (this does not break us too much since
there are no WFS 1.1 clients around, and the new that will be developed
will have to deal with this axis order inversion thing).If you grab the latest nightly and don't configure it in any special
way you'll have to:
* have your data stored in lon/lat order (we don't support the opposite
since nothing uses lat/lon order by default)
* if you use WFS 1.0 or WFS 1.1 but requesting data with EPSG:XXXX srs
you'll get back lon/lat
* if you use WFS 1.1 and use urn:ogc:def:crs:EPSG:xxxx form then you'll
get back lat/lon order (but then you're on your own, nothing can read
data with that axis order nowadays)
* KML output should be always generated in lon/lat order anyways since
that's what the KML spec says
* with OL you should use WFS 1.0 or, if you need WFS 1.1 capaibilities
for some reason, do specify srs in EPSG:XXXX format and ask for GML2
output format.Does this make sense?
yes, when i request wfs without specify any srs, i obtain the response
in lat,lon.is it because of WFS 1.1 ???Exatly. The WFS 1.1 standard say that if not srs is requested, the
declared one should be used. And the declared one is in the
urn:ogc:def:crs:EPSG:xxxx (otherwise we would not pass the wfs 1.1
cite tests), so it's lat/lon.The OGC requirements will screw up every known client, but what can I
do? I already complained and they told me that I should have to look
outside of the GIS field where everybody else is using lat/lon.
Oh well...Cheers
Adrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/beta3-to-beta4-%3A-FORCE_AXIS_ORDER_HONORING-tp13708899p15079153.html
Sent from the GeoServer - User mailing list archive at Nabble.com.
found the answer to my question thanks to Justin here:
http://www.nabble.com/forum/ViewPost.jtp?post=14534755&framed=y
<wfs:Query typeName="ntlis:ROAD_CENTRELINES" srsName="EPSG:XXXX" >
thanks everyone !!
-i
ivanprice wrote:
and yes sorry that request is broken but you get the idea.
ivanprice wrote:
so i can see that if i request data using a certain SRS i can control the
order of the lat/longs coming back, but what about when i make a
getfeature request with a non-geometry filter ? is there a way to stick
to long/lat for those ?e.g.
<?xml version="1.0"?>
<wfs:GetFeature xmlns:wfs="http://www.opengis.net/wfs"
xmlns:ogc="http://www.opengis.net/ogc"
xmlns:gml="http://www.opengis.net/gml" version="1.1.0"
outputFormat="GML2">
<wfs:Query typeName="ntlis:ROAD_CENTRELINES">
<ogc:Filter>
<ogc:PropertyIsLike wildCard="%" singleChar="_" escape="\\">
<ogc:PropertyName>ROAD_NAME</ogc:PropertyName>
<ogc:Literal>GREVILLEA</ogc:Literal>
</ogc:PropertyIsLike>
<ogc:Intersects>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>will always come lat/long now and this breaks everything.
-ivan
aaime wrote:
Sébastien Geindre ha scritto:
thanks Andrea !
- googleearth draw (via kml) with lat,lon (in europe, the right
place!!)No no, Google Earth pretends data in lon/lat as well. But it's
specified
in the protocol clearly, so whatever you do you get them in lon/lat
order as far as I know. Are you sure you're getting them in lat/lon in
the KML?See also the KML documentation, for example here:
http://code.google.com/apis/kml/documentation/kml_tags_21.html#point
It says:
<coordinates>...</coordinates> <!-- lon,lat[,alt] -->you are right !!
coordinates in kml are in lon, lat
my polygon is drawn in europe, everything normal.does the reference to the srsName force geoserver to translate from
lat,long to long,lat (WKT reader for postgis) ?Yes, but that will happen only in the upper layers of the WFS stack,
not in the datastores.ok it means that in postgis it is store in lon,lat...
and geoserver, anwser to wfs request, reformat from lon,lat to
lat,lon,
that's it ?Exactly, you got it. It's a special case of reprojection.
the real question is : when you specified espg 4326 projection , do
you specify lat,lon or lon,lat coordinate system ?Always lon/lat, there is no storage mechanism using lat/lon afaik,
only
the guys at OGC pretend lon/lat usage, and we give it only for
urn:ogc:def:crs:EPSG:xxxx format, and only for WFS 1.1, in order to
be compliant with the spec (this does not break us too much since
there are no WFS 1.1 clients around, and the new that will be
developed
will have to deal with this axis order inversion thing).If you grab the latest nightly and don't configure it in any special
way you'll have to:
* have your data stored in lon/lat order (we don't support the
opposite
since nothing uses lat/lon order by default)
* if you use WFS 1.0 or WFS 1.1 but requesting data with EPSG:XXXX srs
you'll get back lon/lat
* if you use WFS 1.1 and use urn:ogc:def:crs:EPSG:xxxx form then
you'll
get back lat/lon order (but then you're on your own, nothing can
read
data with that axis order nowadays)
* KML output should be always generated in lon/lat order anyways since
that's what the KML spec says
* with OL you should use WFS 1.0 or, if you need WFS 1.1 capaibilities
for some reason, do specify srs in EPSG:XXXX format and ask for GML2
output format.Does this make sense?
yes, when i request wfs without specify any srs, i obtain the response
in lat,lon.is it because of WFS 1.1 ???Exatly. The WFS 1.1 standard say that if not srs is requested, the
declared one should be used. And the declared one is in the
urn:ogc:def:crs:EPSG:xxxx (otherwise we would not pass the wfs 1.1
cite tests), so it's lat/lon.The OGC requirements will screw up every known client, but what can I
do? I already complained and they told me that I should have to look
outside of the GIS field where everybody else is using lat/lon.
Oh well...Cheers
Adrea-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
--
View this message in context: http://www.nabble.com/beta3-to-beta4-%3A-FORCE_AXIS_ORDER_HONORING-tp13708899p15079409.html
Sent from the GeoServer - User mailing list archive at Nabble.com.