Roger André wrote:
Morning,
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,
"Metadata: AREA_OR_POINT=Area"
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:
-0.0000000000, 8.0000000033
- 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
parallels.
Roger,
I don't see a problem with the data. It appears to have edge pixels
that are properly centered on the lat/long grid points. It does imply
a single row/column of overlap with adjacent grid squares but I believe
that is typical of distributed SRTM data.
What, specifically, in the above seems wrong to you?
Where we do often have contentious debates is when a raster is marked
as PixelIsPoint. In this case there is arguments about how it ought
to be represented by GDAL and there are often complaints that the
approach taken is off by half a pixel. I think it would be much easier
if everyone in the world just distributed data in pixelisarea mode - no
risk of confusion and error.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [email protected]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
