Skip to main content

We have many geotiff files that have NoData Value specified or calculated in ArcGIS. Is there a way in FME to retrieve the NoData Value from the tiff's property?

@aguan​ RasterBandPropertyExtractor should return the no data value on each band in your raster


@aguan​ RasterBandPropertyExtractor should return the no data value on each band in your raster

@markatsafe, yes it is. I have two single band rasters. One has NoData value of 15, and the other is empty. The transformer retrieves the 15 from the first raster, but gives 2 for the second, which is strange. If I calculate the value for the second one in ArcGIS Pro, it gives a value of 16. Then the FME also gives the 16. So my question is why it gives 2 if NoData value is initially empty?


@markatsafe, yes it is. I have two single band rasters. One has NoData value of 15, and the other is empty. The transformer retrieves the 15 from the first raster, but gives 2 for the second, which is strange. If I calculate the value for the second one in ArcGIS Pro, it gives a value of 16. Then the FME also gives the 16. So my question is why it gives 2 if NoData value is initially empty?

@aguan​  If you can attach the problem raster or file a support case with your local FME Support provider then someone would be able to take a look.


@markatsafe, yes it is. I have two single band rasters. One has NoData value of 15, and the other is empty. The transformer retrieves the 15 from the first raster, but gives 2 for the second, which is strange. If I calculate the value for the second one in ArcGIS Pro, it gives a value of 16. Then the FME also gives the 16. So my question is why it gives 2 if NoData value is initially empty?

@markatsafe, see attached tif zip file. The NoData property is empty. I ran the RasterBandPropertyExtractor on it, it gave NoData value of 2.


@markatsafe, yes it is. I have two single band rasters. One has NoData value of 15, and the other is empty. The transformer retrieves the 15 from the first raster, but gives 2 for the second, which is strange. If I calculate the value for the second one in ArcGIS Pro, it gives a value of 16. Then the FME also gives the 16. So my question is why it gives 2 if NoData value is initially empty?

Inspect the tiff you just uploaded. You will see that it has Nodata Value: 2 set on Band 0 (GRAY8) and the _band{0}.band_nodata attribute extracted via RasterBandPropertyExtractor is 2.

I also connected a Raster Statistics Calculator, .min and .max are 0 and 9. So I don't know where you get the 16 from.


@markatsafe, yes it is. I have two single band rasters. One has NoData value of 15, and the other is empty. The transformer retrieves the 15 from the first raster, but gives 2 for the second, which is strange. If I calculate the value for the second one in ArcGIS Pro, it gives a value of 16. Then the FME also gives the 16. So my question is why it gives 2 if NoData value is initially empty?

@caracadrian​ @Mark Stoakes​ I probably did not make my issue clear. I am attaching he screen captures of the NoData value property of this raster in ArcGIS Pro. Initially it is empty, but FME RasterBandPropertyExtractor gives 2. In Pro, using the NoData Editor compute gives a value of 16, and then FME RasterBandPropertyExtractor gives 16 too. I don't care how Pro gives 16. When Pro calculates stats, it ignores NoData value, so the NoData value can be totally outside the (min,max). My concerns is why FME gives 2 while ArcGIS Pro shows it is empty. I would hope FME gives a null NoData value too.


@aguan​ FME reads the nodata value from the TIFF image file = 2 . Esri reads the nodata value from the .tif.xml, which in this case is 15 - <NoDataValue Sync="TRUE">15</NoDataValue>


@markatsafe, ignore .tif.xml. It was a manual entry in Pro's metadata editor. I should not have sent it in the zip file to confuse you. Anyway, I am not worry about now. We have decided not to use FME to read NoData Value property of the tif file, but manually enter it in the metadata editor, and export it to .tif.xml file and retrieve it from there.


Reply