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

[Homme Zwaagstra]

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

On 30/03/15 08:16, Homme Zwaagstra wrote:
>
 > 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": [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!
 >
 >
 >         { "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
 >
 >
 >
 >
 > _______________________________________________
 > 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/ba462c28/attachment.html>