TSE Overview at Dorkbot - Part II
On Thursday March 25th we presented Toronto Sound Ecology at Dorkbot Toronto. This is the second half of the talk.
Now that Max has situated the TSE project in relation to geography and lived space, I'd like to go over some of the technical details – and dwell on how this project lives on the web. As a point of departure I'd like to point at a 2008 interview with Adrian Holovaty just as his incredible EveryBlock project launched. In talking about how data journalism was reshaping the traditional newsroom, Holovaty stated:
We’re interested in spreading the concept of “geocoding” news—that is, classifying news articles by location. Currently, we do that by crawling news sites and applying algorithms and human editing efforts, but it’d be best for everybody if news organizations did this on their own. We’re interested in developing some sort of specification/standard for designating granular locations in news stories—look for more about that from us soon.
I think this perspective is important for a number of reasons. Holovaty is clearly tuned in to how news (and narrative) events can be tethered to geodata – how the search paradigm relates to how we engage urban space. What is most interesting to me is his language – the manner in which he stresses the "granularity" of location. We're all used to this kind of specificity being used to sort our personal, professional and communicative relations through social networks, so it only follows this logic should now apply to location.
A great example of this kind of rigor is Stamen's Oakland Crimespotting, a project that redeploys police reports as content for an interactive map. The team behind this project have delivered a finely tuned interface for exploring how crime plays out across the city over time. As editors of this dataset, they've categorized crime (violent, non-violent, property damage, etc.) so that citizens of Oakland have a means to explore where crime happens – traditionally citizens would rely on a newspaper for this kind of information. [See my 2007 blog post on this project]
We obviously don't need to look to one off creative projects to see how the web is moving towards embracing a locative outlook. Web services like foursquare and gowalla represent a "new breed" of social network where activity streams and status updates are georeferenced. While I'm all for the manner in which foursquare presents the city as a game I have some reservations about the tone of the project. As we know from other social networks, the protocols and interface users are presented with dictates how users engage the system and (to me) foursquare presents the city as little more than a matrix of restaurants, bars and shopping destinations. Beyond this point, questions of class start to arise. What does it say about a platform when the user base of a web service does little more than advertise the three upscale eateries and lounges they visit on a particular evening with their $700 phone? I like to fool around on foursquare and occasionally issue fake checkins advertising that I've unlocked the "functional alcoholic badge" or that I'm the mayor of The Centre for Addiction and Mental Health – I don't exactly know what else to do with the service. Facebook will be rolling out their location-based status updates soon and you can bet this will be accompanied by a new and improved contextual advertising engine. So this is the state of the web to which we introduce our comparatively tiny and irrelevant project.
Since Max has given you an intro on how our project addresses the collection of walks, I want to highlight some of the tools and protocols we've used to develop Toronto Sound Ecology:
- First up is OpenStreetMap – the Wikipedia of web mapping. This is where we get our maps of Toronto. OpenStreetMap is part of the web commons, it is free to use and the underlying data is constantly being improved by a global community of users.
- We use CloudMade to style our base geodata. CloudMade is kind of a force-multiplier for OpenStreetMap, their interface is very powerful and it permits you to adjust the colour, line weight and fills of the various layers of your map and turn layers on or off. This allows you Adobe Illustrator-like control and the user is free to move away from all the familiarity and baggage associated with proprietary mapping services.
- Maps are served through OpenLayers – which I'll discuss in future posts.
- In terms of file formats each walk yields two files – a 320 kbps MP3 and a well-known text (WKT) string. The MP3 needs no introduction. The WKT is vector line broken down to a series of points, each with latitude and longitude coordinates. So a 6 or 7 minute walk will be reduced to say a half dozen points or so, indicating where the walker turned or cut across the street.
It is kind of interesting to take something as visceral as a city walk and reduce it down to a medium quality audio file and a vector line. Toronto Sound ecology is definitely a "fuzzy" archive, one that is content with inexactitude. We do ask for more from our soundwalkers than an MP3 and a WKT file – each walk has a range of metadata associated with it. The image at the top of this post is a simple diagram of the information "attached" to each walk. This includes:
- The info attached to the MP3
- The date and time
- The temperature and prevailing weather
- Key sounds are identified (user generated taxonomy)
- The recording model of the recording device
- A brief annotation is made to describe the walk in several words
So while a walk is "reduced" to two simple file formats we are collecting a fair amount of information contextualizing those files. We're fine with this information being approximately correct and the only editing we plan to do is adjust taxonomy terms of the sounds so that they are standardized across submissions. We plan to use this metadata as the basis for further developing the interface – we're definitely going to use time of day, season and weather information as the basis for searching and browsing the walk archive as we develop the interface for the site further.
This site is built in the Drupal content management system – I'll use a future post to map out which modules we are using, how they relate and give an overview of the general workflow. My intent is to document the development of this project as clearly as possible.


