0

It has been discussed how different versions of WFS output lat/long in different orders: https://docs.geoserver.org/latest/en/user/services/wfs/axis_order.html

This URL, for instance, in GeoJSON with this URL:

http://localhost:8080/geoserver/cite/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=cite%3Anyc_buildings&maxFeatures=2&outputFormat=application%2Fjson

outputs:

{"type":"FeatureCollection","features":[{"type":"Feature","id":"nyc_buildings.1","geometry":{"type":"MultiPolygon","coordinates":[[[[-73.98491055,40.74005906],[-73.9849737,40.74008594],[-73.98504876,40.74011791],[-73.98488089,40.74034721],[-73.98480556,40.74031513],[-73.98472899,40.74028253],[-73.98479823,40.7401898],[-73.98481948,40.74019886],[-73.9848708,40.74012916],[-73.98484753,40.74011925],[-73.98488251,40.74007141],[-73.98489601,40.74005307],[-73.98491055,40.74005906]]]]},"geometry_name":"the_geom","properties":{"bin":0}},{"type":"Feature","id":"nyc_buildings.2","geometry":{"type":"MultiPolygon","coordinates":[[[[-73.99500641,40.74170638],[-73.99497717,40.74174708],[-73.99460553,40.7415927],[-73.99465874,40.74151862],[-73.99476388,40.74137248],[-73.99513481,40.74152994],[-73.99500641,40.74170638]]]]},"geometry_name":"the_geom","properties":{"bin":0}}],"totalFeatures":6528,"numberMatched":6528,"numberReturned":2,"timeStamp":"2019-09-17T18:14:44.077Z","crs":{"type":"name","properties":{"name":"urn:ogc:def:crs:EPSG::4326"}}}

Since simply changing to WFS&version=2.0.0 in the URL doesn't change the order, what is the proper way to output a GeoJSON with a different version of WFS?

  • 3
    GeoJSON is by definition always Longitude-Latitude or Easting-Northing. See the old specification geojson.org/geojson-spec.html and the current one tools.ietf.org/html/rfc7946. – user30184 Sep 17 '19 at 19:43
  • As an addendum GeoJSON is NOT EPSG:4326, it's CRS:84; they may use the same ellipsoid and datum, but precisely because they use lat/long vs long/lat axes order they are not the same CRS – nmtoken Sep 18 '19 at 20:10
  • Also note that crs: member is deprecated in GeoJSON, use CRS other than CRS:84 at your peril – nmtoken Sep 18 '19 at 20:13
  • By the way, GeoServer WFS returns classic GeoJSON (pre RFC 7946) and there is no way to ask for the newer one. That would not change the CRS or axis order though, per previous arrangement, but there are other differences. – Andrea Aime Sep 19 '19 at 10:41
2

In GeoServer you always the the CRS you asked for, or the protocol default otherwise (which is declared in the capabilities).

The GeoJSON specification allows for other CRSs if there is a "previous arrangement", quoting from RFC 7946:

Note: the use of alternative coordinate reference systems was specified in [GJ2008], but it has been removed from this version of the specification because the use of different coordinate reference systems -- especially in the manner specified in [GJ2008] -- has proven to have interoperability issues. In general, GeoJSON processing software is not expected to have access to coordinate reference system databases or to have network access to coordinate reference system transformation parameters. However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

The WFS protocol is the "previous arrangement", it leaves no space for outputs to have a CRS other than the one requested, and the client doing the request should be aware of it.

If you need to force a common GeoJSON output, you can request the output to be in "EPSG:4326" (adding "&srsName=EPSG:4326"), and then you'll get lon/lat in WGS84.

| improve this answer | |
  • So if by prior arrangement I want GeoJSON in lat/long as EPSG:4326, how do you do that? – nmtoken Sep 19 '19 at 10:29
  • Simple, you don't use WFS to get it (or learn to use WFS for what it is) :-D Seriously, if you really wanted, you could force EPSG:4326 as the CRS for the layer, but using WFS 1.1 or WFS 2.0 you would still get back lat/lon order, because that's what the spec mandates. – Andrea Aime Sep 19 '19 at 10:36
  • It's a GDAL issue I think, not WFS. The simple answer is only use GeoJSON as per the specification, only CRS:84 (not EPSG:4326). – nmtoken Sep 19 '19 at 10:38
  • Also, there is another emerging possibility, use the OGC Features API (previously known as WFS3) which returns by default RFC GeoJSON in CRS:84 (currently offers no way to get it in any other CRS, an extension will be added to the base protocol to do that). – Andrea Aime Sep 19 '19 at 10:40
  • by default OGC Features API has no format, just the CRS is defaulted – nmtoken Sep 19 '19 at 10:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.