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
> [email protected]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
