[Feature Request] automatically reproject to WGS84 if saving a file as GeoJSON
See original GitHub issuegeopandas: '0.5.0'
I had this projection issue as well before: https://stackoverflow.com/questions/56806907/gis-shapefile-converted-to-geojson-has-unexpected-coordinate-format
As GeoJSON only supports WGS84. does it make more sense to automatically reproject the GeoDataFrame
being saved as a GeoJSON file? and also of course, give users a warning
Issue Analytics
- State:
- Created 4 years ago
- Reactions:8
- Comments:13 (7 by maintainers)
Top Results From Across the Web
OpenLayers 4.6.5 GeoJSON WGS84 not mapped with a ...
Features and overlays do not automatically reproject if you change the view projection, but you can add some code to update them map....
Read more >Chapter 7 GeoJSON | Introduction to Web Mapping
7.1 Introduction. In this chapter, we are going to learn about GeoJSON—a plain text format for vector layers. On the one hand, GeoJSON...
Read more >Don't Forget to Reproject Spatial Data when Exporting to ...
My current workflow for taking shapefiles, adding/removing features and data, and writing out a GeoJSON file that can be read in D3 or ......
Read more >Tutorial 9: Vector data handling with Python - WUR Geoscripting
Today we will explore a variety of Python packages for vector data handling: ... A GeoDataFrame can be written directly to a GeoJSON...
Read more >GeoJSONLayer | ArcGIS Maps SDK for JavaScript 4.25
An array of field names from the geoJSON file to include with each feature. more details, GeoJSONLayer. popupEnabled, Boolean.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I disagree, I think most people want to export their geodataframe to geojson without having to know trivia like epsg:4326 is the only valid geojson projection. Users don’t get to use their own crs for geojson (according to the spec), so if their frame is not projected, we should assign 4326, and if it is projected we should be converting their data to the correct projection so that the output is valid with a warning that the tool ‘had to reproject from <orig proj> to epsg:4326’.
@snowman2 I think it’s worth pointing out that OGC urn:ogc:def:crs:OGC::CRS84 is the official system for GeoJSON, not EPSG 4326. Using the latter as shorthand for the former is going to be problematic in the future where systems based on GDAL 2 and GDAL 3 need to coexist, yes?
The sentence in the GeoJSON spec that you referenced means to acknowledge that projected data which happens to be structured like GeoJSON is often useful in some contexts. Rasterio’s rio-shapes command lets a user output GeoJSON-like data for features extracted from a raster dataset in the projection of the raster, for the purpose of piping the data into rio-rasterize (for example) and not suffering any degradation of coordinates. It’s not even necessary to put the CRS in the data for these applications as the CRS is communicated out of band. That’s what “prior arrangement” means.
The sentence does not say that it’s correct to write projected GeoJSON-like data, add a “crs” object to it, and call it “GeoJSON” with the expectation that all GeoJSON readers can understand it.
Summary: GeoPandas ought to let users export projected GeoJSON-like data for their own needs. A warning when doing so might be appropriate. Putting a CRS object on the GeoJSON like GDAL has done is no longer correct and reduces interoperability.