On Tue, Apr 22, 2014 at 9:12 AM, Sampo Savolainen <
[email protected]> wrote:
> Hi,
>
> There might be a bug in WFS-NG relating to axis order of coordinates
> returned by layers created by WFS-NG.
>
> I created a dummy feature type on one geoserver serving content in
> EPSG:4258 (northing-easting), then created a feature type in another
> geoserver by cascading the first server using WFS-NG (WFS 1.1.0). The
> WFS-NG feature type uses the same CRS.
>
> When accessing the first geoserver directly (GetFeature), I get the
> coordinates in the correct order. But when accessing the cascading feature
> on the second server (GetFeature again), the coordinates have flipped.
>
> While debugging this, I found that the problem is connected to SRS
> handling in the layer. If "force declared" is chosen, the axis order of the
> returned features if flipped. Both "keep native" and "reproject native to
> declared" work fine.
>
> In GeoServerFeatureSource.reprojectFilter(), declaredCRS has the wrong
> axis order (east-north) while nativeCRS has the correct one (north-east).
> Why is the axis order wrong in declaredCRS? Is this by design / am I
> missing something, or has WFS-NG initialized the FeatureSource wrong
> somehow?
>
Basically for a data source to work properly with GeoServer it has to
return data in east/north order,
if you return it in north/east, even if you use the urn forms, it won't
work.
Longer explanation: in GeoServer the declared EPSG code _has_ to be in the
EPSG:XYWZ form,
which in GeoServer means east/north axis order.
We can't use another authority (http://jira.codehaus.org/browse/GEOS-903),
we can't use the urn form,
GeoServer GUI won't understand it and there is code spread around assuming
the east/north
axis order that will break if we just loosen the GUI.
The reason why things work in reproject to declared and keep native is that
much of the underlying code
can handle axis flipping fine (all the code that uses
CoordinateReferenceSystem instead of its string
representation), so as long as we lie about the CRS to the code that deals
with the string form, we're good.
Options here:
1) make GeoServer source data axis order aware (large refactor, many little
pieces spread around to fix)
2) make your data source always return data in east/north order
3) have some GeoServer code bits aware of the source data axis order issue
and wrap it in a reprojecting
feature source before the rest of the code sees it
Option 1) is expensive, option 2) is not really natural, option 3) can be
fragile and introduce performance
overhead if not done properly.
Hmm.. pick your poison?
Cheers
Andrea
--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
