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

Sjors Provoost sjors at sprovoost.nl
Sat Mar 29 11:14:25 GMT 2008

Hi Karl and Andy,

Thank you for your feedback.

Karl wrote:
> Why not: Use that spatial database (or the raw SRTM grid) to interpolate the elevation
> of existing way nodes and then add "ele" tags to those nodes instead of creating
> new nodes only at the grid points (and with no other information)?

In that case I will store the SRTM grid in a temporary location and
will not create the nodes. The reason I wanted these nodes is that
they are useful to have around in unexplored areas. A future version
of JOSM / Potlatch could show these points as an aid to the user. I
can write a script that adds elevation to all new nodes that do not
have elevation information.

Andy wrote:
> If I can make a suggestion it would be to think of the heights along
> each way, instead of just at nodes. If you look at the cycle map at
> http://www.gravitystorm.co.uk/osm/ you can see SRTM contours with OSM
> data overlaid. It's quite possible for a way to be straight yet cross
> a valley or a peak, and if you only look at the nodes at each end of a
> section you would miss this data. This is especially apparent for long
> straight features like motorways or roads in the USA where the gap
> between nodes can be many hundreds of metres or even kilometers, and
> the same may apply to Australia too. So instead of importing the
> heights as points and estimating the height of each node, I would
> suggest a different approach:
> * Import the SRTM data into a spatial database (i.e. postgis) as
> polylines (contours)
> * Calculate the points along the OSM way where the way intersects a contour
> * Use these points as the height data for the way

I had not thought about those long roads. I could change my approach
to solve that problem, perhaps while still using the original grid

I was thinking about adding nodes to long ways. This may sound a bit
ugly at first, but not if you consider the fact that the SRTM actually
provides real information about these points along long ways. It is
just that the latitude and longitude are not reliable, only the
altitude is.

A future reputation system should then keep in mind that lon&lat data
created by the user SRTM_Bot is not reliable, but its altitude data is
more reliable.

This may actually, as a side effect, also alleviate the problem that
in Tiles at Home some large objects spanning multiple  tiles are not

About the contour data. Do you think that this derived data could
actually be more reliable? I guess it is certainly more reliable than
the crude interpolation that I had in mind. In that case, I will add
to my proposal that I also calculate the position & altitude of nodes
based on the intersection of ways with contour lines.

Kind regards,


On Sat, Mar 29, 2008 at 12:42 AM, Karl Newman <siliconfiend at gmail.com> wrote:
> On Fri, Mar 28, 2008 at 6:32 PM, Andy Allan <gravitystorm at gmail.com> wrote:
> > 2008/3/27 Sjors Provoost <sjors at sprovoost.nl>:
> >
> > > My core objectives / deliverables are:
> > >  import SRTM data as nodes (points) in OSM, for Australia
> > > estimate the altitude of each node in Australia from the SRTM nodes
> > > display (on the fly) an altitude profile given a route (a sequence of nodes)
> > > estimate the altitude of each node in Australia from nearby GPS traces
> > >  analyze the difference between both methods

More information about the dev mailing list