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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev