Demonstration

Example altitude profileI built a simple website that displays the altitude profile for four different example routes. But you can already get the altitude profile for any route in Australia through an XML-RPC request to:
http://bak.sprovoost.nl:8000/
And then call one of the following two functions:
altitude_profile(route) : returns an xml document
altitude_profile_gchart(route) : returns a Google Chart like the one on the left.
The route argument has to look like this:

<route>
  <point id="1" lat="61.8083953857422" lon="10.8497076034546" />
  <point id="2" lat="61.9000000000000" lon="10.8600000000000" />
  <point id="3" lat="61.9000000000000" lon="10.8800000000000" />
</route>

Please be nice to my home computer and if you find any security issues, please tell me.
So what shall I focus on next?
There’s the actual profile:

  • interpolation : when two points in a route are far apart, add extra points between them
  • better altitude estimation : currently I get the altitude from the nearest SRTM data point; I will combine information from multiple points

I hope that with these changes the profiles will look a bit more smooth.
There’s performance:

  • generate lots of example routes; I created these four routes manually. I would probably need to find a way to automatically extract a whole bunch of routes from the Google route planner or something similar.
  • stress test with these routes; I want to get some idea of what kind of hardware & bandwidth requirements are involved.
  • I would really like to get my hands on the Google Apps Engine as that would outsource part of the work to Google. Two problems there: I don’t have an API key yet and I would need more storage space then they currently allow; it would be great if I could store the whole planet, but Australia already needs 123 GB.

Security:

  • Don’t know a lot about that, except that it is very important.

Looks:

  • Something a little more pretty than the Google Chart?
  • Add some ‘landmarks’, e.g. place names, road type.

Code:

  • I’m new to Python, so I want to go over my code and make things a bit nicer: refactoring.

Last but not least, how can this tool best be integrated with other websites? One scenario that I have in mind would be a third party website that uses both the OpenRouteService and my altitude profile application. A user would enter origin and destination. Then the website sends this origin and destination to OpenRouteService (through xml_rpc?), which sends the route back, both as a map figure and as an xml document. Next the website sends this route to the Altitude Profile service (through xml_rpc), which then returns the Google Chart (or an XML document). The website then displays the map and Google Chart for the user to enjoy.
There’s many ways to go from here and although I have plenty of time left for the project, I probably can’t do everything. So what would you like to see next?
Update: More information about my project can be found here.

Published By
Categorized as gsoc

12 comments

  1. The XML-RPC page says: “As new functionality was introduced, the standard evolved into what is now SOAP. (…) Some people still prefer XML-RPC to SOAP because of its simplicity, minimalism, and ease of use.”
    Did you choose XML-RPC over SOAP on purpose? Did you also consider REST?

    Reply

  3. There’s nothing wrong with KISS (the principle, not the band), but since SOAP is called XML-RPC’s successor, maybe it is interesting.
    With XML-RPC/SOAP the focus is on methods (verbs), with REST the focus is on objects (nouns). There are a couple of advantages to REST, but I’m not sure if they apply in your case. It might be nice reading about the differences. I always liked How I Explained REST to My Wife,

    Reply

  4. Interesting post! Some of the comments are also quite useful, if you manage to skip through all the replies that discuss whether or not the post should be consider sexist.
    After lots of reading, I have eventually decided (decision making gets easier when you are hungry) to attempt a REST-full approach.
    The first reason is aesthetics; I like REST because people say it is more elegant for various reasons.
    The second reason is that it is stateless, which makes it easier to host on something like the Google App Engine, which is also stateless. My intuitive guess is that if Google thinks stateless is the way to go for their massive systems, they probably had some smart people think about it. And OpenStreetMap is pretty big already and will probably become massive.
    I just found out that the Google App Engine is available for everyone now [1]. Would have been nice if they emailed people on the waiting list that piece of information.
    I am going to try to port my application to the App Engine, just using a fraction of the data to see how quickly I cross the 500 MB storage limit.
    They have also released some information about pricing. I should be able to calculate how much storing the entire SRTM data set would cost, etc.
    Fun times awaiting!
    [1] http://googleappengine.blogspot.com/

    Reply

  8. Hi Lambertus,
    I would love for you to try and use my altitude profile server. It is still in the early stages, it runs on my home computer and I have yet to do some real performance testing, but since your planner is also a work in progress, I think we can try it.
    So far, I am focusing on walking and cycle routes. I have tried a few random examples and those were less than 100 nodes. That said, we should be able to figure out a way to deal with tens of thousands of nodes.
    Perhaps, as a start, you could fetch the altitude profile only for routes with less than 500 nodes? I am reasonably confident my home computer can handle that a couple of times per minute.
    And then we need to start thinking about those bigger routes. I have a couple of thoughts here:
    * the altitude profile is only a small figure; 100 evenly spaced altitude samples is enough for any route, for most landscapes
    * my server could process a big input and pick 100 evenly spaced samples; that should seriously reduce its work load
    * sending a 30.000 waypoint route over the network only to use 100 points is a not very efficient use of bandwidth. But requiring route services to do their own filtering adds complexity.
    Let’s take it one step at a time though. Do you need any help? I am not sure which language you are using, but if there is a protocol buffer implementation for it, that would be the most efficient solution.

    Reply

  9. This is great. I’ll start working on the simplest form (only routes < 500 nodes) now. When that’s a success I will try client-side (javascript) filtering of the nodes. Test results will then determine how to proceed next. I will let you know when I’m ready.

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *