<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    On 29/03/15 23:58, Robert Coup wrote:<br>
    <span style="white-space: pre;">> Hi,<br>
      ><br>
      > Good work, thanks for taking this on!</span><br>
    <br>
    Yes, this will be very useful!<br>
    <br>
    <span style="white-space: pre;">> 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</span><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>
    <span style="white-space: pre;">> 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? </span><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>
    <span style="white-space: pre;">> 3: Keen to see the ogrinfo
      equivalent!</span><br>
    <br>
    Agreed!<br>
    <br>
    <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": [<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>
    <span style="white-space: pre;">><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></span><br>
    <br>
    <br>
  </body>
</html>