Project link: http://ragbrai.com/data/2009/ragbrai-main-map-2009.php
HTML/Javascript development: Michael Corey
Database back-end: James E. Wilkerson
Photo upload process: Pat McCoy and Michael Corey
The Register’s Annual Great Bicycle Ride Across Iowa, or RAGBRAI, is a massive human-powered party that pedals its way across the state each July. Riders have always taken tons of photos, and for several years we’ve wanted to share as many of those photos as we can on our site.
Photos from the ride are a great example of inherently geographic data — time and place are important to the context — so we’ve also wanted to map them. In 2008 we developed a system that asked users to map their photos, but the process was clunky and we later realized we went about it backwards.
This year, we got it right, and riders have responded. We’ve simplified the photo uploading process (Pat McCoy built a photo uploader class to extend NextGEN Gallery’s uploader for Wordpres, which replaced an earlier Pluck Sitelife API system when we moved RAGBRAI.com to WordPress this year).
After users upload their photo and add a description, we then prompt them to tell us where the photo was taken, if they remember. First we check to see if there’s any geographic data in the photo’s meta data (iPhones and some newer cameras add GPS data by default). If that’s not there, we use any city or address data the user enters to run the photo through Google’s geocoder. Or if users remember exactly where the photo was taken, they can just click on a map to set the position.
As of today, 6 days after the ride ended, RAGBRAI.com’s 2009 gallery has 817 user photos, 554 of which have been mapped. That means users have given us geographic data for nearly 70 percent of the photos, compared to something like 5 or 10 percent last year.
So what accounts for the difference? It’s possible some of it i just that average Web users (RAGBRAI riders tend to be about 40) are just getting more accustomed to online mapping functionality. But I think the vast majority of the difference is in the process we use.
In 2008 we asked users to “map their photos,” and it was possible to upload photos without seeing that prompt. But I think fundamentally, people didn’t get it. But when we integrated it into the upload process, and just asked them where the photos were taken, it made more sense and was a much more passive user experience.
We’ve learned our lesson: Don’t expect users to share your goals for your apps and expect them to do something new — figure out what users are already doing and figure out how to tap into that process.
As you can see, a few photos got placed pretty far from the route. Ah, the joys of user-submitted content! Actually, I’m surprised it didn’t happen a bit more. I think a lot of it is users who initially input some data, then see the map that pops up, and click on it out of curiosity, not realizing that they’ve just moved their photo’s placement.
There’s definitely ways to handle it. If we had more time I’d probably add a spatial query to the uploading process that warns users that their photo has been placed outside a buffer zone around the route — something like 1o miles probably. We could still add this after the fact on the display side, so we only showed photos inside that buffer. But to be honest, as long as the number of outliers is small, I’m fine with a few of them — this isn’t news data analysis here.
Michael Corey is a news applications developer at the