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

Sjors Provoost sjors at sprovoost.nl
Sun Apr 6 22:54:04 BST 2008


Hello again,

As I promised I completely got rid of the idea to actually add
altitude data to OSM nodes. My new proposal does not touch the OSM
database and renders in real time. Here is the summary followed by
some more details from the proposal.

My core objectives / deliverables are:
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)

Secondary goals, if time permits:
6 - scale up to the whole planet
7 - write algorithm to estimate the height of any given coordinate
(server side), using intersection with contours
8 - optimize performance for short and/or long routes
9 - do drawing client side

Tertiary goal (really cool, but probably no time):
10 - allow profiles to be calculated on a different server (using as
little OSM data as needed)

In more detail:

I will define a route as any sequence of nodes. This sequence will be
the input for the profile. This input could come from a future route
planner. I will not create this planner, so I will create some example
routes as a demonstration.

Given a route, there are multiple ways to calculate an altitude profile.

1 - using the original SRTM grid
2 - using the contour lines generated by Srtm2Osm

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

I will iterate over each node of the route and consider several SRTM
points around it. The altitude of a node is then given by
interpolation. Depending on performance, I can use more surrounding
SRTM points or a more sophisticated form of interpolation.

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.

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

To visualize a route I will create a separate rails controller and
view. The input will be an array of current_node id's.

The profile will be an array of (x,y) coordinates, one for each point
along a route, where x is the distance from the origin, via the path
and y is the altitude of each point. A point could be a node or any
other point along a way.

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.

In order not to overload the main OSM server with features, I will try
to make this as modular as possible. If time permits (all the way to
the bottom of my list), I will allow the website to access a separate
server for the altitude data. That separate server can use a stripped
down version of the OSM database to improve its performance. I have
actually never let a website use two different servers and I am not
even sure if it is possible. One way would be to let the client talk
to two servers. The other would be to let the main server talk to the
secondary server and pass the result to the client.

I hope you like this proposal better. If not, I still have a day to
fix it. Thanks for all the feedback so far and for being clear on your
point of view.

Kind regards,

Sjors




More information about the dev mailing list