Using NASA Space Shuttle data
A couple of weeks ago I went to the bookstore and bought a couple of books with cycling routes. My main goal was to get a few ideas on how to improve my apps. Usually these types of books have 10 or 15 routes along the networks inside them, with nice descriptions of things to see and do along the route. This is something I plan to work on this year.
There were also more technical route details like the percentage of distance where you would ride on unpaved paths. But it was another technical detail that caught my eye: the route height profile. This type of profile shows the route points on the X-axis and the elevation on the Y-axes. It gives cyclists and walkers a pretty good idea of how much climbing is involved.
Looking for web services
I had a look around and found a couple free web services that could translate a gps coordinate to an elevation. The problem with these free solutions is that they often come with a rate limit, usually in the form of “you can do so many calls per hour” and “you can do so many calls per day”.
That’s a problem, because on a nice summer day my apps are used a lot. The last error you want to show your users is that you ran out of quota on a free service.
SRTM
I looked a bit further and stumbled upon Nasa’s SRTM data. SRTM stands for Shuttle Radar Topography Mission. The SRTM radar was the primary and pretty much only payload on the STS-99 mission of the Space Shuttle Endeavour, which launched February 11, 2000 and flew for 11 days.
During its flight topography data was collected for 222.4 consecutive hours. The instrument operated almost flawlessly and imaged 99.96% of the targeted landmass at least one time, 94.59% at least twice and about 50% at least three or more times. The goal was to image each terrain segment at least twice from different angles (on ascending, or north-going, and descending orbit passes) to fill in areas shadowed from the radar beam by terrain.
Flat files
This SRTM data is now publicly available as a long list of flat ascii files. For the US and its territories there is SRTM1 data available. For the rest of the world there is SRTM3 data, which is a bit less accurate, but still good enough for our purposes.
Getting the content out of these files was a bit of a hassle. I used the instructions found here. It may seem a bit overwhelming but if you follow the instructions you’ll be fine.
Each file covers an area on earth and is just under 3mb in size. I calculated the areas I would need for Belgium and The Netherlands and ended up needing 24 files. I decided to keep the calculation serverside. I don’t want to ship my apps with +70 megabytes of data in it. Also keeping it server side means more flexibility. Suppose I find a topography dataset tomorrow which is 3 times more accurate than what I have now … I can host the new data, rewrite the scripts without the need to update the app.
I wrapped the communication between the app and the backend in a nice api. The api receives the route id and the network id, so I know from which app the call is made. The backend then fetches the route, gets all the coordinates from the route and runs them all against the SRTM datafiles. The result is a json string with an elevation number for every coordinate on the route.
The app then parses this data and makes a nice graph of the height profile.
Future plans
Having a height profile for every route in my apps is a nice extra, but it’s only the first stap.
The big plan for this year is to do more with publicly available data. I would like to combine the api’s of Wikipedia, FourSquare and Flickr to show quality hotspots on user’s routes. These hotspots can be anything from buildings, bridges, tunnels, rivers, nature, breweries or places of historic significance.
I would like to integrate this deeply into the app, so users who are cycling or walking with voice guidance enabled, will be notified of these places.
I will be working on this functionality in the coming months, so there will be regular progress updates.
