[OSM-dev] SoC Project: Preprocessor to add altitude information to OSM data
kenn at wifi-bourgogne.com
Thu Apr 9 12:15:39 BST 2009
I think this project is interesting. It would seem that while it is a
problem when users create and destroy nodes, this doesn't have to be
critical. Obviously, the altitude information should not be associated
to the node, as these can be moved by users, but rather somewhere near
I'm working on something similar at the University of Luxembourg
(let's avoid duplication of effort!), and one of my ideas for
representing the altitude between two nodes was to do a curve fitting
for a nth order polynomial and simply store the coefficients. After
that, all you need to do is calculate a simple h=a1*x^n+a2*x^(n-1)+...
which will be quick and efficient on any platform. Moreover, if the
geometry is sufficiently simple, you can represent large swaths of
land with relatively few data. You can get even fancier and use the
fact that roads are generally planned either as constant slope or
constantly varying slope.
Of course, this isn't perfectly accurate, but for biking purposes it
can work pretty well. After all, we're not measuring the expansion of
Greenland as the ice melts and the pressure is released. +-3m should
be pretty good as a first approximation.
>You are obviously right. What do you think about this idea: Instead of
>attaching tags to a way I could find all nodes which are shared by more
>than one way and then for each part of a way between two intersection
>create a relation like this:
I think this approach is correct. In any case, this is what I've
already done at the UL. I can share code, if you have Matlab. It
outputs a quadtree file of all the intersecting nodes. I've
preprocessed the files ahead of time to remove all power lines,
boundaries, footpaths, buildings, etc.
If you don't have Matlab, it should be straightforward to port it to C.
On a somewhat related note, openstreetmap really needs to consider
having multiple file layers-- at least one for roads and one for
non-roads. On IRC, it was pointed out to me that "way" and "higway"
have specific meanings in British English, but I'm still not
convinced, and it seems that we're working ourselves into a corner
here. From my research, approximately 75% of osm data dump data in
Europe is non-road related. Since the most practical application for
openstreetmap in the near future is routing, it seems wasteful to
devote so much space to things unessential to the routing question. I
don't see power-lines, footpaths, and/or parking lot aisles (somebody
too the time to completely map a parking lot in Germany.) are POIs. As
splitting things up for the altitude integration is being taken into
consideration, it might be a good time to split OSM into multiple
On Thu, Apr 9, 2009 at 12:32 PM, Graham Jones (Physics)
<grahamjones at physics.org> wrote:
> Andy is right that the key to getting a true representation is not to just
> look at the altitude of nodes, but to integrate the SRTM data between the
> nodes to give total climb (the high tech version of counting the contour
> I think that is what Hermann was intending to do wasn't it?
>> 2009/4/9 Andy Allan <gravitystorm at gmail.com>
>>> On Wed, Apr 8, 2009 at 8:24 PM, Hermann Kraus <herm at scribus.info> wrote:
>>> > Hello!
>>> > I have applied for SoC to write an preprocessor that adds altitude data
>>> > to
>>> > ways to allow better bicycle routing, etc.
>>> > The complete application text is available at  for those of you who
>>> > don't have access to Google's mentor interface.
>>> > I'm also interested in some feedback on this point. What do the people
>>> > on
>>> > this mailinglist think about it?
>>> Hi Hermann,
>>> Sounds like your project overlaps quite a bit with Sjors from GSoC
>>> 2008 - http://wiki.openstreetmap.org/wiki/Route_altitude_profiles_SRTM
>>> So you can probably learn a lot from that - especially why looking at
>>> nodes or endpoints of ways isn't great - you miss a lot of detail
>>> (potentially entire hills!) along the way! I don't think Sjors work
>>> ever influenced routing decisions, so there's still work for you to
>>> I would suggest looking into his work, and looking at yours as an
>>> extension of what's gone before.
>>> > Regards,
>>> > Hermann
>>> >  http://r2d2.stefanm.com/soc2009/application2009_altitude.txt
>>> >  http://www.uni-r.de/
>>> > _______________________________________________
>>> > dev mailing list
>>> > dev at openstreetmap.org
>>> > http://lists.openstreetmap.org/listinfo/dev
>> Dr. Graham Jones
>> Hartlepool, UK
>> email: grahamjones139 at gmail.com
> Dr. Graham Jones
> Hartlepool, UK
> email: grahamjones139 at gmail.com
> dev mailing list
> dev at openstreetmap.org
More information about the dev