- Messages
- 1,510
- Country
On "PixelIsPoint=X"
I've always been unclear on that SDK example, my question is "what does this square represent?" (the red area)
If that square represents the entire source .tif (say a 10000 x 10000px .tif) then yeah, pixelispoint=? is a big deal because it means the NW corner as called out in the .inf wouldn't be the NW corner at all but rather the center of the source. In that case using the wrong pixelispoint value could misplace your photoreal/mesh/etc. by a degree or more in longitude and latitide depending on the size and resolution of your source.
If the red square represents the first pixel in the NW corner of your source .tif then we're talking about a discrepancy of half a pixel max and whether the value in the .inf is 1 or 0 would be insignificant with the possible exception being a 256 x 256px .raw file that you were using to resample landclass, waterclass, seasons, population density, etc.
When I do gdalinfo on a .tif I've reprojected and then use GeoTiffToInf to generate an .inf I find that ulxMap and ulyMap from the .inf match the upper left corner coordinates from the gdalinfo report. That's with PixelIsPoint=0. What happens if I then change PixelIsPoint=0 to PixelIsPoint=1 and resample it again? Here's what I found:
That's the NW corner of two .bgls overlayed in TMFViewer, one resampled with PixelIsPoint=0 and the other resampled with PixelIsPoint=1 and highly zoomed in. The semi-transparent row of pixels across the top is the difference in their positioning, PixelIsPoint=1 appears to have shifted the .bgl one pixel northward. (I would have expected a shift of 1/2 pixel northward and 1/2 pixel westward but maybe we're only working in whole pixels here?) My conclusion is that the red square in the first image represents the first pixel in the NW corner of the source .tif rather than the source .tif in it's entirety, and on a source larger than 10px in either direction the value of PixelIsPoint=X is completely insignificant for our purposes.
Am I missing something?
I've always been unclear on that SDK example, my question is "what does this square represent?" (the red area)
If that square represents the entire source .tif (say a 10000 x 10000px .tif) then yeah, pixelispoint=? is a big deal because it means the NW corner as called out in the .inf wouldn't be the NW corner at all but rather the center of the source. In that case using the wrong pixelispoint value could misplace your photoreal/mesh/etc. by a degree or more in longitude and latitide depending on the size and resolution of your source.
If the red square represents the first pixel in the NW corner of your source .tif then we're talking about a discrepancy of half a pixel max and whether the value in the .inf is 1 or 0 would be insignificant with the possible exception being a 256 x 256px .raw file that you were using to resample landclass, waterclass, seasons, population density, etc.
When I do gdalinfo on a .tif I've reprojected and then use GeoTiffToInf to generate an .inf I find that ulxMap and ulyMap from the .inf match the upper left corner coordinates from the gdalinfo report. That's with PixelIsPoint=0. What happens if I then change PixelIsPoint=0 to PixelIsPoint=1 and resample it again? Here's what I found:
That's the NW corner of two .bgls overlayed in TMFViewer, one resampled with PixelIsPoint=0 and the other resampled with PixelIsPoint=1 and highly zoomed in. The semi-transparent row of pixels across the top is the difference in their positioning, PixelIsPoint=1 appears to have shifted the .bgl one pixel northward. (I would have expected a shift of 1/2 pixel northward and 1/2 pixel westward but maybe we're only working in whole pixels here?) My conclusion is that the red square in the first image represents the first pixel in the NW corner of the source .tif rather than the source .tif in it's entirety, and on a source larger than 10px in either direction the value of PixelIsPoint=X is completely insignificant for our purposes.
Am I missing something?