Mon 14 Dec 2009
Telling time with open realtime data
Posted by Joe Hughes under Data Sharing, Ideas, Mobile, Realtime, San Francisco
[22] Comments
This past weekend, I had a little bit of time to work on a hobby project:
This is my Sony Ericsson MBW-150 bluetooth watch, showing the next few SF Muni bus arrival times for a nearby stop. The code to fetch the arrival times is running on my Droid phone, and communicating with the watch using Marcel Dopita’s OpenWatch software for the Android platform.
Using a secondary display like a watch could allow a rider to keep tabs on when their bus is coming without constantly having to take their phone out of their pocket and unlock its display—particularly nice if it’s cold enough and they’re wearing gloves.
It’s also worth mentioning that a few months ago, I wouldn’t have been blogging about this. On November 7, the San Francisco MTA finally gave formal permission to developers to build apps using their realtime arrival data. Prior to that, developers who spoke publicly about their experiments with the Muni realtime data risked threats from a company that claimed a contractual right to charge for access to the arrival data for Muni’s vehicles. People were still building interesting things, but because of these chilling effects, no one outside of their circle of trusted friends would ever know about them.
Moral of the story for agencies: if you want to encourage innovative realtime transit apps in your city, read your contracts carefully, and insist on the right to provide realtime data about your vehicles to creative and energetic developers. You’ll be in good company, alongside the Chicago’s CTA, San Francisco’s Muni and BART, Boston’s MBTA, and Portland’s TriMet.
Note: this post was updated to replace the original image with an improved one on December 18, 2009.
22 Responses to “ Telling time with open realtime data ”
Comments:
Trackbacks & Pingbacks:
-
Pingback from NextMuni — Wanneer komt de volgende tram? at Alper.nl
December 21st, 2009 at 4:25 am[...] halte vrij in een handig XML-formaat. Daarmee kun je leuke dingen bouwen, zoals bijvoorbeeld een horloge wat de volgende tram [...]
-
Pingback from Link Latte #7
January 13th, 2010 at 10:46 pm[...] 4) Android to watch, Android to watch… [...]
-
Pingback from The Case for Manchester Open Data City and the Joys of Courting Corporate Philanthropy | Real Fresh TV | Social Media, Multi-Platform Marketing and Internet TV Specialists
February 5th, 2010 at 11:44 am[...] Telling time with open real time data – a public transport mashup that is transferred from a Google Android to a watch via Bluetooth. [...]
-
Pingback from OpenData : un exemple simple pour évoquer l’évidence du concept — Agence LIMITE le blog
July 4th, 2010 at 7:32 am[...] montrer que l’imagination des développeurs n’a pas de limites – et tant mieux : la montre qui donne l’heure de passage des trains en temps réel ; c’est à San Francisco que ça se passe et là comme ailleurs, les contraintes à lever [...]
-
Pingback from L’opendata dans tous ses états – Juillet II «
July 12th, 2010 at 5:47 am[...] Telling time with open realtime data [...]
-
Pingback from Tekst NRC.next-artikel openbaar vervoersgegevens at Alper.nl
October 27th, 2010 at 3:02 pm[...] waarop je kunt zien waar je fietsen kunt huren. Dit gaat verder dan je telefoon: mensen bouwen horloges met daarop live vertrektijden van haltes in de buurt, gratis SMS- en telefoondiensten en een Augmented Reality-weergave van metrolijnen bestaat ook al. [...]
-
Pingback from MetaWatch Experiments | The Incrementalist
August 26th, 2011 at 3:47 am[...] my previous experiments in showing live bus times on an older bluetooth watch, the guys at Fossil got in touch with me, and over the past couple of years I’ve served as an [...]
December 14th, 2009 at 2:05 pm
This is fantastic! If you could package it up into some sort of project or product I would love to feature it on CityGoRound.
December 15th, 2009 at 7:04 am
Nice work Joe! Great and timely example. (reaches for twitter)
December 15th, 2009 at 8:04 am
Awesome hack, Joe!
What’s the battery life like? (I.e, could you reasonably leave this running on your Droid for a day?)
December 15th, 2009 at 10:37 am
Nicholas: In order to be polite to the server, I have it set to stop updating the predictions 10 minutes after I trigger the estimates, but that could be tuned. (One of these days I want to try piping realtime data through PubHubSubBub to improve responsiveness and scalability.) I haven’t done a lot of battery life tests, since my Droid is plugged in a lot during the day for software development/debugging.
December 26th, 2009 at 5:49 pm
Dude, you are a geek. This is awesome :)
location aware watch, I can think of thousands of things you can do with that.
December 29th, 2009 at 6:53 pm
Wow… this is an awesome hack. I want one!
What does the software on the Android side of this look like?
I previously had the beginnings of a Java-for-Android library for hitting NextBus via the less-than-kosher endpoints that were the only option prior to the liberation of Muni’s NextBus data, though I found the predictions endpoint response to be pretty bloated and ended up making my own JSON-based wrapper around it which later evolved into ProximoBus, so now I have only a Python implementation.
With that said, do you have a good Java implementation of parsing the real nextbus webservice output that you’d be willing to share?
January 3rd, 2010 at 4:02 pm
Great idea! I’m head of Sales and Marketing for NextBus – we provide the real-time information that’s being shown on the watch by putting GPS units on the buses and using our NextBus algorithm and historical data (time of day, day of week, season, etc.) to predict when the next bus will arrive.
What your readers should know is that riders without this watch type but with smartphones or cell phones can set up alerts by time of day and stop to send them an alert 1 to 20 minutes before the bus is predicted to arrive at their stop. These alerts can be sent by email, SMS text, or as a pop-up on a laptop. Take a look – http://www.nextbus.com/myNextBus/ It only takes a minute to register.
January 3rd, 2010 at 4:41 pm
Larry, thanks for commenting. It’s great that NextBus has developed useful ways of getting at this information in-house. However, no matter how many good interfaces to the data NextBus builds, there will always be some ideas that you don’t have time to pursue, whether because of staffing limitations or because the ideas are only useful to a niche market (like bluetooth watch owners).
This is why it’s so great that progressive cities like San Francisco, Chicago, and Boston have opened up access to their realtime predictions, and why it’s such a shame that this isn’t the case in many other places where NextBus has deployed systems. Open data allows companies like NextBus to indirectly provide better tools to the riders in their client cities, through loose-knit collaboration with other software developers.
January 4th, 2010 at 7:31 am
Joe,
In full agreement with you. We are fully supportive of third-party developers and we encourage all of our transit customers to open up their data to the public. Our transit agency customers own the data and we do with it what they ask us to do. Our prime objective is to provide the most accurate predictions based on the real-time location of the bus and our application of our algorithm.
There are some great iPhone apps that have been developed by third-parties – GoToThere is one of them.
By the way, we’ve developed a mobile website – not an app – that, when you have your GPS turned on, shows the nearest bus stop to your phone, shows a map of the route that that stop is on, and shows another map of where your phone is in relation to the stop.
January 5th, 2010 at 11:28 am
Add King County Metro to that list, especially it’s partnership with UW including such lovely things as One Bus Away (which is apparently capable of working with anyone that gives access to the NTCIP database)
January 13th, 2010 at 9:39 pm
Very cool. Amazing what we can do with technology now.
January 13th, 2010 at 10:32 pm
Best Mr Hughes!
A most innovative string ( programme).
If there where more of you out there who will just take the step and make good use of the knowledge/skills you have,we would have many small innovation firms taking up the battle with “the Goliath´s”.Nothing bad about of being big/large/huge/enormous….. but we have many,many highly skilled people who think that they doesnt stand a chance to come out with their ideas/products.
Hope that you lead the way to many innovative people and maybe show them the way to “come out” and let your ideas make just a little difference to a lot or a great change for a few ( ex. medical use).
Great job x 2 Mr Hughes,the hack and the exposure.
From a ” Twiend ” ( Twitter-Friend) in Ericson-land.
// Don Peter
Ljungman of Revesby
August 25th, 2010 at 9:16 pm
Where did you purchase your MBW-150 Executive Edition? I ask because I got mine from an Israeli reseller and it came DOA and wouldn’t retain a charge at all. To make matters worse, Sony Ericsson is refusing to repair/replace my unit because I don’t have the “original receipt”, whatever that means. Is there any happy ending for me?
January 8th, 2011 at 10:59 am
Any chance you could detail how you managed the interaction from phone to watch? Did you connect through SL4A and openwatch?
I always had trouble with using startActivity (from SL4A API) to pass intent to openwatch… it only worked with shell “am broadcast” and never through perl/php/others
thank you
January 8th, 2011 at 6:04 pm
Giuseppe, I haven’t personally tried using SL4A with OpenWatch, but I think some friends have. You may want to watch the logs using adb logcat while you’re trying your programs, to make sure that the broadcast intent for OpenWatch are happening as you expect.