Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend docs for GeoJSON format #40

Open
kadyb opened this issue Apr 12, 2024 · 6 comments
Open

Extend docs for GeoJSON format #40

kadyb opened this issue Apr 12, 2024 · 6 comments
Labels
enhancement New feature or request

Comments

@kadyb
Copy link
Contributor

kadyb commented Apr 12, 2024

I think we should include in the docs explicitly that saving and loading GeoJSON assumes WGS 84 coordinate reference system (EPSG:4326).

library("sf")
library("yyjsonr")

nc = read_sf(system.file("shape/nc.shp", package = "sf"))
nc = st_transform(nc, "EPSG:3857")

write_sf(nc, "test1.geojson")
write_geojson_file(nc, "test2.geojson")

x = read_sf("test1.geojson")
st_crs(x)$epsg
#> [1] 3857
y = read_geojson_file("test2.geojson")
st_crs(y)$epsg
#> [1] 4326
@coolbutuseless
Copy link
Owner

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

@kadyb
Copy link
Contributor Author

kadyb commented Apr 12, 2024

I have no idea, but we can ask on Mastodon 😄 If we don't find anything, we can adapt the first example.

@kadyb
Copy link
Contributor Author

kadyb commented Apr 12, 2024

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 ] } }
]
}

@coolbutuseless
Copy link
Owner

coolbutuseless commented Apr 12, 2024

I have added your initial test case with nc.shp to the tests in branch geojson-crs.

  • find database of mappings between crs code and the wkt string
  • make_default_crs() uses wgs84
  • possibly need a fuzzy crs comparison as geojsonsf and 'sf' might not agree verbatim. Needed for testing
  • pass crs from parent to child function when parsing
  • write crs when generating geojson

@coolbutuseless coolbutuseless added the enhancement New feature or request label Apr 12, 2024
@coolbutuseless
Copy link
Owner

coolbutuseless commented Apr 13, 2024

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.

@kadyb
Copy link
Contributor Author

kadyb commented Apr 13, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants