Raster Calculator output GeoTiff header and tfw do not match

2402
5
10-21-2016 10:39 AM
PatIampietro
Occasional Contributor

A simple Map Algebra operation in the Raster Calculator using a GeoTiff as input and adding a constant to it should result in a new raster having the identical footprint and resolution, with only the pixel values changed by the operation.

For example:

"mydem.tif" + 34.169998

However, when this is done, whether the output is allowed to go to a temporary raster and then made permanent by using Data>Export Data and specifying TIFF format, or the Raster Calculator is explicitly set to output a tiff initially, the tfw "worldfile" created conflicts with the internal georeferencing information in the geotiff header.

The X,Y pixel size in the header and the X,Y corner coordinates of the tfw are both altered slightly.

Here is the GeoTiff header and ftw file information of an input file, with matching information:

GeoTiff header vs. tfw information of input file

And here is the information from the resulting output tiff file after the Raster Calculator operation:

GeoTiff header vs. tfw information of output file

The cell size in the header has changed by a very small amount, and the tfw corner coordinate has changed by 0.01307, or 1/2 pixel.

Anybody know why the output Tiff/Worldfile referencing is not identical to that of the input, as one would expect it should be?

0 Kudos
5 Replies
DanPatterson_Retired
MVP Emeritus

the tiny tiny difference is floating point representation (not to worry).  The half cell offset, I vaguely remember a link that some processes allow you to specify cell center vs cell bottom left when creating the output extent and i can't find it or remember which process has both options enabled.  Hopefully this triggers someone's memory

PatIampietro
Occasional Contributor

Thanks Dan,

The center-vs-corner preference setting does indeed ring a bell, but I cant recall where I've seen a place to change it. Be that as it may, if there is a way to toggle it for outputs, why do the output header and tfw information not match, if they do in the input file?

I do understand that ArcGIS will read the header info first if it exists, so as long the XY anchor info does not change there I'm fine in Arc and my outputs all line up fine with my inputs. But some software only uses the worldfile, and I'd rather not see a 1/2-pixel shift in those applications.

0 Kudos
DanPatterson_Retired
MVP Emeritus

here are a couple of references until I can nail down the lin I was looking for... at least you can produce a new world file

Export Raster World File—Help | ArcGIS for Desktop 

World files for raster datasets—Help | ArcGIS for Desktop 

In any event, it is important to not only set cell size and extent when working with rasters but when working in conjunction with other rasters... the snap raster.  If 'fixes' that cell alignment issue

Snap Raster (Environment setting)—Help | ArcGIS for Desktop 

How the Snap Raster environment setting works—Help | ArcGIS for Desktop 

Environment settings for raster data—Help | ArcGIS for Desktop 

which leaves us with the last kick at getting everything back into place

Shift—Help | ArcGIS for Desktop 

although I feel that I am still missing something...

PatIampietro
Occasional Contributor

Yup, lots of ways to export a new tfw or fix the one created, just wondering why it should be necessary.

A snap raster definitely makes sense when there are more than 1 raster input, but don't see why it should be necessary to specify the only raster input as the snap, especially given the default behavior described in the help sections you cited.

Anyway, thanks much for the time and effort spent on this quandary, much appreciated.

0 Kudos
DanPatterson_Retired
MVP Emeritus

Pat, I agree about the snap raster making sense, when more than one is involved... but I have learned what makes sense, need not be the way things work.  anyway good luck, it seems there are not other comments from the viewers, so you may want to change this to a discussion, since there is no obvious answer at present.

0 Kudos