[gdal-dev] SRTM data and Pixel is area vs. Pixel is point
randre at gmail.com
Fri Apr 24 12:12:21 EDT 2009
I have a bit of a conundrum which I'm trying to find an answer for,
and which is prompting a certain amount of contentious debate at work.
I've downloaded a 1-deg x 1-deg SRTM tile from the GLCF site,
SRTM_f03_n007e000.tif. Now from its name, this tile should have its
origin at N 7, E 0.
When I view the metadata for the tile, I see a helpful note that says,
I assume from this that the data is using "PixellsArea" Raster Space,
as defined at http://www.remotesensing.org/geotiff/spec/geotiff2.5.html.
This definition states that "The "PixelIsArea" raster grid space R,
which is the default, uses coordinates I and J, with (0,0) denoting
the upper-left corner of the image". So my guess would be that the UL
corner coordinates of this raster should be (0, 8). However, that is
not the case.
- When I run gdalinfo against the tile, I get the following info:
Upper Left ( -0.0004167, 8.0004167)
- When I create a worldfile for the tile with gdal_translate, I get
the following pixel coords reported in it:
- Also, when I create a shapefile of this tile's extents using
gdaltindex, I get the following extents reported:
Extent: (-0.000417, 6.999583) - (1.000417, 8.000417)
So my question is this, are we really all working with SRTM data that
is offset by 1/2 a pixel because of a discrepancy between
point-vs-area pixel registration? This is coming to a head for us
because we need to do some raster analysis, and we're having a really
hard time understandind why the data keeps spanning meridians and
Would appreciate any clarification or insights.
More information about the gdal-dev