[gdal-dev] GeoTiff writer refuses to set 42113 (NoData) from Python

[jratike80]

Hi,

There is a common belief that problems with images happen only with exactly
that confidential multigigabyte image that user is playing with. That is
uncommon and usually the problem can be repeated with any other image with
similar structure. 

If you have GDAL v. 3.2 you can use
https://gdal.org/programs/gdal_create.html for sharing test data. Usage
example:

gdal_create -outsize 500 500 -burn 255 -burn 0 -burn 0 -if p4433h.tif
create.tif

The command creates a 500x500 pixel sized image that has the same
projection, bit depth etc. than the original "p4433h.tif" but all the pixels
are filled with red (this was a RGB image). Now there is no secrets to be
seen in the image. If the location is secret, assign fake ullr coordinates.
If even SRS is sectet you can change even that.

It is also possible to do quite a lot with python and nobody can say by your
description what goes wrong. Add so much of Python that others can just
copy, paste, and run the code, and together with the test image it produces
the error. Just as with the image, do not show all your code. Simplify it
into minimum to show the error.

-Jukka Rahkonen-



Dustin Sims wrote
> Hey devs,
> 
> I have an issue where writing any GeoTiff from python results in
> 
> ERROR 1: TIFFSetField:Path/To/File: Unknown tag 42113
> 
> This happens regardless of warp or translate (the only two applicable
> tools for my use case)
> 
> However, running this through the CLI tools with the exact same inputs
> results in the NoDataValue being preserved, and no matching error output.
> While I can use subprocess tools to run the CLI tool through python, I
> would very much prefer to use gdal.Warp() and the like.
> 
> I am unable to provide sample data, due to it being confidential. If I use
> gdal.Warp() or gdal.BuildVRT() to convert the input file to VRT, the
> NoData is preserved. Translating that to a GeoTiff  results in the above
> error and NoData is lost. Seems really strange that I am unable to write
> tag 42113, as that is one of the GDAL specific tags. Anyone have any
> advice on what I could do to resolve this?
> 
> GDAL version 3.2.1
> GDAL-python 3.2.1
> 
> _______________________________________________
> gdal-dev mailing list

> gdal-dev at .osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html