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 the node.
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 layers. Best regards, Kenn Sebesta On Thu, Apr 9, 2009 at 12:32 PM, Graham Jones (Physics) <[email protected]> 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 > lines...). > > I think that is what Hermann was intending to do wasn't it? > > Graham. >> >> 2009/4/9 Andy Allan <[email protected]> >>> >>> On Wed, Apr 8, 2009 at 8:24 PM, Hermann Kraus <[email protected]> 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 [1] 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 >>> do. >>> >>> I would suggest looking into his work, and looking at yours as an >>> extension of what's gone before. >>> >>> Cheers, >>> Andy >>> >>> > Regards, >>> > >>> > Hermann >>> > >>> > >>> > [1] http://r2d2.stefanm.com/soc2009/application2009_altitude.txt >>> > [2] http://www.uni-r.de/ >>> > >>> > _______________________________________________ >>> > dev mailing list >>> > [email protected] >>> > http://lists.openstreetmap.org/listinfo/dev >>> > >> >> >> >> -- >> Dr. Graham Jones >> Hartlepool, UK >> email: [email protected] > > > > -- > Dr. Graham Jones > Hartlepool, UK > email: [email protected] > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
