<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
P.S. on the proposal below, perhaps things could be 'standardised'
even more by<br>
including the cornerCoordinates in both wgs84 and native coordinate
systems<br>
(much like gdalinfo does at the moment). In this way you can be
guaranteed of<br>
getting geojson output in its default coordinate system. e.g.:<br>
<br>
{ "cornerCoordinates":<br>
{ "wgs84": ... GeoJSON FeatureCollection transformed to EPSG:4326
...,<br>
"native: ... GeoJSON FeatureCollection in native coordinates ...<br>
}<br>
}<br>
<br>
Best regards,<br>
<br>
Homme <br>
<br>
On 30/03/15 08:16, Homme Zwaagstra wrote:<br>
<span style="white-space: pre;">><br>
> Regarding the JSON output, I would prefer the top level
"cornerCoordinates"<br>
> property to be a GeoJSON feature collection rather than the
current custom data<br>
> structure. Currently it is:<br>
><br>
> {<br>
> "cornerCoordinates": {<br>
> "upperLeft": [<br>
> 440720.000,<br>
> 3751320.000<br>
> ],<br>
> "lowerLeft": [<br>
> 440720.000,<br>
> 3750120.000<br>
> ],<br>
> "upperRight": [<br>
> 441920.000,<br>
> 3751320.000<br>
> ],<br>
> "lowerRight": [<br>
> 441920.000,<br>
> 3750120.000<br>
> ],<br>
> "center": [<br>
> 441320.000,<br>
> 3750720.000<br>
> ]<br>
> }<br>
> }<br>
><br>
> I think the following would be more useful:<br>
><br>
> { "cornerCoordinates":<br>
> { "type": "FeatureCollection",<br>
> "bbox": [440720.000, 3750120.000, 441920.000,
3751320.000],<br>
> "features": [Hi,<br>
><br>
> On 29/03/15 23:58, Robert Coup wrote:<br>
> > Hi,<br>
> ><br>
> > Good work, thanks for taking this on!<br>
><br>
> Yes, this will be very useful!<br>
><br>
> > 2: In terms of the proposed gdalinfo JSON...<br>
> ><br>
> > b) personally I'd prefer to be slightly more verbose in
attribute naming. eg. block -> blockSize, colorInterp ->
colorInterpolation, proj -> proj4<br>
><br>
> I agree as that will make it easier to scan through the
output without raising<br>
> questions or needing to refer to specs. E.g. does colorInterp
mean color<br>
> interpretation or interpolation?!<br>
><br>
> > c) There's support for multiple RATs in a single
dataset, but the JSON format only allows one. Maybe rats: {"name":
{... attributes...}}?<br>
> ><br>
> > 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)?<br>
> ><br>
> > There may be a few other elements where there's support
(either now or in the forseeable future) for multiple items.
@Even, any thoughts?<br>
><br>
> Yes, it would be nice to have support (or the possibility of
support) for the<br>
> information concerning the larger gdal data model. This kind
of high level<br>
> declarative API is really useful in covering a lot common use
cases e.g. getting<br>
> the extent of a raster, and finding out what files define it.
<br>
><br>
> The command line parseable output format interface in itself
would be great, but<br>
> the icing on the cake would be the combination of this RFC
with the GSOC 2015<br>
> 'Integration of cpp GDAL utilities into GDAL core library'
exposing this as a<br>
> fully fledged core API.<br>
><br>
> > 3: Keen to see the ogrinfo equivalent!<br>
><br>
> Agreed!<br>
><br>
><br>
> { "type": "Feature",<br>
> "geometry": {"type": "Point", "coordinates":
[440720.000, 3751320.000]},<br>
> "properties": {"position": "upperLeft"}<br>
> },<br>
> { "type": "Feature",<br>
> "geometry": {"type": "Point", "coordinates":
[440720.000, 3750120.000]},<br>
> "properties": {"position": "lowerLeft"}<br>
> },<br>
> { "type": "Feature",<br>
> "geometry": {"type": "Point", "coordinates":
[441920.000, 3751320.000]},<br>
> "properties": {"position": "upperRight"}<br>
> },<br>
> { "type": "Feature",<br>
> "geometry": {"type": "Point", "coordinates":
[441920.000, 3751320.000]},<br>
> "properties": {"position": "lowerRight"}<br>
> },<br>
> { "type": "Feature",<br>
> "geometry": {"type": "Point", "coordinates":
[441320.000, 3750720.000]},<br>
> "properties": {"position": "center"}<br>
> }<br>
> ]<br>
> }<br>
> }<br>
><br>
> It is more verbose, but seeing as the output is designed for
parsing, this<br>
> shouldn't be a problem. The big plus is that it is standard,
allowing things<br>
> like this:<br>
><br>
> gdalinfo -json | jq '{cornerCoordinates}' | ogr2ogr
extent.shp /vsistdin/<br>
><br>
> (jq is like sed for JSON data: see
<a class="moz-txt-link-rfc2396E" href="http://stedolan.github.io/jq/"><http://stedolan.github.io/jq/></a>).<br>
><br>
> An added benefit is that the FeatureCollection also includes
the bbox<br>
> information for easy access to the raster extent.<br>
><br>
> Best regards,<br>
><br>
> Homme<br>
><br>
> ><br>
> > Rob :)<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > gdal-dev mailing list<br>
> > <a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> > <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/gdal-dev">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></span><br>
<br>
<br>
</body>
</html>