[Geoserver-devel] WFS-NG and flipped coordinates

GeoServer GeoServer Developer
1

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?

Sampo

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

2

We are kind of doomed[1] with axis order issue due to the changes between different OGC specifications over time.

Basically EPSG:4326 = I don’t know it depends how each application is configured. To be more sure please use one of the longer URN formats for spatial reference system.

···

Jody Garnett

On Tue, Apr 22, 2014 at 5:12 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> 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?

Sampo

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Hi Jody,

Yeah, I know. Axis order has been quite messed up, especially for 4326. However note that I’m not using 4326 but 4258. There are no special considerations (at least to my knowledge) that need to take place here, and as such, I don’t believe there is any reason for GeoServer to use a version of the CRS where the axis order is forced to east-north.

S.

···

On Tue, Apr 22, 2014 at 10:41 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

We are kind of doomed[1] with axis order issue due to the changes between different OGC specifications over time.

Basically EPSG:4326 = I don’t know it depends how each application is configured. To be more sure please use one of the longer URN formats for spatial reference system.

Jody

[1] http://docs.geotools.org/latest/userguide/library/referencing/order.html

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

Jody Garnett

On Tue, Apr 22, 2014 at 5:12 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> 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?

Sampo

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

4

On Tue, Apr 22, 2014 at 9:12 AM, Sampo Savolainen <
sampo.savolainen@anonymised.com> 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

-------------------------------------------------------

5

On Tue, Apr 22, 2014 at 9:44 AM, Sampo Savolainen <
sampo.savolainen@anonymised.com> wrote:

Hi Jody,

Yeah, I know. Axis order has been quite messed up, especially for 4326.
However note that I'm not using 4326 but 4258. There are no special
considerations (at least to my knowledge) that need to take place here, and
as such, I don't believe there is any reason for GeoServer to use a version
of the CRS where the axis order is forced to east-north.

There is no special consideration for 4326, every working source returns
data in earth/north order, consisently, for all codes
(e.g., try that code with postgis, shapefile, whatever, anything that has
not been touched by OGC)

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

-------------------------------------------------------

6

For an example of another block of code that has to deal with interoperability look at the WMS client code used in the WMS cascade case.

In this case each “external” bounding box handled xplicitly, rewriting to internal URN syntax, or using forceLatLong as required to accurately represent the data. With this accurate representation it is reprojected as quickly possible to the order used by GeoServer to avoid confusion.

···

Jody Garnett

On Tue, Apr 22, 2014 at 5:50 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Tue, Apr 22, 2014 at 9:12 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> 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

7

Hi,

Ok. So let’s look at the specific use case I’m working on. Here’s the current status:

  • The WFS backend (non-geoserver) returns the data in the the axis order of the CRS.
  • WFS-NG module interacts with the WFS backend appropriately and reads the the returned features.
  • If SRS handling is “force declared”, the feature reader stack produces features in east-north order => WMS draws geometries incorrectly (expects different order)
  • If SRS handling is “native” or “reproject”, the feature reader stack produces features in north-east order => WMS draws geometries correctly

This conflicts with what Andrea said about how coordinates should always be represented in east-north inside GeoServer. This probably means that there’s something else going on that I’m not aware of. Judging by your comments on the design, the feature reader stack should always produce features with a forced east-north axis order. So why are features in the correct order drawn incorrectly by the WMS service?

Sampo

···

On Tue, Apr 22, 2014 at 10:50 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Tue, Apr 22, 2014 at 9:12 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> 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

8

On Tue, Apr 22, 2014 at 11:00 AM, Sampo Savolainen <
sampo.savolainen@anonymised.com> wrote:

Hi,

Ok. So let's look at the specific use case I'm working on. Here's the
current status:
- The WFS backend (non-geoserver) returns the data in the the axis order
of the CRS.
- WFS-NG module interacts with the WFS backend appropriately and reads
the the returned features.
- If SRS handling is "force declared", the feature reader stack produces
features in east-north order => WMS draws geometries incorrectly (expects
different order)
- If SRS handling is "native" or "reproject", the feature reader stack
produces features in north-east order => WMS draws geometries correctly

This conflicts with what Andrea said about how coordinates should always
be represented in east-north inside GeoServer. This probably means that
there's something else going on that I'm not aware of. Judging by your
comments on the design, the feature reader stack should always produce
features with a forced east-north axis order. So why are features in the
correct order drawn incorrectly by the WMS service?

Force declared means what it says, it ignores the data own crs and forces
the one declared (as in, keep the data, and just change the crs metadata).
So the rendering engine is getting data in north/east order, but with a crs
declared in east/north, and it does not flip them

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

-------------------------------------------------------

9

Hi,

But according to how I understood what you and Jody said, shouldn’t drawing happen correctly when the geometries are forced to east-north? Now the opposite is happening.

S.

···

On Tue, Apr 22, 2014 at 12:03 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Tue, Apr 22, 2014 at 11:00 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Ok. So let’s look at the specific use case I’m working on. Here’s the current status:

  • The WFS backend (non-geoserver) returns the data in the the axis order of the CRS.
  • WFS-NG module interacts with the WFS backend appropriately and reads the the returned features.
  • If SRS handling is “force declared”, the feature reader stack produces features in east-north order => WMS draws geometries incorrectly (expects different order)
  • If SRS handling is “native” or “reproject”, the feature reader stack produces features in north-east order => WMS draws geometries correctly

This conflicts with what Andrea said about how coordinates should always be represented in east-north inside GeoServer. This probably means that there’s something else going on that I’m not aware of. Judging by your comments on the design, the feature reader stack should always produce features with a forced east-north axis order. So why are features in the correct order drawn incorrectly by the WMS service?

Force declared means what it says, it ignores the data own crs and forces the one declared (as in, keep the data, and just change the crs metadata).
So the rendering engine is getting data in north/east order, but with a crs declared in east/north, and it does not flip them

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

10

The drawing code correctly sets up a transform, so as long as the CRS matches the data it will work.

The rest of GeoServer is not quite so well tested, so expect trouble (for example with bounding boxes).

···

Jody Garnett

On Tue, Apr 22, 2014 at 7:00 PM, Sampo Savolainen <sampo.savolainen@anonymised.com> wrote:

Hi,

Ok. So let’s look at the specific use case I’m working on. Here’s the current status:

  • The WFS backend (non-geoserver) returns the data in the the axis order of the CRS.
  • WFS-NG module interacts with the WFS backend appropriately and reads the the returned features.
  • If SRS handling is “force declared”, the feature reader stack produces features in east-north order => WMS draws geometries incorrectly (expects different order)
  • If SRS handling is “native” or “reproject”, the feature reader stack produces features in north-east order => WMS draws geometries correctly

This conflicts with what Andrea said about how coordinates should always be represented in east-north inside GeoServer. This probably means that there’s something else going on that I’m not aware of. Judging by your comments on the design, the feature reader stack should always produce features with a forced east-north axis order. So why are features in the correct order drawn incorrectly by the WMS service?

Sampo

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Tue, Apr 22, 2014 at 10:50 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolainen@anonymised.com89…
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc

This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.

On Tue, Apr 22, 2014 at 9:12 AM, Sampo Savolainen <sampo.savolainen@anonymised.com> 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

11

On Tue, Apr 22, 2014 at 11:13 AM, Sampo Savolainen <
sampo.savolainen@anonymised.com> wrote:

Hi,

But according to how I understood what you and Jody said, shouldn't
drawing happen correctly when the geometries are forced to east-north? Now
the opposite is happening.

"Force declared" does not change the geometry, it just replaces the CRS
metadata.

The wfs-ng is cascading a WFS 2.0, which returns data in north/east order,
then GeoServer projection handling
code forces the CRS (metadata) to be in eart/noth order (the metadta, not
the geometries, and it does because you told
it to do that), at this point we have geometries in one order, the metadata
in the opposite one, and things just blow up.

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

-------------------------------------------------------