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:
And here is the information from the resulting output tiff file after the Raster Calculator operation:
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?
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
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.
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...
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.
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.