When running gdalinfo on an SRTM file, I get the corner coordinates. However, when I attempt to get the elevation at those coordinates using gdallocationinfo -wgs84 file.hgt {corner coordinates} I get that they are off the file, why is this? It seems to me that if I got the extents I should be able to query those points for their corresponding elevation. How would I go about getting the inclusive corner coordinates?
-
2Bring the coordinates in by up to half a cell. Rounding may place them just off the raster when resolving world to cell. Or optionally use row, column addressing from 0,0 to nCols, nRows.– Michael StimsonCommented Mar 28, 2017 at 0:58
-
I understand that I can add/subtract half the pixel width to get bounds within the cell, but I am curious about what are the true limits of the raster are. How do I know, within the nearest machine precision, what the box limits are?– user985030Commented Mar 30, 2017 at 17:11
-
The bounding box is the limits, the outer edge of the cells, because you're using the limits of the file to query the pixels rounding will often resolve the 'world' coordinates to rows and columns that aren't on the raster. Internally the tool must convert a world coordinate to a row/column address on the raster to locate the pixels; all pixel operations to the raster dataset are made on row/col address, so addressing using 0,0 (top left) to nCols-1, nRows-1 (lower right) is the better way to address the corner points of a raster as world coords are converted and you avoid any ambiguity.– Michael StimsonCommented Mar 30, 2017 at 21:14
Add a comment
|