The file is indeed fine and was recognized in earlier GDAL versions (<=
3.4). Bug fixed per https://github.com/OSGeo/gdal/pull/7382
Le 08/03/2023 à 14:22, Micha Silver a écrit :
Inline...
On 08/03/2023 14:33, Even Rouault wrote:
Ah, the issue here is that the GeoTIFF keys in the .tif part
Inline...
On 08/03/2023 14:33, Even Rouault
wrote:
Ah, the issue here is that the GeoTIFF keys in the .tif
partially define the projection (or possibly the .tif.aux.xml
contain this invalid WKT). But METHOD["unnamed"] means that
Ah, the issue here is that the GeoTIFF keys in the .tif partially define
the projection (or possibly the .tif.aux.xml contain this invalid WKT).
But METHOD["unnamed"] means that the projection method is unknown, so it
is logical that GDAL/PROJ can't compute geographic coordinates from
projected
Hi Even:
Here's the
full gdalinfo, with the reported CRS:
gdalinfo
HiBar_21022022_A1.tif
Driver: GTiff/GeoTIFF
Files: HiBar_21022022_A1.tif
HiBar_21022022_A1.tif.aux.xml
gdalinfo is usually showing the coordinates of the corners and center in
the CRS of the GeoTIFF, and also in WGS84 in degrees as conversion of the
previous. Looks like your CRS does not support such conversion.
If you paste the full output of gdalinfo there should be some clues about
the CRS used.
Micha,
which CRS is reported and which PROJ version do you use ? It is
presumably one projection method for which PROJ only implements the
forward conversion, that is from geographic to projected coordinates,
but not the reverse way
Even
Le 08/03/2023 à 09:37, Micha Silver a écrit :
I
I received some Geotiff files, and gdalinfo shows:
Corner
Coordinates:
ERROR 1: No inverse operation
Upper Left ( 205370.241, 418790.721)
ERROR 1: No inverse operation
Lower Left ( 205370.241, 4156
