Does a value in srtm dem file refer to the center or corner of a cell?

Question

I'm working with srtm dem files. They are ascii text files containing a table/grid of elevation values. At the top of the file is some metadata to locate the grid in lat/lon:

xllcorner -124.00041606132

yllcorner 48.999583599682

cellsize 0.00083333333333333

So initially I thought of the cells as points and assumed that the first value in the grid was the elevation for a point located at (xllcorner, yllcorner), and that the second value in the grid was the elevation at (xllcorner + cellsize, yllcorner). I then used this data to draw a 3d mesh with the mesh vertices corresponding to cells in the grid.

The resulting mesh looks correct but now I'm wondering if it's out by (cellsize / 2) in lat and lon...

When I started working with the file using Postgis Raster I discovered that it considers each cell as a polygon rather than a point. Rather than the first value representing the elevation for the point (xllcorner, yllcorner) it actually represents the the elevation for the polygon (xllcorner, yllcorner, xllcorner + cellsize, yllcorner + cellsize).

So, with that in mind, and seeing that I need to map each elevation to a point. Is it more accurate to say that the first value in the grid represents the elevation at (xllcorner, yllcorner) or at (xllcorner + cellsize / 2, yllcorner + cellsize / 2)?

Answer 1

Here's what the original NASA's SRTM document says (emphasis is mine):

File names refer to the latitude and longitude of the lower left corner of the tile - e.g. N37W105 has its lower left corner at 37 degrees north latitude and 105 degrees west longitude. To be more exact, these coordinates refer to the geometric center of the lower left pixel, which in the case of SRTM3 data will be about 90 meters in extent.

What you have is an ASCII grid file. I've seen two types of these: one type defines the grid using xllcorner/yllcorner, the other using xllcenter/yllcenter, but both are essentially the same.

So, with that in mind, and seeing that I need to map each elevation to a point. Is it more accurate to say that the first value in the grid represents the elevation at (xllcorner, yllcorner) or at (xllcorner + cellsize / 2, yllcorner + cellsize / 2)?

SRTM height represents the (average) height of all points within the cell, which has a bounding box (xllcorner, yllcorner, xllcorner + cellsize, yllcorner + cellsize). The center of that cell is xllcorner + cellsize/2, yllcorner + cellsize/2. So, basically, the answer to your question is: use the center of the cell to represent the height point.

I would also suggest running some TIN simplification algorithm on your mesh to reduce its size, that's what I did for my project.

Answer 2

I think it depends on your SRTM source, but if you have the original SRTM1 .hgt files, then you should read the Documentation.

I think this part (from Section 3.0) answers your quesion:

The names of individual data tiles refer to the longitude and latitude of the lower-left (southwest) corner of the tile (this follows the DTED convention as opposed to the GTOPO30 standard). For example, the coordinates of the lower-left corner of tile N40W118 are 40 degrees north latitude and 118 degrees west longitude. To be more exact, these coordinates refer to the geometric center of the lower left pixel...

Answer 3

I don't know the answer, because it may depend on the source of your data and any processing steps that have been applied to it, but there is a reliable way that you can find out:

1. Notice that the cellsize of 0.00083333333333333 equals 1/1200 (degree) = 1/20 minute = 3 arc seconds, as advertised. Let's call this c.

2. The lower left coordinates equal (-124 - c/2, 49 - c/2).

We might guess that the cell centers have been arranged to start exactly at an origin of (-124, 49), so that the lower left coordinate is for the lower left corner of the grid. To check, count the number of rows (m) and columns (n). The upper right coordinates will equal (-124 - c/2 + n*c, 49 - c/2 + m*c). Compare these to what you expect the upper right coordinates to be (often they are chosen to be a nice fraction of a whole degree). If these also are c/2 more than the expected values, that would confirm the supposition that the center of the cell in row i (counting up from the bottom starting at row 1) and column j (counting from the left starting at column 1) is at (-124 + (i-1)*c, 49 + (j-1)*c). For example, if m = 601 and n = 1201 (notice these are 1 greater than nice fractions of 1200), then -124 - c/2 + n*c = -123 + c/2 and 49 - c/2 + m*c = 49.50 + c/2, spilling over a beautiful endpoint at (-123, 49.50) by exactly half a cell in both directions. The latter would be the center coordinates of the upper right cell.

Why is this important? Well, because one degree of latitude is approximately 111 km and one degree of longitude (at this latitude) is approximately 73 km, mistaking the cell corners for centers makes a systematic error of 1/2400 degree in both directions, for a displacement of

sqrt((1/2400 * 111)^2 + (1/2400 * 73)^2) km
= 55 meters.

It's small but it could create a noticeable shift in overlays with other geographic datasets.

Answer 4

When talking about any DEM, it's resolution is important. SRTM has a resolution of 90 m for non US areas.

Theoretically speaking, you can't really say anything about the height variation within that pixel. So just as PostGIS rasters (or rather All Rasters), it is the value for the entire area of 90m*90m, and not for just some specific point within that square.

However, many interpolating algorithms, assume the height is for the center of the pixel, and will interpolate the heights for points in between the pixel centers.