[gdal-dev] Problem reading Sentinel-1 GeoTIFFs

[Even Rouault]

Those files use a invalid GeogEllipsoidGeoKey=4326 for the WGS 84 
ellipsoid. The correct code should be 7030. Sometimes should report that 
to the data producer.

Warning silenced in https://github.com/OSGeo/gdal/pull/4975

Le 11/12/2021 à 00:05, Simon Eves a écrit :
> After also finding this thread...
>
> https://github.com/OSGeo/gdal/issues/2321 
> <https://github.com/OSGeo/gdal/issues/2321>
>
> ...I installed geotiff-bin and ran listgeo on the file.
>
> It also spits the same message (three times).
>
> The output is attached.
>
> S
>
> On Fri, Dec 10, 2021 at 2:56 PM Simon Eves <simon.eves at omnisci.com 
> <mailto:simon.eves at omnisci.com>> wrote:
>
>     Further to my earlier post about GCP Transforms, I now have that
>     code written, and it seems to be functioning fine, although
>     whether it's generating the right values is as yet unclear.
>
>     The problem is that I am having trouble creating the secondary
>     transformation from whatever the output space of the GCP transform
>     is, to my desired space (4326 in this case).
>
>     Whenever I call GetGCPSpatialRef() on the datasource, I get the
>     following error (twice)
>
>       PROJ: proj_create_from_database: ellipsoid not found (1)
>
>     I get the same error (also twice) when I run gdalinfo on the file,
>     but then with a plausible looking SR dump, which may of course
>     just be a default:
>     ______________________________________________________
>
>     $ gdalinfo
>     s1b-iw-grd-vv-20211110t033513-20211110t033538-029520-0385e8-001.tiff
>     ERROR 1: PROJ: proj_create_from_database: ellipsoid not found
>     ERROR 1: PROJ: proj_create_from_database: ellipsoid not found
>     Driver: GTiff/GeoTIFF
>     Files:
>     s1b-iw-grd-vv-20211110t033513-20211110t033538-029520-0385e8-001.tiff
>     Size is 25541, 16650
>     GCP Projection =
>     GEOGCRS["WGS 84",
>         DATUM["World Geodetic System 1984",
>             ELLIPSOID["unnamed",6378137,298.25722356049,
>                 LENGTHUNIT["metre",1]]],
>         PRIMEM["Greenwich",0,
>             ANGLEUNIT["degree",0.0174532925199433]],
>         CS[ellipsoidal,2],
>             AXIS["geodetic latitude (Lat)",north,
>                 ORDER[1],
>                 ANGLEUNIT["degree",0.0174532925199433]],
>             AXIS["geodetic longitude (Lon)",east,
>                 ORDER[2],
>                 ANGLEUNIT["degree",0.0174532925199433]],
>         ID["EPSG",4326]]
>     Data axis to CRS axis mapping: 2,1
>     GCP[  0]: Id=1, Info=
>               (0,0) ->
>     (45.0323375081341,62.6475859336067,149.992539359257)
>     [etc.]
>     ______________________________________________________
>
>     My constructed OGRCoordinateTransformation for the second
>     transform is therefore a no-op, but the final values (which are
>     therefore just the values out of the GCP transform) are definitely
>     not 4326.
>     ______________________________________________________
>
>     omnisql> select * from s1 where rowid<10;
>     raster_lon|raster_lat
>     476788.1263799404|747980.9704571336
>     460813.8583986053|747120.1413700345
>     444852.7791957706|746184.4282221086
>     428904.8887714364|745173.8310133558
>     412970.1871256025|744088.349743776
>     397048.6742582691|742927.9844133693
>     381140.3501694361|741692.7350221358
>     365245.2148591036|740382.6015700753
>     349363.2683272713|738997.5840571877
>     333494.5105739397|737537.6824834733
>     ______________________________________________________
>
>     Those are the first ten pixels of the first scanline of the (~25K
>     x ~16K) file, btw, so intuitively there is something worrying me
>     about those values anyway (they are moving very quickly and
>     non-linearly considering that's just ten pixels).
>
>     Anyway, some Googling led me to...
>
>     https://gitlab.orfeo-toolbox.org/s1-tiling/s1tiling/-/issues/46
>     <https://gitlab.orfeo-toolbox.org/s1-tiling/s1tiling/-/issues/46>
>
>     ...which seems very related, and even mentions a patch to
>     libGeoTIFF by Even. I checked, and that patch IS in the (internal,
>     as configured in the build) GeoTIFF in our GDAL.
>
>     This is with GDAL 3.4.0 and Proj 7.2.1.
>
>     Thanks in advance,
>
>     Simon
>
>     -- 
>     <http://www.omnisci.com/>
>     	
>     Simon Eves
>     Senior Graphics Engineer, Rendering Group
>     100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
>
>
>     	
>     Email: simon.eves at omnisci.com <mailto:simon.eves at omnisci.com> |
>     Cell: 	+1 (415) 902-1996
>
>
>
>
>
> -- 
> <http://www.omnisci.com/>
> 	
> Simon Eves
> Senior Graphics Engineer, Rendering Group
> 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
>
>
> 	
> Email: simon.eves at omnisci.com <mailto:simon.eves at omnisci.com> | Cell: 
> +1 (415) 902-1996
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.

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