(Some cartogram structures and linkages Pascal created as sensor maps where the geography is an implied and driven — rather than the driving — parameter.)
Fabien Girardin, MIT brainiac and a fellow Near Future Laboratory ‘naut presented his expert and insightful trinity of themes that appear to be the main motivators behind "urban computing", a bit of cocktail party conversation related to this short essay that Kazys Varnelis and Leah Meisterlin wrote, and that Nicolas poked a stick at.
Fabien describes three prime motivators behind the “urban computing” discussion and construction projects. Bears repeating, with some commentary.
1. Creating an opportunistic and optimistic urban environment that is somehow “better” than one without some sort of underlying computational infrastructure. This is the realm of the ubiquitous computing folks. The visions are aspirational — near-future signposts always already just out of reach and endlessly deferred — perhaps this is the definition of industry and academic R&D. Provide curious near-future fictions about possible near-future worlds. Effectively science-fiction expressed through objects and scenarios and large research (instead of film and television production) budgets. (Cf ““Resistance is Futile”: Reading Science Fiction Alongside
Ubiquitous Computing”, Paul Dourish and Genevieve Bell, forthcoming in Personal and Ubiquitous Computing.)2. Study of the impacts and implications of computational systems and operations in an urban context, performed by GIS folk and urban planners and computer science people. These are studies of the dynamics of data-people sensed in the city, mapped and used to develop insights on urban conditions, or perhaps used as contributing information for design or re-design of urban geography. In some cases the data is interpreted in real-time, such as you might expect to be done to manage loads on cellular data networks, etc.
3. The action, postulating and creative exercises of independent and undisciplinary explorers and adventurers who shuffle and interleave the interesting data points that are anchored to geographies that can be re-mapped. This has brought us such interesting tidbits as the various crime data maps, for example, or the flows of automobiles throughout cities. (Using the geeky, horribly, self-deprecatingly named “mash-ups”.) What is happening here that is most compelling to me at least is that “GIS” activities are becoming something that anyone, without a license or professional sanction can do, inexpensively (i.e. for free and a bit of time). So, anything new here and worth glorifying is this fact — we can be our own map-makers. This is significant in the Foucauldian power-knowledge sense of significant. Cartograms such as the fundraising maps, which started out as a very DIY project, are important because they create new meaning and possibilities for action, or shifts in perspective that can lead to change, rather than stagnation. (There’s a normative element, of course. Visualizations of data with geographies, in the power-knowledge realm of things, are as free to interpretation as anything that alleges to be fact, so they can’t be counted upon to prove much of anything. At worst, they can be enrolled in larger conversations, just like any good knowledge agent.)
(Some more of Pascal’s cartogram structures and linkages. Sensor maps recorded amongst a small group of us and visualized such that the geography is an implied and driven — rather than the driving — parameter.)
I’d add a bit here. How can the experience of space — urban space, just to stick to the most discussed idiom — become fruitfully and playfully data-driven? Mapping data onto geographies by their instrumentalized location in space is okay. It’s a bit knee-jerk, though. What I mean is that re-mapping data with an entirely different basis could possibly produce an entirely different urban experience that may, at worst, be curious and playful. Just to see what comes of this. The Laboratory has been working for way too long on such re-mappings that do not assume that latitude and longitude are the canonical reference points for whatever data gets built on top.
I know..I know. This is weird. And the first project I was involved with that did this — an edition of PDPal that created maps based exclusively on interpreting an “experience” — fought a losing battle. But there are some indicators that this approach is at least worth exploring.
Creating “maps” that have a spatial aspect to them, but that do not use space as the primary or explicit reference datum can then emphasize people-practices or experiences first, with the geographic datum implicit or made into a driven, rather than driving, parameter. Paulos and Goodman’s “Jabberwocky” project comes to mind, as do Twitchr and other mappings of “encounters” and actions that are not expecting to use GPS first-and-foremost.
Situationist Space (Thomas F. McDonough)
Here in the Laboratory we’ve been building several prototype devices that record Bluetooth encounters for later visualization. The first prototype was a small Python script running on a Nokia N70 phone. It was like a little data attractor that would sniff for Bluetooth devices, and then record them in a log file, and send them to a server to be persisted in a database.
Two recent editions used a small, custom-designed device that used the Bluetooth scanning mode of a radio to essentially do the same thing, storing the results in a Flash memory device to be later extracted with a simple USB interface. Lately a bunch of us in the studio have been working with a similar concept in the form of a background sensing application developed at Nokia R&D for S60 devices that does all of this, plus quite a bit more. (Currently in closed alpha, but soon to be available publicly.) The biggest challenge (besides running it on an S60 device..) is making meaning out of all of this. The strongest vectors for me, at least, lead to re-mapping and exploring possibilities playfully, with no specific expectations that there is intelligence in the maps by themselves.
# install first the following files to your phone
# (they will install automatically the needed libraries for the script below):
# aosocket-series60_v20.sis, pdis.sis
# found at: http://pdis.hiit.fi/pdis/download/pdis/
# this script was found from forum.nokia.com
import e32
import appuifw
##import aosocketnativenew
from pdis.lib.logging import *
##import httplib, urllib
from location import gsm_location
import time
import sysinfo
import select
cell = []
init_logging(FileLogger("e:\apache\htdocs\bt_probing.html"))
def tell(string):
#logwrite(string)
if e32.is_ui_thread():
print string
e32.ao_yield()
# ----------------------------------
from aosocket.symbian.bt_device_discoverer import *
#from socket import * # for obex file send
def discovered(error, devices, cb_param):
if error == 0:
global cell
#tell("start discovery..")
cell = gsm_location()
#tell("devices: " + str(devices))
tell(cell)
#print location.gsm_location()
for address, name in devices:
logwrite("")
tell(cell[0])
tell(cell[1])
tell(cell[2])
tell(cell[3])
print location.gsm_location()
urllib.urlopen("http://smalltown.nearfuturelaboratory.com/upload_bt.jsp",
urllib.urlencode([('addr',address),('name',name),
('imei', sysinfo.imei()),
('batt', sysinfo.battery()),
('signal', sysinfo.signal()),
('cell_0', cell[0]), ('cell_1', cell[1]),
('cell_2', cell[2]), ('cell_3', cell[3])]))
else:
tell("device discovery failure: error %d" % error)
_discoverer.close()
# -----------------------------------------------------------------------------
while(1):
try:
_discoverer = BtDeviceLister()
_discoverer.discover_all(discovered, None)
#tell("discovering")
e32.ao_sleep(15)
print "scanning again"
except:
tell("init failure")
appuifw.note(u"Fatal error.", "error")