Mobile Archives - Near Future Laboratory

The Atlas of Desire

Or: privatesquare, ten months later

It would be generous to say that privatesquare was ever released. Instead, the source code was made public with a long and twisty blog post and a flurry of screenshots. I’ve told a few people about my installation of privatesquare but since I haven’t had the stamina to run a service for strangers (and a free one, at that) it’s remained small and reserved for friends and family. A few people along the way have set up their own instances and that’s been both gratifying and enormously useful in working out some of the kinks.

Maybe there are lots of copies of privatesquare running in the wild. I have no idea and no way of knowing. This is not a bad thing. In the meantime, I’ve continued to chip away at the project adding small features and fixing bugs as they come up.

Recently, we moved from San Francisco to New York City. Maybe foursquare, itself, woulda-coulda-shoulda started in another city but once you start to live the day-to-day ritual in New York it becomes pretty clear why it started here. The Atlas of Desire feature, described below, probably would have languished in a pit of good intentions if we hadn’t moved here but I’ll come back to that in a bit.

When it was first announced, last November, privatesquare came with a long list of tricks it hadn’t learned so it’s probably long overdue for a status update.

New old things

Here’s an unordered list of the things privatesquare said it didn’t do went I pushed it out of the nest:

History pages

There are now history pages for venues and dates (and date ranges) as well as for cities. Details on that below.
Sync with the foursquare API…

This is now possible, although it’s not enabled by default.

Specifically, there is a little script that can be run by hand to import any foursquare check-ins that may have happened outside of privatesquare. This includes the history of check-ins that predate someone starting to use privatesquare. Or not. That’s why the feature needs to be explicitly enabled by each user choosing from one of three options:
- Do not sync foursquare check-ins – Which is what it says on the tin. What you do elsewhere is entirely your business and privatesquare doesn’t need to know about it.
- Only sync recent foursquare check-ins – Tell privatesquare to archive missing check-ins but only those that have happened since you signed up (with privatesquare).
- Sync all foursquare check-ins past and future – This tells privatesquare to archive your entire foursquare history. This is what I’d expect most users to choose but it just always ends better when you let people make that decision for themselves.
The nearest linear cell-tower problem…

Sort of. Not really, though.

The nearest linear cell-tower problem is caused by the fact that when a person is using privatesquare from their phone they are connected to the Internet through a cellular rather than a wireless network. Since the nearest cell-tower is used as a proxy for your location and since cell-towers have a range that is sometimes greater than the radius used to query nearby venues the list of places that gets returned is sometimes weird and full of bunk.

One issue is that the W3C geolocation API, used by web browsers to determine your location, doesn’t tell you how your location was acquired. Was it from a wireless network? A cell-tower? A passing drone, overhead? There’s no way to know and by extension no way to adjust expectations.

The nearest linear cell-tower problem is ultimately a user-interface problem and not one that’s ever been tackled particularly well. In more recent versions of privatesquare there is sometimes a little grey dot (rather than blue) that’s meant to indicate where the code thinks you are and help provide some context for the other dots.

Another option is to allow you to grow the search radius for each query but I haven’t done that yet. File under: Something, however inadequate, instead of nothing.
There is no ability to delete (or undo) check-ins…

Done.

Except for the part where there’s no way to delete check-ins using foursquare API which is … puzzling, to say the least. So in those instances where you’ve checked in to both privatesquare and foursquare and then delete check-in using privatesquare you’ll be presented with a short (exasperated) note explaining the situation and a link to the foursquare site where you can finish things up.

I know, right?
There is no ability to add new venues….

Nope. Still not possible. Chances of it happening remain close to zero.
Nor is there any way to record events offline…

Sort of. Kind of. But only one particular facet of the problem is handled well.

I first started thinking about this at SXSW this year because the combination of both the cellular network and foursquare being simultaneously overloaded with eager users meant that privatesquare was often unusable in downtown Austin.

There are two problems that need to be sorted here:
- The first is some way to store a check-in for future use when foursquare API is sad.
- The second is some way to store a check-in for future use when the network itself is sad.
The first problem is now accounted for with pending check-ins, something I’ll discuss more in a bit. The second problem isn’t really accounted for at all and at some point I just need to sit down and look carefully at what the Lanyrd kids did for their mobile site and probably just copy that.
There is no way to distinguish duplicate venues (same name, different ID)…

Nope. Still punting on that.
Pages for venues…

Totally!

Every venue you’ve checked in to now has its own page on privatesquare. Each venue page has a list of the dates you’ve checked in there (including links to the actual check-in page), a link to other places you’ve checked in to nearby and a handy I am here now button for … well, check-ing in again.

Designing for thumbs, and all that.
Pages for cities…

Yes!

All check-ins in privatesquare are reverse-geocoded using the Flickr API which returns a list of Where on Earth (WOE) ID associated with a venue. At the moment only cities are recorded so you can’t filter check-ins by neighbourhood or country. Technically, there’s nothing to prevent it from being possible but cities seemed like a good and easy place to start.

The places pages are kind of great and they are especially striking when you see them on a screen that is bigger than your phone. And because it uses the Flickr API it means that airports are bucketed as cities which makes even more sense in a foursquare context.

Neighbourhoods are also a near-certainty given that no one’s geo infrastructure can figure out how to make peace with the meta-neighbourcities, called boroughs, that form the NYC metropolitan area and I actually have to suffer the consequences now that I live here. See also: the Atlas of Desire, below.
Export…

Yes!

There are handy links at the bottom of most pages to export your check-ins as either a CSV or a GeoJSON file.

Exports are available for the following buckets: check-ins by date or date range; check-ins for a venue; check-ins for a place. Exports should be available but aren’t yet for for: check-ins by nearby-iness; check-ins by desire (more below).

It has also been the case that if you’re running privatesquare in a controlled environment (like a shared web-hosting service) that enforces its own usage limits exporting check-ins for a user with billions und billions und billions of check-ins can be problematic. I don’t have a ready-made solution for this problem, yet.

New new things

At the same time all of that was being done, there were a bunch of smaller things happening. In no particular order they are:

Documentation!

Gary Gale has done an amazing job of peeling away, with fresh eyes, the stack behind privatesquare and Flamework and keeping detailed notes about what everything means and how to get privatesquare up and running with a minimum of fuss in a variety of environments.

Gary is also one of those people who checks in every time he exhales so he’s been excellent at finding the crumbly edge of things in privatesquare.
Weather tracking

privatesquare tries to record the weather (based a venue’s latitude and longitude) whenever you check in. Not much is done with that data except to show in the list of check-ins for a venue. The data is stored alongside the check-in so there’s always to opportunity to do something clever and interesting with in the future and in the meantime it makes for a nice soundtrack when scrolling backwards through the history of a place.
Time of day tracking

Sort of.

Vladimir Agafonkin wrote a lovely little Javascript library to calculate the time pie for a given timestamp and Tom Carden was good enough to create a handy HTTP pony wrapper for it on Heroku that can be poked when a user checks in.

All your check-ins that happened during the golden hour and that sort of thing.

Unfortunately, with all the other network requests going out to third parties (foursquare, weather services and so on) the API call to get a time pie is often the one that fails or is killed because it happens so late in the chain of events. For the time being it is not a feature that is enabled by default. There’s a branch of privatesquare with the start of a pure PHP port of the code but it is both incomplete and full of bugs.

If you’re not familiar with the idea of time pies, you should definitely read this blog post about them from the Stamen kids.
Deferred check-ins

Occasionally the foursquare API is sad. Sometimes it happens when you’re trying to use privatesquare. In the past you were sorry-out-of-luck but now when that first API call to fetch nearby venues fails privatesquare will give you the option of writing down the name of the venue you were trying to check in to and stick it, along with a timestamp, in your browser’s local (storage) cache.

Once that happens a link titled pending will magically appears in the navigation menu and from there you can go back in time (sort of) and finish check-ing in.

Essentially all that’s happening is the usual check-in process being replayed but with a canned search term and a note to privatesquare to use a an equally canned check-in time instead of of right now.

For a bunch of perfectly good reasons you can’t do the same in foursquare so any pending, or deferred, check-ins are not forwarded along to the mothership. I may change that in the future and handle the spacetime disconnect by simply adding a note to the foursquare check-in. We’ll see.

This is basically what should happen when the network itself is down or unavailable. Cities like New York are strange beasts that way. It’s hard to keep the scale of the infrastructure, and the burden of its history, in mind some days. Aside from the fact there are whole pockets of the city with terrible network (read: cellular) connectivity there are others that completely silent, to this day.

Subways are an obvious place to want to check-in and privatesquare shouldn’t let itself be defeated by the dark spaces underground so teaching the code to play nicely as an offline application is rapidly bubbling up the totem pole.

I’m told that if you have one of the fancy auto-refilling monthly New York City subway passes it’s possible to retrieve a history of all the stations where it’s been swiped so that bodes well for some sexy Clipper Futures style integration with privatesquare in the not too distant future.
The Atlas of Desire

Let’s be honest. On its current trajectory privatesquare will, sooner or later, become Dopplr. I don’t know what that says about foursquare and since the thing I built is, by design, not social I couldn’t exactly call the Chris Heathcote buckets described in the first blog post a Social Atlas. So, I called it what it is: an Atlas of Desire. Or, in concrete terms:
- Web pages and list view for all the places you’ve checked-in to rolled up by the status you assigned: I am here; I want to go there; again again; and so on.
- The ability to change a status after you’ve checked-in. For example, you could check-in to a restaurant when you sit down to eat and then change to again maybe when you leave.
I’ve also added a new status simply called meh which, to my mind, is somewhere between again maybe and again never but ultimately the semantics are left up to individual users.

If you asked me I’d tell you it’s for those places that you would visit for purely mechanical reasons: No matter how lackluster the food is it remains less bad than the bad craziness and temper tantrums caused when you melt down out of hunger.

Shelley Bernstein, from the Brooklyn Museum, deserves a proper shout-out for the Idea of Meh which was part of her work making public the museum’s collection metadata.

In addition to filtering your check-ins by status, you can further prune those places by nearby-iness or by city. It’s become pretty obvious that you should also be able to scope your desire to a neighbourhood. (See above inre: neighbourhoods.) It’s not a hard feature to add but it is a lot of typing so it will happen sometime between this blog post and re-wiring everything to work offline.

Still broken things:

Things that should never have been broken in the first place and that maybe I should fix before I say anything else, but oh well…

OMGWTFTZ… timezones

There are no excuses for this. It’s a thing that conveniently Just Works ® on the West Coast (because that’s the default timezone in the source code) and a thing complicated enough, under the surface, that I’d like to spend a little bit of time thinking about it before I go charging in to fix things.

Probably the best thing would be to check for the timezone in the foursquare API response when you check-in and store that information locally. Failing timezone information in the API response I might build a simple httpony service on top of the whereonearth-timezeone dataset to do reverse geocoding for timezones.

Sorry.

Things still TO DO

Mike Migurski has requested that privatesquare grow an I’m on my way status flag which is tempting but we’ll have to see about that one. Meanwhile, in no particular order these are some of the outstanding known-knowns:

Make the tasteful pale grey permalink button and link for individual check-ins less invisible

Yes, there are tasteful pale grey permalink buttons and links and for every check-in.
Build scripts for “cloud app” hosting

Gary’s documentation for setting up privatesquare is great and makes the whole process less painful but enough technical hoop-jumping remains to make it all inaccessible to a lot of people. Meanwhile, there are a whole raft of hosted services, like Heroku or PHPFog, that allow you to one-button install web applications which seem like they would be a good fit for things like privatesquare.

Unfortunately the way the privatesquare is bundled (read: the ways the files and folders are organized) doesn’t lend it to one-button anything with many of these services. privatesquare (and similar tools I’ve been tinkering with at the same time) has never had versioned releases but it might be time be time to start freeze-drying the code at particular moments and creating discrete bundles targeted at specific environments.

Those releases would always lag a little behind the new and shiny but the up-side is that it would be easier to install, which is probably a trade-off some people would make.
Sharing. Maybe? Probably not…

privatesquare is so-called for a reason. Every now and then I think about changing the default check-in status from don’t tell foursquare to don’t tell anyone which would, once you pulled in a user’s contact list, allow for sharing of things on privatesquare.

I am still unconvinced about this one as it adds another layer of complexity and it’s not clear why it’s useful (foursquare is pretty good at that side of things) outside of the Atlas of Desire for which plain vanilla exports are probably more important. To whit:
Better integration and/or pillaging of the Dotspotting codebase

A couple months ago I forked the source code for Dotspotting and started to add the ability to edit individual dots. That’s really as far as I got and I’m not entirely sure where it all fits with privatesquare but the shadows of the two projects seem to overlap more often than not.

Something something something see above something about exports something something something maps something something something.
A proper API

privatesquare already uses its own API but punts entirely on delegated authentication and still uses cookies for authentication and authorization. This is not ideal or, rather, is not a reason to lack an API that third-parties could build on.

This is just another one of those tasks that requires some time where I sit down and spend the time to finish all the typing necessary to make it happen. Unfortunately, it is a thing made more complicated by the fact that having to read any of the OAuth specs makes me a little crazy in the head. It will happen.
Notes

Maybe. I’m of two minds which is to say I’m not inclined to add notes because I like the simplicity of the site, now, but could be convinced. For a while I had a version of privatesquare that would let you add notes to Findery (née Pinwheel) from venue, or check-in, pages and relied on the magic of machine tags (on their side) to stitch everything back together. I liked that and when there is a public API for the site (in the past I was… well, yeah, anyway…) I will probably slip it back in as an optional feature.
Artisanal Integers!

No, really.

Privatesquare is at least half the reason that artisanal integers exist at all so it’s only fitting that is should start using them. Dan Catt’s blog post about London Integers is good place to start if you’re sitting there oscillating between confusion and table-pounding muttering the words artisanal… integers…

Really.

One of the nicest things anyone has said to me about privatesquare since I started building it was: Oh, I’d love to use it but I can’t because I have an Android phone. The nice part is: you can! privatesquare is nothing more than a what-do-you-call-it web application.

The whole native versus web application debate on mobile is interesting, but only insofar as there are still a few tricks that web browsers can’t do or that they are prevented from doing by the operating system itself. Beyond that it all smells too much like the insane and self-serving hair-splitting that people, in the 90s and early 2000s, made about WAP and other uniquely mobile technologies. Read: Small computers, in your pocket.

privatesquare is meant to play equally well with your desktop as it is your phone. As time permits and I can work through what a print-specific CSS file looks like it should also work on that crazy retrograde technology that refuses to die: paper. The extent to which privatesquare fails, in any of those arenas, is more a reflection of (my) poor design skills than it is proof that somebody’s preferred form factor wins at celebrity death match.

And on and on, it goes!

Weekending 17062012

Here in Los Angeles it’s mostly been programming and book editing and talking to humans. Geoff Manaugh and Nicola Twilley stopped by to do an interview for their curious cross-country mobile blog/interview platform/landscape exploration vehicle called Venue. That was good fun to discuss the various ways landscape, urban space, data-based representations of places, things and flows of humans has informed and influenced the work we do here. Curiously — that seemed to be the topic of the weekend in one way or another. By that I mean that Sunday evening Zoe Ryan and Karen Kice to talk about the same set of topics for a forthcoming exhibition that the Art Institute of Chicago will do. It was a good opportunity for myself — to refresh my memory about a number of projects that sometimes I forget about, like Drift Deck and PDPal. So fun conversation time last week.

The programming has been good and fun as well. It’s quite nice to get back into that and maintain that skill as well as check off the to-do list a number of ideas and projects that have been lingering. I’m currently working on a little social browser/viewer that inverts the way I “catch-up” with my Friends — other than the “friends” that I find online or who ask me to be their friends but, really? I have little idea as to who they are and often quite a small/nil stake in what they’ve been doing or what they’ve taken a photo of. So, in the app I basically go through the social services for these true-blue Friends and show their latest photos, tweets, etc., so that I don’t have to trawl for them amongst the kruft of illegible feeds and all that crap. I go to people first rather than social services.

And then Rachel Hinman’s new book “Mobile Frontier” showed up with a little interview she did with me. So..that was fun.

Additionally, there’s been more planning and phone calls for this Design Fiction workshop we’ll be doing in Detroit this fall. More about that when I’m not rushing off.

Otherwise..looking forward to the summer with Nicolas here quite nearby in Venice Beach.

Continue reading Weekending 17062012

Interaction Awards 2012: Drift Deck for People's Choice

Drift Deck is up for the IxDA Interaction Awards in the “People’s Choice” category. Which isn’t the “Jury’s Choice” but — whatev. It’s the People, so we’re hustling to make you, the People, aware of this chance for you to choose what is the Choice of the People. For Interaction Design Awards.

Please give it a vote.

What makes Drift Deck chooseable? Well — it does something different and provocative in the world of interaction design for the things we do when we’re going/finding. The canon of interaction design for what were once fondly called “maps” is pretty stuck in the mud. Nothing extraordinary going on there that you wouldn’t expect from the next generation of mapping things.

What we did with Drift Deck was look at the world a little sideways and imagine a world in which the map was a bit dynamic and the act of going/finding was a bit less, you know — purposeful in a tedious, dogmatic sort of way.

It’s an otherworldly map app, if you will. Drift Deck is meant partly to be pragmatic for those times I find myself somewhere and have no idea what to do if I have an hour to wander about. (Sometimes we all need a bit of a start, or a script to follow.) And of course, it’s playful in it’s nod to the Situationists and their experiments with re-imagining urban space.

The principles led directly from the Drift Deck: Analog Edition that you can find here and more here.

These are the kinds of projects we do here. They’re not “Conceptual.” That cheapens the hard work that goes into them. We write code. We do illustrations of things that get properly printed on big Heidelberg presses. We put together electrical components and have printed circuit boards made and populated with parts to create new sorts of interaction rituals, new sorts of devices — new things that are different from the old things. These are ways of evolving the ordinary to make possibily otherworldly, extraordinary things. They come from ideas that we then evolve into material form so that the ideas can be held and dropped and switched up, on and off to be understood properly.

So, just to be clear — Drift Deck isn’t a conceptual bit of wankery. It’s a thing that got made. Ideas turned into lines of code turned into compiled bytecode. Oh, look! It’s running on my iPhone! Doesn’t feel very concept-y to me.
Continue reading Interaction Awards 2012: Drift Deck for People's Choice

Quiet But Not Quiescent

Judge not the less yammer-y state of the studio blog to indicate that there is nothing worth yammering about. It’s just that the clang of steel caressing code has been going on and that in great measure, too. Some of you may have glimpsed and grinned at the fantastic electronified edition of the paper Drift Deck that we developed a couple of years ago. That’s right. We’ve added *batteries to the Drift Deck and it’s fallen into the *app well..it’s an app which is fantastic because it means the last remaining physical card editions can become properly *artisinal and the electronic battery editions can spread the sensibility of the Drift Deck concept to the rest of the world.

Release is imminent. Prepare ye iPhones. Hop expectantly from foot-to-foot. More news in a short while, including linkages to downloadables. In the meantime, check out the new Drift Deck webified “page” and the fantastic roster of hammererers that batteryified the ‘deck.

..And then — onto the next thing here. It’ll be quiet a little, but good things are baking in the kiln, rest assured.

*Willow next. The superlative friendregator for the discerning social being.
Continue reading Quiet But Not Quiescent

A Curious Crosswalk Clarification

A curious inscription left by someone to clarify which button expedites which crosswalk signal. Someone has written with an indelible marker “B” and “W” on each button (for Broad Street and Watchung Avenue respectively), as well as writing an abbreviation on the pole (“WAT”, for example.) What is interesting here is that an official sign also indicates which direction is controlled by the button (“Push button to cross *arrow* Watchung”) making me wonder if this was an addition made after some complaints about the confusing buttons. What made this confusing initially was probably the fact that there are two crossings in roughly a straight line. You cross a small bit of one-lane street that subsequently does an easy turn onto Broad Street from Watchung, and then stand on this island with the buttons. Then you cross a larger street — Watchung Avenue proper — with several lanes. Approaching the island after a nervous crossing and then looking out into a daunting sea of fast-moving traffic on your way to a quick sugar fix at Holsten’s, you might think the first button you see is the one to hit, which would be wrong.

Why do I blog this? I find these sorts of thoughtful, improvised inscriptions fascinating. A different kind of “read-write” city or read-write urbanism, where people in their everyday moments take it upon themselves to make additions, hacks, DIY improvements and adjustments to make the city more livable and agreeable to their sensibilities. The points where urban design from the top-down meets urban living from the bottom-up.
Continue reading A Curious Crosswalk Clarification

Beyond Public Toilet Maps — Prehistoric Augmented Reality Devices

A small collection of historic augmented reality devices, found during a rake through a flea market in Paris with fellow Urban Scout Nicolas Nova last Saturday. Mostly bashed up, broken things — but evocative devices that, when run up against all the excitement surrounding “Augmented Reality”, suggest more to me than the more typical, canonical — hold-my-flat-screen-mobile-device-up-in-front-of-me mode of operation.

Tactically, the evolution of mobile practices like this might learn from the everyday pre-historic rituals, such as gazing through a telescope which, in its infancy, was probably quite close to a kind of augmented reality. It allowed merchants to gaze to the horizon while sitting at port to see what ships were coming in, with what loads. The more speculating merchants could foresee shifts in the local markets because cotton was coming in and eek out their profits with the foresight brought to them courtesy of their expensive, privileged optical devices. A kind of future-seeing device used to their advantage.

Today’s augmented reality has none of that sparkle and magic. The visions of the AR future as best as I can tell is overturned by the fetish of the technology. This truly is a bad approach to making new kinds of worlds. The instrument comes first — a display, compact electronics, embedded compass and network connectivity — are what guide the vision and the “scenarios” (if you can call them that) entail something that basically is an expensive way to ask someone standing right next to you, who probably speaks a language you speak anyway — where the nearest public toilet is. Or where the metro stop is. Or in what direction the museum is. All of these things are problems that have been well-solved and need no tax imposed upon them like data roaming fees, or the inconvenience of a [[bad network/crap GPS signal/annoyance of dropping your $500 toy//&c]].

Augmented Reality in this mode of “design” is a bit like finding a nice door knob…and then looking for the house that looks good around it. Starting with the door knob — the instrumental technical stuff — is a really bad way to design a house, I think.

Why do I blog this? Poking and prodding at a more satisfying set of metaphors, language, histories for what a looking glass / viewmaster / binocular of the near future might be and what lessons it might learn from its prehistoric kin. I’m curious about the possibility of learning from the evolution and development and cultural valance of these earlier devices — considering them in the mode of a magical, exciting bit of technical kit from their time. But what did they do and how were they used? How much of the device and technical characteristics guided what they became, like today? Was someone walking around with some carefully, expensively constructed optics, not entirely sure what to do with them? Or not sure how to sell them to people? How were they to be assembled, technically speaking? What was the level of knowledge of combined optics — was it similar in its sophistication and arcane incantations like programming embedded devices and mobile phones today? What did it take for someone to use the telescope as something other than a device for starring at the moon or constellations? And other questions like this…what can be learned from shifting contexts, moving to historic moments, fictionalizing alternative possibilities for those histories, or fictionalizing the near future of these weird “augmented reality” speculations.

What might “augmented reality” augment besides directions to a public toilet?
Continue reading Beyond Public Toilet Maps — Prehistoric Augmented Reality Devices

Design Fiction Chronicles: Urgency and Emergency, Notification and Warning

Tsunami Evacuation Route on Washington Boulevard at the border — basically 60 degrees North-North-East, directly opposite the coastline in the other direction, but essentially only a few meters above sea-level for a good couple of miles.

Last week, when there was that earthquake in Samoa, we happened to be talking about Tsunamis in the studio — thinking about the ways that the California coast could be gobbled up in an unfortunate, epic disaster. It’s a distinct possibility, and with the Pacific Ocean popping off earthquakes with increasing frequency (or so it seems..), it makes one think about what sort of early warning system could be put in place — and one that would not rely too much on quite fallible technology-based networks. These are the things that typically fail even without a disaster at hand. (For instance, at the Venice Beach Music Festival a few weeks ago, with a relatively smallish contingent of people occupying Abbot-Kinney Boulevard, me and those I was with were hard-pressed to get a cell signal. If you have all of Venice Beach panicking because of an approaching Tsunami, what are the chances AT&T will be able to handle the load? I’d rather not count on them, to be perfectly honest, to help me communicate with family in a disaster.) Perhaps mesh-y networks that do not rely on too much pre-built systems like cellular base stations.

Or, are there more esoteric warning systems, like these rattling cups? Hairs on the back of your neck? A forest of yammering, naddering wild life suddenly falling dead still and quiet? The color of the sky in the morning? Scattering insects all going in the same direction? A sudden feeling that comes from another array of sensors — ones not invented by scientists or technologists or relying on a functioning grid of power, communication and all that?

What are the other “weak signals” of impending disaster, besides the news?

These fictional moments in movie scenes popped into my head while thinking about early warning of impending disaster.

Why do I blog this? Place marks for ideas related to early warning systems and the stories around them. Signals that are not explicit, but suggestive, providing some clues and cues that force one to be more attentive and resilient and resourceful.
Continue reading Design Fiction Chronicles: Urgency and Emergency, Notification and Warning

Interoperability

A curious interoperability protocol, wherein the address for some weird place in Seoul has been found on an iPhone and must now be entered into the GPS of the taxi. A simple affair, with minimal bumps often enough, particularly because the map on the iPhone shows the address and streets in Korean, which is great for the taxi cab driver, but miserable for the the traveler who can only hope that the locale on the map is actually where he would like to be.

Why do I blog this? This are useful moments to capture, where language, culture, objects, data come into conflict and must work their way around one another. I am told the iPhone isn’t available in South Korea at the time of this photo, so you have this foreign object — one that is probably quite legible as the iPod Touch was spotted around the city — and a baroque assemblage of devices, machines, transaction mechanisms, remote controls, identity stickers, car controls, radios, etc. I would have to contrast this with the notion of seamless perfection and interoperability that is often the image of the future transportation dashboard.
Continue reading Interoperability

Street Furniture

Times Square beach, complete with tourists (as any beach should), found here.

Urban Lounge found near Madison Square, New York City.

This is probably old hat for current New Yorkers certainly, and something that makes visits home really interesting, these street furnishings and people zones are incredible interventions and nice experiments about alternative urban landscaping. When arriving in Times Square with my brother for a quick screech through of High POV shots, we managed to get one of these curious middle-of-the-avenue parking spots so you basically park right smack in the middle of Times Square. Which is good because you cannot drive through the square itself, only around it, because of these pedestrian urban “beaches”, complete with lawn chairs. According to one of the local business improvement district rangers or whatever they are, tourists quite like it. I wonder if locals find these useful or an annoyance to their conveyance around the city.

Not quite the same, but in a different category of street furniture — the dispensed with sort.

Why do I blog this? A fascinating example of a reconfiguration of the canonical gridded city. Turning pavement into a more human, habitable space that evokes other leisures is a fantastic way to create new opportunities and to think about new sorts of design practices for urban space. This is an area that many people are curious about of course, and it is something that has attracted the attention of the laboratory quite a bit recently. For some reason, we have been thinking about new kinds of principles, rituals and scouting toolkits for finding new ways to look at the city, using these to think about new kinds of interactive urbanscapes…and not interactive in the “UX” sort of digital-y way. Playful interactions, thoughtful interactions — new rules of occupancy; new social interaction rituals.

GPX to DXF – Drawing GPS Tracks

Lines and arrows and splines point the way. Taken in a parking lot near the beaches at Santa Monica.

It has not been a quiet couple of days here in the Laboratory. Lots of gear and glassware about. Goggles, bunsen burners and all that sort of thing. And the report draft was just finished with Nicolas Nova, which occupied many early mornings. We almost spilled an organic, but toxic material on the draft which cause a collective gasp, but it was pulled out of the way, just in time before irrevocable damage was done. We’re writing with ink and pen these days, which feels so much more angelic and respectful, but are, through incidents like this, reminded that such may have nostalgic integrity, but it is also quite delicate and precious.

In the midst of all that was the need to translate a GPS track from GPX format to DXF. This was harder than I thought it would be, at least after poking around the Google. There are some tools that’ll do format conversions and so forth, but they were way more expensive than I thought was reasonable, seeing as we’re not making precious objects. It’s basically a translation of one connected graph format to another.

Okay, so — it was time to think about making our own tools, which took 10 times less time than the original set of Google searches, mostly because of the recently discovered ancient treasure of a Java library our buddy Tom Carden wrote back in the Precambian of the Age of the Network — somewhere’s around 1996 or some such…

This library provides enough functionality to read a GPX track and draw it on screen. The Processing.org DXF library can spit that drawing from the screen out as a saved DXF. So, that basically solves the problem. The DXF files that come out are flat lines that can then be serviced by other software to do other things. (There also exists this Kabeja library for consuming DXF and creating DOM models, which we’ll save for another day.

My lead toward the Carden code was found here on the Processing.org forums, where I found enough of a simple code snippet to get me out and through the chiseled hole in the brick wall I had hit.

Also to note is the small comment in the small simple bit of code that can cobble together many separate GPX files (tracks from a GPS) into one larger one, which can be quite convenient.

Why do I blog this? Mostly for my own recollection and notes as to how things are done. It’s been enough time in the jungle of small, utility challenges that, when on another project inevitably in the future, some small task I need to perform smells familiar — but, why? One gets the feeling — I’ve had to do this before? What project was it? How did I do it? Playing in the geo/map-making/cartography space has all these little formats and translation steps that are a bit zany to wrangle. Jotting a post with a bit of a reminder helps. Te bigger “why do I blog this?” has to do with using real-world GPS tracks as a basis for constructing other things — the input is movement in the world, an effort to figure out how a map might look that inverted the assumptions about static geographies and fluid movement, so that the ground moved and the things that moved became static. *shrug*


import processing.dxf.*;

// Based on Tom Carden's code and GPX library available at
// http://www.processing.org/hacks/hacks:gpx
// Press "R" and your track gets saved as a DXF file which
// you can use in lots of other things..

import tomc.gpx.*;

GPX gpx;

GPXTrack track;
GPXTrackSeg trackSeg;
String trackName;

double minLat, maxLat;
double minLon, maxLon;
double minEle, maxEle;
boolean record = false;

final static int SEPARATOR = 200;
String filename, filepath;

// I collapse lots of individual GPX files into one larger file
// using the free gpsbabel.
// At the command prompt (the GUI editions don't have enough features
// to do this) you'll do something like this:

/************

/Applications/GPSBabel+-1.3.5/gpsbabel -i gpx -f 20090321.gpx 
-f 20090401.gpx -f 20090402.gpx -f 20090403.gpx 
  -x transform,wpt=trk,del 
  -x radius,distance=5,lat=34.0236,lon=-118.4319,nosort 
  -x transform,trk=wpt,del  
  -o gpx -F foo.gpx

The "-x" filters do a couple of things.
The first -x filter turns the tracks into waypoints to work around
an issue that gpsbabel has with the "radius" filter
The second -x filters the output only to points that are within a
5 mile radius of the specified lat/lon, which is useful if you want
to limit the range of data you draw.
The final -x filter turns the waypoints back into tracks, which is what we want
Finally, we output as GPX formatted data and
write the whole thing to the file called foo.gpx.dxf


*************/

void setup()
{
  // Yep, hardcoded path to the GPX file we'll process
  filepath = "/Users/julian/Desktop/GPS Tracks/foo.gpx";
  // We'll use the name of the file for our DXF output, with the ".dxf" extension added
  filename = (new File(filepath)).getName();
  size(800, 800, P2D);
  gpx = new GPX(this);

  // you can load a file or a URL evidently..
  gpx.parse(filepath);

  // Find scope of track file so we can scale our drawing
  minLat = 2000; minLon = 2000; minEle = 100000;
  maxLon = -1000; maxLat = -1000;

  println("track count "+gpx.getTrackCount());
  for(int j=0; j < gpx.getTrackCount(); j++) {
  track = gpx.getTrack(j);
  println("track size "+track.size());
  for(int k=0; k<track.size(); k++) {
     trackSeg = track.getTrackSeg(k);
     println("track seg size "+trackSeg.size());
  for (int i = 0; i < trackSeg.size(); i++)
  {

    GPXPoint pt = trackSeg.getPoint(i);
    if (pt.lat < minLat)
    {
      minLat = pt.lat;
    }
    if (pt.lon < minLon)
    {
      minLon = pt.lon;
    }
    if (pt.ele  maxLat)
    {
      maxLat = pt.lat;
    }
    if (pt.lon > maxLon)
    {
      maxLon = pt.lon;
    }
    if (pt.ele > maxEle)
    {
      maxEle = pt.ele;
    }
  }
  }
  }
println("Lat: " + minLat + " to " + maxLat);
println("Lon: " + minLon + " to " + maxLon);
println("Ele: " + minEle + " to " + maxEle);
}

boolean hasDrawn = false;

void draw()
{
  if(record == true) {
    beginRaw(DXF, filename+".dxf");
    hasDrawn = false;
  }
  if(hasDrawn == false) {
  background(255);
  //stroke(#FF0000);
  //line(0, SEPARATOR, width, SEPARATOR);

  double distance = 0;

 for(int j=0; j < gpx.getTrackCount(); j++) {
  track = gpx.getTrack(j);
  //println("track size "+track.size());
  for(int k=0; k<track.size(); k++) {
     trackSeg = track.getTrackSeg(k);
     //println("track seg size "+trackSeg.size());
       GPXPoint prevPt = trackSeg.getPoint(0);
      PVector prevPos = GetPosition(prevPt);
      for (int i = 1; i < trackSeg.size(); i++)
      {
       GPXPoint pt = trackSeg.getPoint(i);

    // Show track
    PVector pos = GetPosition(pt);
    stroke(#FF8800);
    line(prevPos.x, prevPos.y, pos.x, pos.y);
    prevPos = pos;
  }
  }
 }
  }
  if(record == true) {
    endRaw();
    record = false; // stop recording to the file
    println("done writing "+filename+".dxf");
  }
  hasDrawn = true;
}

void keyPressed() {
  if (key == 'R' || key == 'r') {
    record = true;
  }
}

PVector GetElevation(int n, GPXPoint pt)
{
  return new PVector(
      map(n, 0, trackSeg.size(), 10, width - 10),
      map((float) pt.ele, (float) minEle, (float) maxEle, SEPARATOR - 10, 10)
  );
}

PVector GetPosition(GPXPoint pt)
{
  return new PVector(
      map((float) pt.lon, (float) minLon, (float) maxLon, 10, width - 10),
      map((float) pt.lat, (float) minLat, (float) maxLat, SEPARATOR + 10, height - 10)
  );
}