Open kadyb opened 3 months ago
Yyjsonr should probably parse/write this correctly.
This is my fault for only having test cases with WGS84!
If you/anyone know of sets of test cases around crs that would be a helpful
I have no idea, but we can ask on Mastodon 😄 If we don't find anything, we can adapt the first example.
I think this can be used as a minimum file:
{
"type": "FeatureCollection",
"name": "crs_test",
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::3857" } },
"features": [
{ "type": "Feature", "properties": { }, "geometry": { "type": "Point", "coordinates": [ 0.0, 0.0 ] } }
]
}
I have added your initial test case with nc.shp
to the tests in branch geojson-crs
.
According to GeoJSON RFC 7946, https://datatracker.ietf.org/doc/html/rfc7946#section-4 , coord reference system should only be WGS84.
Also discussed here: https://code.whatever.social/exchange/gis/questions/203439/how-to-identify-the-co-ordinate-system-crs-srs-of-a-geojson-file
Support for other CRSs seems out-of-spec.
So, I might do as you originally suggested and document that "WGS84 is the assumed CRS - in accordance with the RFC".
The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [[WGS84](https://datatracker.ietf.org/doc/html/rfc7946#ref-WGS84)] datum, with longitude and latitude units
of decimal degrees. This is equivalent to the coordinate reference
system identified by the Open Geospatial Consortium (OGC) URN
urn:ogc:def:crs:OGC::CRS84. An OPTIONAL third-position element SHALL
be the height in meters above or below the WGS 84 reference
ellipsoid. In the absence of elevation values, applications
sensitive to height or depth SHOULD interpret positions as being at
local ground or sea level.
Note: the use of alternative coordinate reference systems was
specified in [[GJ2008](https://datatracker.ietf.org/doc/html/rfc7946#ref-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](https://datatracker.ietf.org/doc/html/rfc7946#ref-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.
BTW: For GDAL and RFC7946 compatibility, you may also consider saving only 7 decimal digits by default, which will reduce the file size a bit (https://gdal.org/drivers/vector/geojson.html#rfc-7946-write-support).
I think we should include in the docs explicitly that saving and loading GeoJSON assumes WGS 84 coordinate reference system (EPSG:4326).