[gdal-dev] SRTM data and Pixel is area vs. Pixel is point

[Roger André]

Hi Frank,

I think the problem we're having is with this, "It does imply a single
row/column of overlap with adjacent grid squares but I believe that is
typical of distributed SRTM data."  I guess we were expecting there to
be zero overlap and for the tiles to line up edge-to-edge.

Thanks,

Roger
--

On Fri, Apr 24, 2009 at 9:59 AM, Frank Warmerdam <warmerdam at pobox.com> wrote:
> 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,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>