Peer Pressure

Stuff to look at about looking at stuff. From Chris Dent. What?

Archive

Mar
15th
Sun
permalink

What I did on my Spring Vacation

I made raamable.

My friend Stan is going to be part of the support crew of Team Hoosiers when they once again participate in the Race Across America: a west to east cross-continental traverse of the US. On bikes.

Stan wondered about the possibility of some web based resources to help make things go. When heading across the country where every minute counts it’s good to know where you are going; what’s coming up next; weather conditions; the nearest grocery, gas, laundry, bike store.

When I was working for Socialtext most of the developers worked from home, scattered around the world. When we did get together we’d sometimes experience bursts of productivity that were very pleasant: a great sense of being in the zone. Bourbon was often involved. Intense work and intense play.

Seemed like Stan’s project was a good reason to do some good work for a good cause.

So I hunted out Matt and Zac, also former Socialtexters, and we planned a hankathon (hack and drink a thon) in Bloomington, the font of much goodness. The idea was we’d gather, mess about with some Google mashups, see what we ended up with, and see what we learned about how to have effective similar things in the future. These days it should only take a few days to establish a startup.

We made plans. Zac couldn’t come: teething baby. Down to just Matt and me. I was sick, Matt had to work, and hanging out with Stan is too rare and too fun to be wasted on staring at computers so we didn’t have the focus and concentration we originally desired. We still managed to get some things done and learn some things.

On the learning side we had some thoughts for next time:

  • Clear the decks. If you’re going to a multi-day hackathon, don’t bring other work.
  • Have a least three people. If you know exactly what you are doing, pairing or sharing work can work out very well, but if you are exploring as much as executing, an odd number keeps thinking unstable and diverse.
  • Spend the first day, half day, some unit of time brainstorming and finding the point of gravity. The group needs an articulated shared goal to have shared momentum.
  • Have a tool for keeping track of what’s up. We used a TiddlyWeb hosted tiddlywiki but didn’t initially use it all that well. Since we were in person I suspect something more tactile like a whiteboard with stickies on it might have worked better.
  • Get necessary infrastructure in place beforehand.

Despite being a bit discombobulated we did manage to create something.

Uncle Ingy says every good project starts with a good name, so I baked the name “raamable” into a git repo on github and started gathering the necessary pieces.

Since we knew we’d be working on this project separately before and after the hankathon, we’d need a convenient way to work in a test and deployed environment. Google App Engine makes that easy: do local development until you get it right and then deploy to the servers.

We had some known data sources: gps waypoints for the race, locations and frequencies of NOAA weather radio towers, a web service that gives elevation for longitude and latitude in the US.

First pass plan: put all that stuff on a google map and see what happens. There were some challenges.

It’s easy to put a bunch of markers on a map. The code shows that well enough. What’s harder, when there are several hundred markers, is plotting the line of the route on roads. Plotting a route requires using GDirections, which will only take 25 waypoints per use. Our solution was to loop over the markers in chunks of 25. The results in the map shown on the front page. The animation is a side effect of the process being somewhat slow. The darker blue spots happen where one block of 25 stops and another starts.

On the interactive map yellow markers are time stations, orange are turns on the route, and the towers mark nearby weather radio towers. Each GMarker that represents a turn has an added attribute altitude containing meters of elevation at that location. Each GMarker representing a radio has a frequency attribute.

The race route turns information did not come with elevation data. I initially planned to make the map queryable for elevation at any point (thus the /proxy URL in the app engine code) but then we decided an elevation profile image would be nice. Dynamic querying for that would be much too time consuming and barring catastrophe elevation doesn’t change much so storing it on the map seemed the way to go. For kicks I processed the route turn CSV file through a shell one liner using curl to get the elevation data and add it back into the file.

The elevation profile is a google chart that is redrawn each time the map is moved or zoomed. The crux here was to make sure that we only draw information for those markers which are within the bounds of the current view. updateProfile in the code shows how this is done.

There are many hundreds of radio towers in the continental US. We only want to show those which are near the route. There’s doesn’t seem to be a straightforward efficient way to say “plot only those waypoints which are near to this other set of waypoints” so we constructed our own. The entire route describes a rectangle that has northern and souther latitudes that can exclude most of the towers. So first we do that. The slope of the route (southwest to northeast), however, is too steep for this to be good enough: a larger number of towers are plotted which are too far away to be tuned in and make the map uselessly noisy. To deal with this an array of bounds, one containing each ten turns (plus and minus 1 degree of longitude and latitude) along the map, is created. The remaining radio tower locations are compared against the bounds. See _establishRouteCallback and _addTowersCallback.

We hope to do quite a bit more. We’re tracking our plans on the wiki. What’s running now is a useful tool but suffers one rather extreme flaw: it requires network access. We hope to modify things so that useful printouts can be made from the system and carried on the route.

This is an open source project, you are welcome to help out, use this for your own bike ride, or whatever. If you do, we’d love to hear from you.

Comments (View)
blog comments powered by Disqus