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

Mon Mar 30 03:35:39 PDT 2015

Hello,

On 30/03/15 10:20, Even Rouault wrote:

> Homme's comments :
 >
 >> 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.
 >
 > Not sure what other information you're thinking of ? Faza's proposal 
covers
 > pretty much everything available on the raster side AFAICS.

No specific information, just a general statement applied to Roberts 
last three
points to make the JSON accessible information as comprehensive as 
possible! I
agree that Faza's proposal combined with your suggestions makes for a very
complete and useful feature set: I have a number of custom scripts and tools
that I can't wait to simplify with this new functionality.

>
 >> 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.
 >
 > Faza is applying for this subject ;-)
 >
 >> 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
 >>  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 ...
 >>   }
 >> }
 >
 > +1, although latests Jukka's arguments make sense too...
 >
 > One thing to be aware of is that the wgs84 object might not always be 
there,
 > in case there's no projection information, or in case of inconsistent
 > projection + geotransform which make transformation to WGS84 coordinates
 > invalid. Actually there are cases where reprojection to WGS84 doesn't 
make any
 > sense at all: consider a PDS, ISIS or VICAR dataset of a Moon or Mars 
image
 > (but I think that currently you could reproject them to WGS84 
ironically since
 > neither OGRSpatialReference or proj.4 will realize you're dealing with
 > different planets!).
 >
 > Other remark: in the current gdalinfo report,
 >
 > Upper Left  (  397335.000, 3877407.000) (100d 7'31.87"W, 35d 2' 2.87"N)
 > Lower Left  (  397335.000, 3865044.000) (100d 7'26.38"W, 34d55'21.61"N)
 > Upper Right (  411627.000, 3877407.000) ( 99d58' 7.88"W, 35d 2' 7.74"N)
 > Lower Right (  411627.000, 3865044.000) ( 99d58' 3.16"W, 34d55'26.46"N)
 > Center      (  404481.000, 3871225.500) (100d 2'47.32"W, 34d58'44.76"N)
 >
 > the long/lat coordinates displayed are *not* necessarily WGS84. They 
are in
 > the geographic coordinate system of the projected coordinate systems, 
so if
 > you've a NAD27 UTM PCS, there will be in NAD27 long/lat (so in the 
case of my
 > Mars images, the coordinates actually make sense since they are 
expressed in a
 > Mars datum).

Ok, I wasn't aware that Jukka's can of worms was on such a cosmic scale!

> I'm not sure how usefull a  FeatureCollection of Feature corners is. My latest
 > thinking would be to keep Faza's proposal of having a 
"cornerCoordinates"
 > object (in native coordinate system), and add a side "wgs84Extent" 
object (not
 > always there for above reasons), which would be GeoJSON feature with 
a Polygon
 > geometry (each 4 corners projected to WGS84) :
 >
 > {
 >      ...
 >      "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
 >          ]
 >      },
 >      "wgs84Extent": {
 >         "type": "Feature",
 >         "bbox": [2.0.5, 49.1, 2.8, 50.0],
 >         "geometry": {
 >               "type": "Polygon",
 >               "coordinates": [
 >                     [ 2.1, 49.1 ],
 >                     [ 2.05, 50.0 ],
 >                     [ 2.8, 49.9 ],
 >                     [ 2.15, 49.15 ],
 >                     [ 2.1, 49.1 ]
 >                ]
 >           },
 >           "properties": []
 >       }
 >       ....
 > }
 >

Yes, having the cornerCorner coordinates as a polygon would be fine too (you
only give up the ability to extract the center coordinate using geojson).
However it would be a shame not to have geojson access, whether by points or
polygons, to coordinates from files where, as Jukka says, the CRS 
information
may be missing or untransformable (which I believe in the above would 
mean that
there is no wgs84Extent).

I understand that GeoJSON is usually represented as epsg:4326 (and in 
the future
'must' be!), but from a practical point of view I just find it easier to 
make
use of coordinates in geojson format (whatever the CRS), rather than 
massaging
custom (if admittedly simple) data structures into a usable format. It's a
small thing but lots of small things added up make a big difference :)

I suggested a FeatureCollection as you can embed the position (e.g. 
upperLeft)
as an attribute, but you could also adapt Fazam's original proposal to 
point to
a GeoJSON Geometry rather than a coordinate array e.g:

{
     ...
     "cornerCoordinates": {
         "upperLeft": {"type": "Point", "coordinates": [440720.000, 
3751320.000]},
         ...
     },
     ...
}

> ~~~~~
 >
 > My own remark/question: With the preliminary implementation work done 
by Faza
 > (
 > 
https://github.com/fazam/gdal/commit/34c25e01d014ab18f8842ce7c9bca1142915af69#commitcomment-10458670 

 > ), which follows closely the current logic of gdalinfo, some objects 
might not
 > always be there in the output. For example "gcps" will not be there 
if there
 > are no GCPs (and if -nogcps if passed, but in which case that's 
expected).
 > Same for "unit", "offset", "scale", "rat", "colorTable", "histogram" ...
 > Is that something acceptable ? I think it might be OK but we must add a
 > foreword sentence mentionning that some objects might not be present 
depending
 > on the dataset characteristics and options passed to gdalinfo.

My only comment would be to differentiate between a property that has
specifically been requested but is not available, and an optional
argument. E.g. if -nogcps is passed then it would make sense if the "gcps"
property didn't exist in the JSON, but if it was not passed and there 
were still
no gcps, then the JSON should be { "gcps": null }.  I am not familiar 
with the
code but it looks like this may already be the case?

Best regards,

Homme

> Even
 >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20150330/210b8b0e/attachment-0001.html>