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
<[email protected]>wrote:
> 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
>
> -------------------------------------------------------
>
--
Sampo Savolainen
R&D Director, Spatineo Oy
[email protected]
+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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
