Fusion Tables is neat. Google describes it as ‘an experimental data visualization web application to gather, visualize, and share larger data tables’. Last year I tried out their API which was mostly based on sending SQL statements to create and manipulate tables. Recently, I looked at Fusion Tables again as part of an imminent upgrade to Mobile Logger. The API has been upgraded to “v1”, is now much more RESTful and enforces OAuth 2.0 authentication.
Once again, fired up Titanium Appcelerator to dig into the Mobile Logger source code. Every time I look at Appcerelator I’m reminded why I have opted to focus on Objective-C. Not going to get into a religious war…it just feels cumbersome. That could just as easily be attributed to my general unfamiliarity with the Titanium Studio and toolchain, since I’m otherwise using Xcode and Objective-C daily. Still, it’s much better now than when I first started Mobile Logger in 2009—using vim because Titanium did not have an IDE (or documentation, for that matter).
Back to Fusion Tables…it’s fairly easy to create a new table and import all the data from logs. Two authenticated calls: one to create the table and receive it’s ID, and another to use that ID with CSV data in a batch import. Once in Google Drive it’s trivial to map the data and play in various ways to chart the data. Nothing special, but here is a quick result from a walk in the park.
For now, I’ve only gotten a one way trip going. Haven’t tried to reconcile changes bidirectionally, or enabled updates to existing tables…but it seems like a promising start. Beta testing the next release of Mobile Logger now. Release likely just after the new year when iTunes Connect reopens. In the meantime, the code is up on github.
My second (personal) iPhone app, C10CK, is now available in the App Store. It is a clock which displays time using binary notation – the same way everything is (eventually) stored in a digital computer. I’ve been using a binary clock since a staff member of ITP passed this past year and several alumni recalled stories of the binary clock she kept on her desk and would happily explain to anyone who asked. I now keep a binary clock on my desk and think of her when people ask me what it is. (more…)
Update 2: Before using the script, ensure that you can build tesseract for your host system normally. Also, I only tested the script with the v3 release of tesseract, not svn HEAD. If you get build errors, please try with rev 498.
Update: The script has been updated, thanks mostly to the prompting of fopen2003 in the comments below. I’ve successfully tested the resulting libs in both Simulator and an iPhone 4 (both at iOS4.x) using the PocketOCR project.
After many requests, I finally got around to looking into updating the build script to cross-compile tesseract ocr v3 for use with iPhone. Here’s the script. It seems to build the static, fat library without error. I haven’t tried to update my app to use it yet, so I really don’t know if it even works. Let me know in the comments if it actually does indeed work.
Check out the svn source of tesseract: http://code.google.com/p/tesseract-ocr/source/checkout
Copy this script into the source directory and run from there
I’ve been working sporadically on the app, trying to get the next release out the door.
Currently, the last feature holding up release is the post log upload…there are intermittent timeouts occurring and I’d like to determine if there is a lightweight way to mitigate them.
This upcoming release will likely change the “real-time” uploading to opt-in. There are two primary reasons: conserve significant battery life and to alleviate the server load from new data.
The battery savings are great…I’ve gone from close to 20% to less than 10% use over a 35 minute ride.
I’m getting low on space on the server, with about 550 hours of data logged – which is awesome – thanks to everyone who has shared their log data. However, I haven’t yet had an opportunity to visualize it and am feeling a bit overwhelmed by it. Hopefully this will throttle that a bit.
Rolling the extra logged sensor data into the GPX export took more effort that it should have…but I uncovered and fixed a latent bug in the export feature, so that’s a win right? Regardless, it’s was nice to use the new issue tracker at bugs.robertcarlsen.net for real(z) for the first time. I’m looking to get several other features implemented before the next released update…planning on a few weeks. Otherwise, code is available, as always, on github.
GPX export seems to be working, and imports fine into Google Earth. This is just a basic implementation of the essentials for a route; I’d really like to include other recorded sensors somehow into the track – maybe it could be a layer in Google Earth?
Looking at the ride data here reveals just how bad raw GPS data can be between tall buildings in NYC. Several data points often share the same GPS location. It seems that moving quickly with a clear path to the sky gives the best performance.
The app also quit midway though the ride – I have to look into that.
Thanks to a (very flattering) mention of my thesis project on Gizmodo after the ITP Spring Show, the use of Mobile Logger has quadrupled in the past two days. I had been watching the number of unique users rise on the Dashboard page, currently near 800…but then wondered what that would look like animated over time.
Here’s the world map, showing events pop up chronologically. There was the initial spread on April 12th from the public release in the app store…but just wait..wait…wait…for May 12th. Fun!
(Here is the documentation for my thesis project at NYU’s Interactive Telecommunications Program. PDF version here.)
Riding through Mountains of Data:
Visualizations of Cycling
Robert Carlsen
Interactive Telecommunications Program
Tisch School of the Arts
New York University
Abstract
This project attempts to describe the cycling experiences of several riders in New York City through a series of visualizations. Specifically, I am interested to discover if riders similar to myself share a common experience through which a sense of connection could be derived.
Cyclists were encouraged to record their travels using their personal mobile devices running Mobile Logger, a custom iPhone application.
Log data was uploaded by the application to an online database in near real-time during each ride. This data was analyzed and filtered to provide source material for the resulting visualizations and system “dashboard” at http://mobilelogger.robertcarlsen.net.
Keywords
Cycling, New York City, sensors, iPhone, visualization, mapping, tracking, logging, mobile, application, bicycle
The Mobile Logger application has been public for a couple of weeks and has (surprisingly, to me) been used in every continent, save Antarctica. I first noticed several events in the database from Australia, then the UK. I was mostly catching these events by coincidence when I was looking over my own data and wondered just where (in the world) these other users were logging from.
For Earth Day, I generated a map of the global users of Mobile Logger and put it on the status page. While the historical data is really neat, and humbling to know that people all over have tried this app, the real-time data is captivating. I added the city of the most recent event and a pulsing marker to the map. Now, the location of the newest log is marked when the status page is updated. Next, I’d like to show it when several events have been logged at the same time.
That’s it for now…working on the next iteration of the visualizations. I’m thinking of some Feltron-inspired summary charts, then a more detailed array of specific data. Who knows?!