The Sajara team started working with Google’s Street View quite a while ago as part of our work for Muralfarm.org. During that implementation I realized that, while good intentions abound, the Street View wasn’t really showing our users what we intended them to be looking at. For Muralfarm.org, we wanted the Street View feature to offer a more contextual view of Philly’s murals than the images in the system. The problem was extremely few default Street View coordinates actually pointed at one of our murals!

Now take that situation and imagine how confusing things could get when PhillyHistory’s historic photos get a dose of Street View. Not only might Street View not be pointing at the right building or street corner, but the subject might not even exist anymore! The average user has no way to tell what connects the historic images to the presented Street View.

After a bit of digging, I found that we weren’t giving the Street View API quite enough information for the kind of detailed positioning we were after.  After giving the API a mural’s x/y coordinates, it was filling in the rest of its parameters with default values:

• Pitch: 5
• Yaw: 0
• Zoom: 0

Anyone who’s worked with 3D camera positioning or flying might know what those values should be; I had to go look them up the first time.

If you think about holding a camera, there are three ways to move it to get it to point where you want it: pitch, yaw and roll. Pitch is a measure of tilting up-and-down motion and Street View uses +180 to -180 degrees for this value with 0 degrees being perfectly level. Yaw is your side-to-side movement value and Street View uses a full 360 degrees for this one. Both 0 degrees and 360 degrees are due north. Roll is the only directional indicator that doesn’t get used… after all, they were using a stationary camera on top of a vehicle; no roll available. The last value in the list above is zoom. I haven’t seen any panoramas with more than three zoom levels: 0, 1, and 2.

Building a tool to let administrative users change these values should be easy… and it was for the most part. Google’s Street View API reports changes in the positional values using some fairly obvious events: yawchanged, pitchchanged and zoomchanged. So catching those numbers and saving them was a piece of cake.

One challenge I ran into is some slightly overzealous reloading. I built our editing tool into an ExtJS TabContainer widget and each time a user leaves and returns to that particular tab (not having changed anything else in the meantime) any unsaved changes are lost. I can’t go saving Street View position values to our database every time someone switches tools, so I have to settle for some stern warning text about losing data.

A future challenge I face is part of the classic battle of the 900913 projection vs. PA State Plane South. I predict heavy use of a sound-proofed room, the Proj4js forums and lots of comfort food… or I’ll just use Azavea’s common libraries. ^_^

Deb, our resident archivist, has written about the impacts of Street View on PhillyHistory.org over in Azavea Atlas. You can also check out the Street View on Muralfarm.org and PhillyHistory.org. Let us know what you think!