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

[Homme Zwaagstra]

Hi,

On 29/03/15 23:58, Robert Coup wrote:
> Hi,
 >
 > Good work, thanks for taking this on!

Yes, this will be very useful!

> 2: In terms of the proposed  gdalinfo JSON...
 >
 > b) personally I'd prefer to be slightly more verbose in attribute 
naming. eg. block -> blockSize, colorInterp -> colorInterpolation, proj 
-> proj4

I agree as that will make it easier to scan through the output without 
raising
questions or needing to refer to specs. E.g. does colorInterp mean color
interpretation or interpolation?!

> 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?

Yes, it would be nice to have support (or the possibility of support) 
for the
information concerning the larger gdal data model.  This kind of high level
declarative API is really useful in covering a lot common use cases e.g. 
getting
the extent of a raster, and finding out what files define it.

The command line parseable output format interface in itself would be 
great, but
the icing on the cake would be the combination of this RFC with the GSOC 
2015
'Integration of cpp GDAL utilities into GDAL core library' exposing this 
as a
fully fledged core API.

> 3: Keen to see the ogrinfo  equivalent!

Agreed!


Regarding the JSON output, I would prefer the top level "cornerCoordinates"
property to be a GeoJSON feature collection rather than the current 
custom data
structure.  Currently it is:

{
     "cornerCoordinates": {
         "upperLeft": [
             440720.000,
             3751320.000
         ],
         "lowerLeft": [
             440720.000,
             3750120.000
         ],
         "upperRight": [
             441920.000,
             3751320.000
         ],
         "lowerRight": [
             441920.000,
             3750120.000
         ],
         "center": [
             441320.000,
             3750720.000
         ]
     }
}

I think the following would be more useful:

{ "cornerCoordinates":
   { "type": "FeatureCollection",
     "bbox": [440720.000, 3750120.000, 441920.000, 3751320.000],
     "features": [
         { "type": "Feature",
           "geometry": {"type": "Point", "coordinates": [440720.000, 
3751320.000]},
           "properties": {"position": "upperLeft"}
         },
         { "type": "Feature",
           "geometry": {"type": "Point", "coordinates": [440720.000, 
3750120.000]},
           "properties": {"position": "lowerLeft"}
         },
         { "type": "Feature",
           "geometry": {"type": "Point", "coordinates": [441920.000, 
3751320.000]},
           "properties": {"position": "upperRight"}
         },
         { "type": "Feature",
           "geometry": {"type": "Point", "coordinates": [441920.000, 
3751320.000]},
           "properties": {"position": "lowerRight"}
         },
         { "type": "Feature",
           "geometry": {"type": "Point", "coordinates": [441320.000, 
3750720.000]},
           "properties": {"position": "center"}
         }
     ]
   }
}

It is more verbose, but seeing as the output is designed for parsing, this
shouldn't be a problem.  The big plus is that it is standard, allowing 
things
like this:

     gdalinfo -json | jq '{cornerCoordinates}' | ogr2ogr extent.shp 
/vsistdin/

(jq is like sed for JSON data: see <http://stedolan.github.io/jq/>).

An added benefit is that the FeatureCollection also includes the bbox
information for easy access to the raster extent.

Best regards,

Homme

>
 > 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/a2383cdb/attachment.html>