Can st_write warn when writing non-EPSG:4326 GeoJSON files?

[atheriel]

Although GeoJSON does support a crs field, it is not widely supported by client libraries. Popular Javascript visualization libraries (including Leaflet and D3) expect all GeoJSON files to be EPSG:4326, and will break in mysterious ways if this is not the case. The draft GeoJSON standard recommends against it, too.

At the moment sf will happily let you export non-EPSG:4326 GeoJSON files. Obviously this may be desirable in some cases, but I suspect that many users would do so unintentionally.

Is it possible or desirable to have st_write issue a warning when writing non-standard GeoJSON files? I would be happy to write a patch if so.

[edzer]

I am inclined to leave such decisions up to GDAL - as you say, the issue with draft standards is that they are not yet "the" standard, we have to live with that now, and understand the consequences.

[atheriel]

This makes sense to me. Presumably GDAL warnings could be propagated up through sf, and the project shouldn't stray too far from the spec. But from my browsing of the GDAL bug tracker it does not look like they will consider this a bug, either.

Still, I suspect that casual consumers of sf (like me) will not "understand the consequences" of the current GeoJSON standard (and its shortcomings), and are very likely to be surprised by this behaviour. That is why I think it might belong at the R level, and not in GDAL.

[edzer]

I'd be happy to go there when the GeoJSON standard is no longer a draft, and prescribes 4326.

[yeelauren]

When using st_write(data, '.out/data.geojson', driver = 'geojson') the geojson contains a CRS.
This goes against the geojson spec, is there a way to use st_write while not including the CRS in the geojson?

This is causing issues for map tiles.

[edzer]

sf is not going to interfere with the GDAL GeoJSON driver by itself, but reading that, you might want to add the argument layer_options = "RFC7946=YES" to follow the RFC spec.