GeoJSON 2008 specification (obsoleted by RFC 7946) about arcgis-to-geojson-utils HOT 8 CLOSED

First some docs for context:

https://tools.ietf.org/html/rfc7946
https://sgillies.net/2016/08/11/rfc-7946-the-geojson-format.html

I've started having a look into this today. Here are some initial thoughts:

1. I think the main thing is the ring winding order. For example, if I do:

const geojson = arcgisToGeoJSON({
  'rings': [
    [
      [41.8359375, 71.015625],
      [56.953125, 33.75],
      [21.796875, 36.5625],
      [41.8359375, 71.015625]
    ]
  ]
});
console.log(JSON.stringify(geojson));

that will output

{
  "type": "Polygon",
  "coordinates": [
    [
      [41.8359375, 71.015625],
      [56.953125, 33.75],
      [21.796875, 36.5625],
      [41.8359375, 71.015625]
    ]
  ]
}

If I validate the output at http://geojsonlint.com/ that will fail with Polygons and MultiPolygons should follow the right-hand rule.

2. RFC 7946 does have some opinions on decimal precision although I think it actually stops short of making a particular co-ordinate precision a hard requirement. This library passes through the number of places used in the input json rather than rounding e.g:

const geojson = arcgisToGeoJSON({
  "x":-66.0123456789,
  "y":20.0123456789,
  "spatialReference": {
    "wkid": 4326
  }
});
console.log(JSON.stringify(geojson));

outputs

{
  "type": "Point",
  "coordinates": [
    -66.0123456789,
    20.0123456789
  ]
}

although I am unclear if this is strictly invalid, or just recommended against. @jgravois I don't know if you have any thoughts on whether rounding should be applied in the conversion?

3. The GJ2008 spec does allow the use of alternative coordinate reference systems, but RFC 7946 mandates the use of WGS84 so something like

const geojson = arcgisToGeoJSON({
  "x": 392917.31,
  "y": 298521.34,
  "spatialReference": {
    "wkid": 27700
  }
});

console.log(JSON.stringify(geojson));

should probably fail to convert (I think it is out of scope for a format conversion tool to attempt to transpose between co-ordinate reference systems). That said, at the moment the output of this does not even include a "crs" object. It just outputs

{
  "type": "Point",
  "coordinates": [
    392917.31,
    298521.34
  ]
}

so this behaviour is probably invalid by either spec.

I'll try and go through it in more detail as my reading is currently incomplete (I only started looking at this today after @learning4life raised an issue about this on another repo), but I expect that the right-hand rule/ring winding order is the main change that would be needed to support this.

from arcgis-to-geojson-utils.

1. ring winding order

i agree that we should ensure that the ring orientation of output GeoJSON is correct. a PR for this would definitely be welcomed.

there is no need to start from scratch. i think a straight port of my unlanded work in terraformer-arcgis-parser in existing methods is all that's needed.

2. rounding coordinate precision

@jgravois I don't know if you have any thoughts on whether rounding should be applied in the conversion?

i'm as frustrated by false precision as anyone but i don't think its the place of this library to apply rounding to coordinates when converting between GeoServices and GeoJSON.

3. "RFC 7946 mandates the use of WGS84"

removing the specification of crs from within GeoJSON is not the same thing as mandating the use of WGS84. despite Sean's paraphrasing, i think it would be a mistake for this lib to error out when coordinates in a crs other than WGS84 are encountered, primarily because of the note below.

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.

3. id is a string or a number

i don't understand why anyone would pass on object literal as an id, but if its a situation you feel warrants trapping, PR away.

all in all, thank you both for your comments and questions. i'm a fan of the prescriptions of RFC 7946, so even though there are areas where i don't feel that internal changes are necessary I'd still welcome documentation, samples and even messages logged to the console to steer developers in the right direction.

from arcgis-to-geojson-utils.

Thanks for the feedback @jgravois - I'll aim to submit a PR later in the week

from arcgis-to-geojson-utils.

released as v1.1.0.

thanks y'all.

from arcgis-to-geojson-utils.

what is it about the geojson produced by this repo that isn't compliant with RFC 7946?

from arcgis-to-geojson-utils.

see also: Esri/terraformer-wkt-parser#15

from arcgis-to-geojson-utils.

Thanks @chris48s for your in-depth input.

@jgravois let me quote Sean Gillies:

The changes from the Pre-IETF GeoJSON Format Specification published in 2008 at http://geojson.org are listed at https://tools.ietf.org/html/rfc7946#appendix-B.

To summarize:

• Coordinate reference systems are no longer in the core of the specification; use CRS84 longitude and latitude with GeoJSON from now on.
• Don't extend coordinate arrays with linear referencing measure, timestamps, or other variables.
• Follow the math and physics right-hand rule (not the surveyor's right-hand rule) when forming polygon rings.
• Construct bounding boxes so they are not ambiguous at the Earth's poles and antimeridian.
• Do extend GeoJSON, but don't change its semantics.
• Don't write longitude and latitude values with more than 7 decimal places of precision.
• Avoid using GeometryCollection when possible.
• Reference RFC 7946 from now on instead of http://geojson.org.

Here's an important point that may be obscured by formalities: RFC 7946 does not define a "GeoJSON 2.0." This is "GeoJSON." If you need to be more specific, e.g., in describing support for deprecated features like "crs", you should refer to "2008 geojson.org GeoJSON" vs. "RFC 7946 GeoJSON" or "application/geo+json GeoJSON." There is no "GeoJSON 2.0."

from arcgis-to-geojson-utils.

Having spent some more time looking at this, there's one other thing I can find. The RFC says that id is a string or a number, but if I do

const geojson = arcgisToGeoJSON({
  "x":-122.6764,
  "y":45.5165,
  "spatialReference": {
    "wkid": 4326
  },
  'attributes': {
    'some_field': {
      'not an number': 'or a string'
    }
  }
}, 'some_field');

console.log(JSON.stringify(geojson));

that will log

{
  "type": "Feature",
  "coordinates": [
    -122.6764,
    45.5165
  ],
  "geometry": null,
  "properties": {
    "some_field": {
      "not an number": "or a string"
    }
  },
  "id": {
    "not an number": "or a string"
  }
}

which is also non-compliant.

@jgravois - I've started looking at a PR for this stuff and I'm happy to work on it, but I'd like to be reasonably confident that there is a good chance of it getting merged (subject to your usual review process, obviously) before I sink a bunch of time into it.

from arcgis-to-geojson-utils.