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.
First some information about me: I study physics at the University of Regensburg [2] and I'm in the 6th term. I already took part three times in SoC and completed all projects. My hobbies are computers, electronics, cycling and swimming. I could not discuss this proposal earlier, because I was very busy moving to a new house. Now that it's over I'll have more time. I got some questions about my application by Graham Jones <[email protected]> and I'll discuss then here: (Quotes are copied from his mail with permission, my replies are what I wrote him with some small corrections/additions) > The first is what to do with the data - do you envisage it going back > into > the OSM database, or straight to the routing programme? There is a > debate > to be had about where to put this data - some may not wish to 'clutter' > the > OSM database with it. The data is not meant to go into the osm database, as it would result in incorrect data soon, as the users are free to move ways around. What I can imagine is that somebody processes the planetdump each week and publishes this dump. Something similar is done with routable garmin maps. This enables everybody to use the data without having to download all SRTM tiles and without the computing power. > The other is slightly more fundamental - I agree that you can fairly > easily > calculate total climb over a way, but my question is whether that is > really > what you want? I think that most ways do not end at road junctions > (certainly not the ones I have mapped anyway), but the routing programme > will be interested in the total climb between road junctions, rather than > for the total way? 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: type=metainfo alt_difference=10.6 alt_total=27.3 distance=1032 with the way and the two intersection nodes as members. The distance is easily computed while doing the other processing. So the routing application could skip this step. > If I am right then rather then your proposal will need closer > integration with the routing programme - I think the router will > pre-process > the OSM file to calculate distance between junctions - we will want it to > include altitudes at the same time. I explicitly tried to avoid a strong integration with the routers, because we have more than one and I expect even more in the future. Creating a library might be an option, if you think my idea is not really good the other way. However I still would prefer the preprocessor option since this allows to publish planet dumps which have the altitude information. When the processing is done by the router one has to publish data for each router seperatly or the user has to download the SRTM data. I want to make this application as userfriendly as possible and what could be more userfriendly than having a world file (or excerpt of it) which already includes the altitude data. > I think your proposal to add a relation is an interesting one - it is > essentially doing the same thing as the routing program will need to do > for > distances - you can imagine doing the same to calculate distance between > junctions too, which is what the routing programs will do. I am still a > little unsure how much benefit is gained by your proposed way of doing > it, > rather than directly incorporating it into a routing program - the > routing > program(s) will need to be modified to read your new relations anyway > won't > they? > I would be inclined to suggest the two possibilities on your mailing list > post to see what the others think. Of course the router will need some support for reading the data. But it won't need support for processing SRTM data directly. I'm also interested in some feedback on this point. What do the people on this mailinglist think about it? 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
