Opened 9 years ago
Closed 8 years ago
#2893 closed defect (invalid)
Specify crs when exporting to GeoJSON
Reported by: | pmav99 | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.0.5 |
Component: | Default | Version: | unspecified |
Keywords: | v.out.ogr | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
If the information is available, v.out.ogr
should probably specify the "crs" attribute when exporting to GeoJSON. ogr2ogr
seems to support this feature.
$ pacman -Qs gdal local/gdal 2.0.1-6 A translator library for raster geospatial data formats
A GeoJSON
file with no crs
:
$ cat sample.json { "type": "Polygon", "coordinates": [ [ [ -84.32281494140625, 34.9895035675793 ], [ -84.29122924804688, 35.21981940793435 ], [ -84.24041748046875, 35.25459097465022 ], [ -84.32281494140625, 34.9895035675793 ] ] ] }
Reprojecting:
$ ogr2ogr -f GeoJSON -t_srs "EPSG:3857" 3857.json sample.json $ ogr2ogr -f GeoJSON -t_srs "EPSG:4326" 4326.json sample.json
The new files:
$ cat 3857.json { "type": "FeatureCollection", "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::3857" } }, "features": [ { "type": "Feature", "properties": { }, "geometry": { "type": "Polygon", "coordinates": [ [ [ -9386772.821532785892487, 4162454.812297557480633 ], [ -9383256.718231666833162, 4193793.993894479703158 ], [ -9377600.378138564527035, 4198533.089648159220815 ], [ -9386772.821532785892487, 4162454.812297557480633 ] ] ] } } ] }
$ cat 4326.json { "type": "FeatureCollection", "crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:OGC:1.3:CRS84" } }, "features": [ { "type": "Feature", "properties": { }, "geometry": { "type": "Polygon", "coordinates": [ [ [ -84.32281494140625, 34.989503567579298 ], [ -84.291229248046875, 35.219819407934352 ], [ -84.24041748046875, 35.25459097465022 ], [ -84.32281494140625, 34.989503567579298 ] ] ] } } ] }
By the way, when crs is not defined ogrinfo
seems to default to EPSG:4326
which I guess is the most reasonable choice, although I think I would prefer something more explicit (e.g. a warning):
$ ogrinfo -so -al sample.json ERROR 4: GeoJSON Driver doesn't support update. Had to open data source read-only. INFO: Open of `sample.json' using driver `GeoJSON' successful. Layer name: OGRGeoJSON Geometry: Polygon Feature Count: 1 Extent: (-84.322815, 34.989504) - (-84.240417, 35.254591) Layer SRS WKT: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]]
Change History (4)
comment:2 by , 9 years ago
Quoting the geojson spec ( http://geojson.org/geojson-spec.html#coordinate-reference-system-objects ) : "The default CRS is a geographic coordinate reference system, using the WGS84 datum, and with longitude and latitude units of decimal degrees." . So OGR behaviour follows the spec.
And the new geojson spec ( https://www.ietf.org/id/draft-ietf-geojson-00.txt ) deprecates the use of other CRS : "Other coordinate reference systems, including ones described by CRS objects of the kind defined in [GJ2008] are NOT RECOMMENDED"
comment:4 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
It seems that the specs are respected, so not much we can do here. Closing.
Hmm... it seems
ogr2ogr
's implicit choices can lead to bugs :If we erase the CRS field from
3857.json
:Then
ogrinfo
assumes that EPSG is 4326:reprojecting does not make any changes to the coords (which is expected I guess):
but this particular
(coords, crs)
combination is obviously garbage: