[OSM-dev] Altitude data & (cycle) route profiles
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
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
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
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