Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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)?

share|improve this question

4 Answers 4

up vote 2 down vote accepted

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.

share|improve this answer
1  
Thanks. Your second-to-last paragraph answers the question exactly as it describes the meaning of xllcorner/yllcorner rather than the meaning of the filename (which is also useful but wasn't my question). Anyone else with this question should note that the excerpt from Nasa's documentation (first quote above) explains the meaning of the filename not xllcorner/yllcorner. I also think the link to the ASCII grid file on wikipedia is the most relevant reference for anyone else who has this same question. –  Bruce Jul 29 '12 at 4:55

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.

share|improve this answer
    
Thanks, you're right, (xllcorner, yllcorner) is ALMOST exactly half a cellsize off from being on an exact degree. –  Bruce Jul 29 '12 at 4:45

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...

share|improve this answer
    
Thanks very much for that link, I thought the format should be documented somewhere but didn't know where to look. This explains it pretty well. It's interesting to note that "To be more exact, these coordinates refer to the geometric center of the lower left pixel" - indicates that the filename references the center of the lower left pixel. I think though that the xllcorner and yllcorner fields in side the file represent the lower left corner of the lower left tile though. Thanks! –  Bruce Jul 29 '12 at 4:42

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.

share|improve this answer
    
This is all correct, but I don't think it answers the question. At the end of the day, the software assigns coordinates to each cell. In this particular SRTM DEM, what then are the coordinates of the lower left cell? –  whuber Jul 27 '12 at 14:05
    
@whuber It is possible, that I misunderstood the question. I thought the question was about, the height value of the pixel; If the OP wants to know about the (x,y) coordinates of the pixel, then the answer gis.stackexchange.com/a/30463/442 is more appropriate. –  Devdatta Tengshe Jul 28 '12 at 4:07
    
Thanks this does give some context, given that a cell represents the average height for all records in that polygon then the most accurate way for me to generate a point from each pixel is to treat the value as the elevation at the centroid. –  Bruce Jul 29 '12 at 4:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.