[papercrane]

> It works great as long as you squint just a bit, ignoring that it generally calls for long,lat and is designed with the assumption of a world CRS.

I thought the spec allowed you to specify the CRS, but I just checked the RFC and they removed that from the 2016 specification and WGS84 is specified. It does allow for alternative CRS with prior arrangement, but like you said that does require a lot of care.

[CornCobs]

Yes, they deprecated the CRS field and the current state of geojson handling libraries is pretty messy as a result since geojson does not have versioning!

If you have old geojson in a different projection, will your library respect the crs field or will it simply misinterpret your data?

Wondering if anyone could shed light on the decision to remove it as a standard when projection seems to be a critical part of GIS.

[Waterluvian]

Coordinate systems and projections are one of those deeply complicated truths that makes such a headache in GIS. I still shudder at all the pain in school and at previous jobs dealing with inconsistent datasets.

It seems like they decided to just opt out of trying (see the yellow box in section 4): https://stevage.github.io/geojson-spec/#section-4

I think they should have completely backed off from touching on projections and datums in the format altogether. Ie. Something like, “coordinates are 2 or 3 tuples where the values in order correspond with easting/long and northing/lat and elevation/altitude. See metadata for agreed upon units and CRS/projection semantics. It is strongly encouraged to standardize on WGS84 when encoding data with an earth-resolvable datum.”

Because GeoJSON otherwise works fine for indoor spaces, video game spaces, fictional lands, other celestial bodies, etc. You just have to educate on the idea that there’s more to data compatibility than it being GeoJSON.

[drewda]

Yup, technically speaking if the coordinates aren't in WGS84, it isn't GeoJSON