[OSM-dev] Altitude data & (cycle) route profiles

Steve Hill steve at nexusuk.org
Mon Apr 7 10:05:05 BST 2008


On Sun, 6 Apr 2008, Sjors Provoost wrote:

> 1 - import SRTM data for (part of) Australia
> 2 - write several algorithms to estimate the height of any given
> coordinate (server side), using original STRM grid
> 3 - display (on the fly) an altitude profile given a route (a sequence
> of nodes). Drawing done server side.
> 5 - integrate with the main website (on a dev server)

This sounds good to me.  I'd also suggest considering implementing an API 
for clients to get at the SRTM altitude data.  Ideas that spring to mind 
are:
1. A simplistic solution: clients can request the elevation at a given 
lat/lon and the server returns the interpolated elevation.
2. Slightly more complex: clients can supply two lat/lon tuples and the 
server returns a list of elevations along the line between them.
3. Even more complex: as with (2) but return the data as bezier (or 
similar) curves.

You're going to need to be able to generate this data anyway, so making it 
accessible via an HTTP API should be quite trivial.

> For method 1 I will write a ruby script that imports the SRTM data and
> will use the source code of SRTM for inspiration.

Where are you going to import it to?  Consider using PostGIS since this 
will allow spacial referencing of the data (but you may need to experi

> For long straight roads there is another problem: a road may go up and
> down several times between two consecutive nodes. I will calculate the
> altitude along several extra points along this way, although this may
> not be very accurate.

Generating parametric curves (as mentioned above) or the line between 2 
points would probably be the best way of attacking this problem.

> For method 2 I will calculate the intersection of each way with an
> altitude contour. This method does not suffer from the
> long-straight-road problem.

I'm not sure why this doesn't suffer from the same problem - the only 
issue I can see with ways that have very sparse nodes is that long 
straight sections may, in fact, not be straight in the real world (which 
there is nothing you can do about - the results are only as accurate as 
the source data).

> I think that method 2 will be more difficult to implement and require
> much more data and processing power. That's why I moved it to the
> secondary goals. If it turns out method 1 is resource intense and/or
> good enough, I will skip method 2.

I posted some estimated figures for storing the entire SRTM3 data set as 
10m contours in PostGIS a while ago - about half a terabyte.  I think your 
best option is to stick with the raw grid and write a system to generate 
parametric curves of elevation for arbitrary vectors across it on-the-fly.

> Initially I would like to use Gnuplot for the visualization, because
> it is simple to use. However, if time permits, I would like to
> generate the profile plot client side and more fancy. The client will
> simply receive a list of (x,y) coordinates from the server.

ISTR seeing a PHP library for generating graphs as SVG images - can't 
remember what it was called but something like that may be helpful.

> That separate server can use a stripped
> down version of the OSM database to improve its performance.

This server doesn't really need the OSM database at all - instead of 
sending a list of node IDs to the server, you can just send it a list of 
lat/lon tuples.

  - Steve
    xmpp:steve at nexusuk.org   sip:steve at nexusuk.org   http://www.nexusuk.org/

      Servatis a periculum, servatis a maleficum - Whisper, Evanescence





More information about the dev mailing list