As I’ve already mentioned I’m interested in 3D rendering for countryside users, and am working on a couple of projects related to this: firstly, the standalone application Footnav, and secondly, I am about to start experimenting with WebGL to see how viable in-browser rendering of OSM data is currently. As part of this, I thought it would be a good idea if NASA SRTM height data could be requested in z/x/y “Google” tile format.
I have now implemented a server to do this, available through the URL http://www.free-map.org.uk/srtm/z/x/y/, e.g. http://www.free-map.org.uk/srtm/13/4079/2740/. Because a tile will contain only a section of the heights from any one .hgt file, and may in some cases contain heights from up to four .hgt files (if the tile contains a line of latitude or longitude or an intersection of two), the format of the data returned is more descriptive than in a .hgt file. Note that it is only available in the box bounded by 7W, 49N, 2E and 59N, i.e. the UK and a limited area of northern France.
The format is as follows. All values are 2-byte numbers (”unsigned shorts” for those who are familiar with C, C++, Java etc), stored in big-endian order (most significant byte first, e.g. the number 512 would be stored as 2,0; the number 2 would be stored as 0,2).
First value in the data is the resolution of the points, in terms of number of points per degree of latitude or longitude. This is always 1200, as that is the resolution in .hgt files.
Second value is the number of .hgt files used to serve this data. This is needed to interpret the rest of the file.
After these two values, there follows a data block for *each* .hgt file used to generate the data. Normally there would be just one block, but there could be two (if the requested tile spans a line of latitude or longitude) or four (if the requested tile contains a latitude/longitude intersection), or even more (if the tile is zoomed-out and contains more than one lat/lon intersection). This format may change in the future so that a seamless data block from multiple .hgt files is produced.
Each block contains the following data values:
lon lat – the longitude and latitude of the SW corner of the .hgt file used to produce this data.
index_w index_n index_e index_s – the indices of the sample points defining the west, north, east and south edges of this data block within the .hgt file, where the leftmost and topmost points would have an index of 0, and the rightmost and bottom-most an index of 1200.
Then the actual height data from the .hgt file for this block follows.
Hope this makes sense! It should make 3D browsers of OSM data showing relief much easier to code on the client side, anyhow…