NYC VERTICES:
In several recent posts, I’ve talked about experiments with personal geographic data collected via OpenPaths. In those examples, location is treated in absolute terms, latitude and longitude.
However, I am working toward something here. Most of my past work has been concerned with the relative qualities of place, the psychogeography that isn’t necessarily keyable to coordinates (see our article in Urban Omnibus). Presently, I’m developing some analytics to try and bridge that gap.
The first order of business is to begin thinking about location in terms of place. Place is a concept that is relative to the context of the individual — but using geodata we can at least identify significant patterns that suggest loci of activity.
Starting from my path data, I used a clustering algorithm (I’ll post the code next) to construct a network graph of my arrivals and departures around the city. What you see here are the locations of all of my “significant” places around the city, over the last 6 months or so. NYT Labs is the big green point up top — home is purple toward the bottom. The lines show the strength of the connections between them (eg, from home I’m most likely to go to the lab).
The conceptual shift here, and I think it’s an important one, is to begin to treat location as behavior. More to come.
(drawn with python)
One thing I wanted to try with OpenPaths data is to reconstruct the paths I have taken. I’m using the as yet unreleased iPhone app, which records a point every time there is a “significant” location change, as determined by the iOS API (this runs in the background without much battery drain — the reason we aren’t using continuous GPS is that such an app would quickly burn through it).
This image shows all of my points around the city in a given time period (without a base map, to preserve some privacy, and it’s kind of more interesting that way). The lines are determined by grouping series of points that are within 10 minutes of each other and inferring the start point.
Additionally, I estimated the maximum speed of each path by looking at the fastest few segments. By clustering the speeds, using the k-means algorithm, the paths are classified by mode of transportation. Red is car or Amtrak, purple is bike (my primary mode), and green is walking.
The arc of my frequent rides between Brooklyn and midtown are pretty clear, and in general you get a sense of the areas that I habitually cover with the different modes. Note Prospect Park at the bottom. One thing that’s a significant omission is the bulk of my subway travel — any ideas on how I could infer this would be appreciated. And I certainly walk around more than is reflected here, but the location changes aren’t big or sustained enough to register.
Slashdot picked up on a project Ive been working on at the lab, originally described by the Nieman Jouralism Lab. Nieman didnt show what I think are the better features of the mirror (visualization of sensor-based health stats, gesture-controlled video), and the Slashdot thread, though hilarious, misses the point behind the project. I hope to articulate the project better in our own documentation and a new version of the software which we’ll roll out in the coming months.
The Zeo is actually a surprisingly effective sleep monitor, an EEG sensor you wear when you sleep that syncs with a base station. By recording your brainwaves, it breaks down the night into periods of deep, REM, and light sleep, and stores the data on an SD card which you upload to a website for analytics (they should really give the base station some wifi). I say surprisingly, because I was startled at the degree to which I could reconstruct a bleary narrative of my night — unconsciousness, sequences of dreams, car alarms, etc — by looking the graph. I typically remember my dreams, and occasionally lucid dream spontaneously — people have already been hacking the Zeo to aid in their lucid dreaming practices.
Zeo has their own graphs, which are plenty nice, but I wanted to create a visualization which would allow me to see all of my nights at once. I was hoping that a radial arrangement would reveal ‘ripples’ of dream states that occurred at relatively constant amounts of time after falling asleep. Try as I might to cluster the sleep data in different ways to show the patterns, that idea turned out to be false (Ive since learned more about sleep and the roll that body temperature cycles may play, which perhaps prevents these from lining up.
In any case, this is an example of the visualizations Ive been making. It shows two weeks of sleeping, with a wedge for each night. The center of the image is the point of falling asleep, and you move later into the night as you move outward. Bright blue shows proper “deep” sleep and the greenish rings are REM, with everything else being fairly crappy. The number on each night is the “ZQ” from Zeo — a measure of sleep quality taking into account time asleep and the duration of each phase. Created in python with my drawing module.
VISUALIZING RELATIVE ENGAGEMENT LEVELS AT EYEO WITH THE AFFECTIVA Q-SENSOR
Affectiva is a spin-off of the Affectiva Computing group at MIT. Their Q-sensor measures skin conductance, which increases with “excitement, attention, or anxiety.” It also has an accelerometer and logs data at 32hz for over 24hrs, which is rad. I’ve been playing around with one in the lab to see if the metrics are useful as a measure of engagement in various of our prototypes, as well as working with the NYT customer insight group to see if they can play a role in evaluating site UX. Soon I hope to include it in my behavior modeling research.
In any case, I’m at the eyeo festival in Minneapolis. I thought it would be fun to see what would happen if I wore the sensor my entire time here, and to correlate the data with events during the day.
Im pulling in the raw Q-sensor data, and processing it to produce a visualization of two features in the signal: a low frequency “tonic”, which shows the general level excitement, and “phasic” features which are more discrete moments of engagement, eg, lots of social interaction. I made a quick web app to record events (although Ive done a terrible job of using it).
The huge caveat here is that the raw signal is very rich, and this visualization strategy is a very rough take at interpreting it. I’m making no claims as to what this actually represents. And I’ve labeled almost nothing. So if you find the graphic unsatisfying, it’s a reflection on me and not Affectiva’s great hardware. I’ve used my python drawing module.
I will also state that everyone’s presentations have been awesome, and I’ve remained fully engaged throughout, regardless of what the sensor says. Ill try to improve things in the coming days.
OK, off to bike down the Mississippi.
DAY 0 (6/26)
DAY 1 (6/27)
DAY 2 (6/28)
DAY 3 (6/29)
AN ACTIVITY HEATMAP FROM FITBIT DATA
The Fitbit is a very nicely designed device, basically an accelerometer plus clock in a belt clip that will wirelessly sync to a base station. It’s marketed as a fitness aid — on their site, you can check out charts and graphs that give you some sense whether you’re moving as much as you should be, set goals, and add subjectively reported measures like diet and mood. It’s a perfect example of a tool for a quantified self practice.
Though fitness is interesting, I’m more fascinated with the possibilities of using movement data for behavior analysis. My intuition is that the patterns of how much one moves over the course of a day or week or month is enough to infer quite a bit about an individual’s lifestyle and to potentially drive a predictive model.
Fitbit data, once gathered by the base station, is sent to your account on their site, which is accessible through an oauth-based API. Which is awesome. However, I was disappointed that the data they expose is very much geared toward their fitness market, and is preprocessed and interpreted along these lines. Significantly, unless I’ve just missed something, the raw, minute-by-minute data is not available, and everything is aggregated by day. While I can understand the motivation behind this, there is lot of power in the raw stream that’s not exposed.
However, prior to the release of the Fitbit API, the developer Eric Blue published a hack in perl that scrapes data from your Fitbit profile page — turns out that the Flash charts they display are powered by an XML feed with significantly more resolution than what is offered via the API. Based on this discovery, I wrote a python script that pulls the granular data.
Using numpy and my nascent drawing module, I created a heatmap of my average week in terms of intensity of movement (since 2011-01-01, wearing the Fitbit somewhat consistently). Behavior clearly emerges, and my bike to work each morning dominates.
From here, there are a lot of possibilities. Beginning to cluster days by type and to cross-reference this with other vectors, such as location, are my next steps. We’ve ordered like 10 of these things for the lab, so I’m psyched to see what we can do with them.
