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?

  • 2
    Bring 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 Stimson Mar 28 '17 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? – user985030 Mar 30 '17 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 Stimson Mar 30 '17 at 21:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.