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

Sean Gillies sean at mapbox.com
Mon Mar 30 07:40:18 PDT 2015


Hi all,

I recommend that JSON item names match the names of methods of the GDAL
API. If not precisely, then at least in a consistent and predictable way.
Introducing new names increases the amount of needed documentation and
generally sows confusion.

For example, Rasterio's rio-info command (you may remember me presenting
about this at FOSS4G 2014), returns JSON with items like "bounds", "res",
"shape" just like in Rasterio's API.


https://github.com/sgillies/frs-cheat-sheet/blob/master/README.md#get-raster-information

For GDAL, I agree with Rob Coup that verbose is going to be better.
"colorInterpolation" matches the GDAL API method and is going to work out
better than "colorInterp":


http://www.gdal.org/classGDALRasterBand.html#a772e1232ac07944e4c6bce3c66f98103


On Sun, Mar 29, 2015 at 4:58 PM, Robert Coup <robert.coup at koordinates.com>
wrote:

> Hi,
>
> Good work, thanks for taking this on!
>
> 1: Is there any particular reason to implement XML? Every language has a
> good JSON parser these days, as you note in the RFC XML is more complex to
> implement, and it's not like strict schemas or streaming (usual reasons for
> XML) are going to be in place.
>
> 2: In terms of the proposed gdalinfo JSON...
>
> a) bands[0].band == 1 -- any reason to favour this over the implicit index
> in the bands[] array?
>
> b) personally I'd prefer to be slightly more verbose in attribute naming.
> eg. block -> blockSize, colorInterp -> colorInterpolation, proj -> proj4
>
> c) There's support for multiple RATs in a single dataset, but the JSON
> format only allows one. Maybe rats: {"name": {... attributes...}}?
>
> d) HDF-derived formats (and probably some others) have support for
> multiple datasets/component images. Is that something we could incorporate
> (maybe with a top-level object surrounding each dataset description)?
>
> There may be a few other elements where there's support (either now or in
> the forseeable future) for multiple items. @Even, any thoughts?
>
> 3: Keen to see the ogrinfo equivalent!
>
> Rob :)
>
> _______________________________________________
> 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/dced372b/attachment.html>


More information about the gdal-dev mailing list