[gdal-dev] RFC 44: Add Parseable Output Formats for ogrinfo and gdalinfo

[Homme Zwaagstra]

Hi Jukka,

On 30/03/15 09:46, Jukka Rahkonen wrote:
> Homme Zwaagstra <hrz  <at> geodata.soton.ac.uk> writes:
 >
 >>
 >>
 >>
 >>     P.S. on the proposal below, perhaps things could be 'standardised'
 >>     even more by
 >>     including the cornerCoordinates in both wgs84 and native coordinate
 >>     systems
 >>     (much like gdalinfo does at the moment).  In this way you can be
 >>     guaranteed of
 >>     getting geojson output in its default coordinate system.  e.g.:
 >>     { "cornerCoordinates":
 >>       { "wgs84": ... GeoJSON FeatureCollection transformed to EPSG:4326
 >>     ...,
 >>         "native: ... GeoJSON FeatureCollection in native coordinates ...
 >>       }
 >>     }
 >>     Best regards,
 >>     Homme
 >
 >
 > Hi,
 >
 > Do you want to open this can of worms? Hardcore GeoJSON folks will 
tell that
 > "GeoJSON FeatureCollection in native coordinates" does not exist because
 > newest GeoJSON draft wants to support only one CRS which is WGS84
 > Longitude-Latitude. From
 > https://datatracker.ietf.org/doc/draft-butler-geojson/?include_text=1
 >
 > "Other coordinate reference systems, including ones described by CRS
 > objects of the kind defined in [GJ2008] are NOT RECOMMENDED."
 >
 > And then hardcore OGC standard folks will tell that the axis order of
 > coordinates must follow the official EPSG:definitions.
 >
 > At least for me as a user of ogrinfo and gdalinfo the bounds in the 
native
 > units are the ones which I need. A few times in a year the geographic 
bounds
 > may be useful but I have not even thought before writing this mail that
 > ogrinfo does not report the WGS84 bounds while gdalinfo does. I deal also
 > often with data with unknown CRS like shapefiles without .prj and 
tiff+tfw
 > files. I suppose that bounds of those cannot be expressed as GeoJSON
 > FeatureCollections according to the new draft because nobody knows how to
 > re-project from unknown to WGS84 and back..

The fact that it is a can of worms is what made me think that providing both
options would be helpful from a practical point of view: many tools expect
geojson to be in wgs84 (in which case use the transformed object) but 
equally as
in your use case it is important to be able to access the native 
coordinates.

I think the key point I wanted to make is that having the coordinates in 
geojson
format makes them more generally accessible, whatever the CRS, but if 
there is
also the option to meet wider (geojson) expectations by also having them in
wgs84 then that can be no bad thing.

Because the JSON output is quite high level it would be nice to not to 
have to
add additional steps such as coordinate transformations to make more 
general use
of the data.  E.g. it would be nice to just be able to pull out the 
extent of a
raster and have it available in a 'known' usable format, such as adding 
it as a
GIS layer, database extent etc.

>
 >
 > I think that the original RFC keeps things simple by relying on plain XML
 > and JSON and not mixing GML and GeoJSON into the play. However, I am 
not a
 > programmer so I may be all wrong.

The geojson and xml is designed to be ingested by programs: I'm in favour of
making this process as easy as possible using standard tools and formats.

I didn't mention GML (the XML component doesn't interest me as much) but now
that you have... ;)

Best regards,

Homme

>
 >
 > -Jukka Rahkonen-
 >
 >
 >
 > _______________________________________________
 > gdal-dev mailing list
 > gdal-dev at lists.osgeo.org
 > http://lists.osgeo.org/mailman/listinfo/gdal-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150330/7dcc2e3e/attachment.html>