Ref:
http://docs.geoserver.org/latest/en/user/services/wfs/basics.html#axis-ordering
we use the proper :) (x,y) ordering (lon,lat). This conforms to CRS:84 (same as EPSG:4326, but with lon/lat). It's an annoying situation as many systems advertised WGS:84/EPSG:4326, but expected lon/lat - (which is technically wrong), but now many systems are also expecting lat/lon for the same system.
WFS also adds more fire to the mix by having a default ordering when no CRS is specified (which many requests rely on), and OGC changed that default ordering from (x,y) in 1.0 to (y,x) in 1.1 and 2.0.
The link above shows the geoserver adds additional permutations to the mix by changing the default order based on the representation of the URN sent.
Basically we need to either handle these cases, or document them very well (or probably both)
Ref:
http://docs.geoserver.org/latest/en/user/services/wfs/basics.html#axis-ordering
we use the proper :) (x,y) ordering (lon,lat). This conforms to CRS:84 (same as EPSG:4326, but with lon/lat). It's an annoying situation as many systems advertised WGS:84/EPSG:4326, but expected lon/lat - (which is technically wrong), but now many systems are also expecting lat/lon for the same system.
WFS also adds more fire to the mix by having a default ordering when no CRS is specified (which many requests rely on), and OGC changed that default ordering from (x,y) in 1.0 to (y,x) in 1.1 and 2.0.
The link above shows the geoserver adds additional permutations to the mix by changing the default order based on the representation of the URN sent.
Basically we need to either handle these cases, or document them very well (or probably both)