<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello,<br>
<br>
On 30/03/15 10:20, Even Rouault wrote:<br>
<br>
<span style="white-space: pre;">> Homme's comments :<br>
><br>
>> Yes, it would be nice to have support (or the possibility
of support) <br>
>> 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. <br>
><br>
> Not sure what other information you're thinking of ? Faza's
proposal covers <br>
> pretty much everything available on the raster side AFAICS.</span><br>
<br>
No specific information, just a general statement applied to Roberts
last three<br>
points to make the JSON accessible information as comprehensive as
possible! I<br>
agree that Faza's proposal combined with your suggestions makes for
a very<br>
complete and useful feature set: I have a number of custom scripts
and tools<br>
that I can't wait to simplify with this new functionality.<br>
<br>
<span style="white-space: pre;">><br>
>> The command line parseable output format interface in
itself would be <br>
>> great, but<br>
>> the icing on the cake would be the combination of this
RFC with the GSOC <br>
>> 2015<br>
>> 'Integration of cpp GDAL utilities into GDAL core
library' exposing this <br>
>> as a<br>
>> fully fledged core API.<br>
><br>
> Faza is applying for this subject ;-)<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 <br>
>> custom data<br>
>> structure<br>
>> In this way you can be <br>
>> 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>
> +1, although latests Jukka's arguments make sense too...<br>
><br>
> One thing to be aware of is that the wgs84 object might not
always be there, <br>
> in case there's no projection information, or in case of
inconsistent <br>
> projection + geotransform which make transformation to WGS84
coordinates <br>
> invalid. Actually there are cases where reprojection to WGS84
doesn't make any <br>
> sense at all: consider a PDS, ISIS or VICAR dataset of a Moon
or Mars image <br>
> (but I think that currently you could reproject them to WGS84
ironically since <br>
> neither OGRSpatialReference or proj.4 will realize you're
dealing with <br>
> different planets!).<br>
><br>
> Other remark: in the current gdalinfo report,<br>
><br>
> Upper Left ( 397335.000, 3877407.000) (100d 7'31.87"W, 35d
2' 2.87"N)<br>
> Lower Left ( 397335.000, 3865044.000) (100d 7'26.38"W,
34d55'21.61"N)<br>
> Upper Right ( 411627.000, 3877407.000) ( 99d58' 7.88"W, 35d
2' 7.74"N)<br>
> Lower Right ( 411627.000, 3865044.000) ( 99d58' 3.16"W,
34d55'26.46"N)<br>
> Center ( 404481.000, 3871225.500) (100d 2'47.32"W,
34d58'44.76"N)<br>
><br>
> the long/lat coordinates displayed are *not* necessarily
WGS84. They are in <br>
> the geographic coordinate system of the projected coordinate
systems, so if <br>
> you've a NAD27 UTM PCS, there will be in NAD27 long/lat (so
in the case of my <br>
> Mars images, the coordinates actually make sense since they
are expressed in a <br>
> Mars datum).</span><br>
<br>
Ok, I wasn't aware that Jukka's can of worms was on such a cosmic
scale!<br>
<br>
<span style="white-space: pre;">> I'm not sure how usefull a
FeatureCollection of Feature corners is. My latest <br>
> thinking would be to keep Faza's proposal of having a
"cornerCoordinates" <br>
> object (in native coordinate system), and add a side
"wgs84Extent" object (not <br>
> always there for above reasons), which would be GeoJSON
feature with a Polygon <br>
> geometry (each 4 corners projected to WGS84) :<br>
><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>
> "wgs84Extent": {<br>
> "type": "Feature",<br>
> "bbox": [2.0.5, 49.1, 2.8, 50.0],<br>
> "geometry": {<br>
> "type": "Polygon",<br>
> "coordinates": [<br>
> [ 2.1, 49.1 ],<br>
> [ 2.05, 50.0 ],<br>
> [ 2.8, 49.9 ],<br>
> [ 2.15, 49.15 ],<br>
> [ 2.1, 49.1 ]<br>
> ]<br>
> },<br>
> "properties": []<br>
> } <br>
> ....<br>
> }<br>
></span><br>
<br>
Yes, having the cornerCorner coordinates as a polygon would be fine
too (you<br>
only give up the ability to extract the center coordinate using
geojson).<br>
However it would be a shame not to have geojson access, whether by
points or<br>
polygons, to coordinates from files where, as Jukka says, the CRS
information<br>
may be missing or untransformable (which I believe in the above
would mean that<br>
there is no wgs84Extent).<br>
<br>
I understand that GeoJSON is usually represented as epsg:4326 (and
in the future<br>
'must' be!), but from a practical point of view I just find it
easier to make<br>
use of coordinates in geojson format (whatever the CRS), rather than
massaging<br>
custom (if admittedly simple) data structures into a usable format.
It's a<br>
small thing but lots of small things added up make a big difference
:)<br>
<br>
I suggested a FeatureCollection as you can embed the position (e.g.
upperLeft)<br>
as an attribute, but you could also adapt Fazam's original proposal
to point to<br>
a GeoJSON Geometry rather than a coordinate array e.g:<br>
<br>
{<br>
...<br>
"cornerCoordinates": {<br>
"upperLeft": {"type": "Point", "coordinates": [440720.000,
3751320.000]},<br>
...<br>
},<br>
...<br>
}<br>
<br>
<span style="white-space: pre;">> ~~~~~<br>
><br>
> My own remark/question: With the preliminary implementation
work done by Faza <br>
> ( <br>
>
<a class="moz-txt-link-freetext" href="https://github.com/fazam/gdal/commit/34c25e01d014ab18f8842ce7c9bca1142915af69#commitcomment-10458670">https://github.com/fazam/gdal/commit/34c25e01d014ab18f8842ce7c9bca1142915af69#commitcomment-10458670</a>
<br>
> ), which follows closely the current logic of gdalinfo, some
objects might not <br>
> always be there in the output. For example "gcps" will not be
there if there <br>
> are no GCPs (and if -nogcps if passed, but in which case
that's expected). <br>
> Same for "unit", "offset", "scale", "rat", "colorTable",
"histogram" ...<br>
> Is that something acceptable ? I think it might be OK but we
must add a <br>
> foreword sentence mentionning that some objects might not be
present depending <br>
> on the dataset characteristics and options passed to
gdalinfo.</span><br>
<br>
My only comment would be to differentiate between a property that
has<br>
specifically been requested but is not available, and an optional<br>
argument. E.g. if -nogcps is passed then it would make sense if the
"gcps"<br>
property didn't exist in the JSON, but if it was not passed and
there were still<br>
no gcps, then the JSON should be { "gcps": null }. I am not
familiar with the<br>
code but it looks like this may already be the case?<br>
<br>
Best regards,<br>
<br>
Homme<br>
<br>
<span style="white-space: pre;">> Even<br>
></span><br>
<br>
</body>
</html>