Sometimes as I’m browsing through the too many RSS feeds I subscribe to, I’m struck by an interesting intersection between two items from different sources.
That happened this weekend when I noted this comment (from regular commenter Dave H) on the open thread:
I’m not sure if anyone here is familiar with QR Codes, but I was wondering about the idea about posting them at TriMet stops as Smart Phone use increases.
The iPhone, Android, Symbian and Palm platforms all support it with free applications (Android has native compatibility, as far as I know), so I’m wondering is this maybe a way to directly link a user to Transit Tracker information for the stop they’re at?
It’s an open and free to use standard, and it would make things really easy for users if all you have to do is aim your phone at a Transit Tracker QR Code to figure out when the next bus shows up it seems like an easy way to gain some choice riders.
If we can be bothered to post route info at every stop, is this maybe an easy way to help make the Smart Phone more transit integrated? I’m sure with GPS you can do similar things for finding next trips, but it seems like a way to move Transit Tracker from display boards to the pocket at a minimal cost.
This struck me as interesting, because it could probably be easily accomplished as a community project – it would just take a good mail merge program to produce labels with QR codes from TriMet’s GTFS files.
But could we do something beyond just Transit Tracker with it?
Then I came across this article (via @caseorganic) on the “City as Software” concept. It suggests that real objects in the urban environment should be “addressable and queryable”.
QR codes would clearly provide one convenient form of addressability. But what about “queryability”. What would we want to query from a transit stop beyond next arrivals?
Ideas?
22 responses to “The Addressable, Queryable Bus Stop?”
One of the components of the Chicago Transit Authority Bus Tracker system is that you can “query” the bus stop’s upcoming bus arrival times.
On every bus stop “flag” (sign), there’s a message that says, “Text ‘ctabus XXXXX’ to 41411.”
You will receive a text message within 20 seconds that lists the arrival times of the next 1-3 buses, for all routes that serve the stop.
This method is more accessible than others, and possibly faster. Save your most visited bus stops as text templates to get results quicker.
(Only a third of Americans with mobile phones have smartphones.)
How is that different than TriMet’s existing SMS service?
The focus should instead be on delivery of public transportation revenue service. That is, if there’s money to either increase service on a route for everyone or to implement some high-tech gadget usable only to a subset of the population, then by all means service should be increased.
With all the technology out there these days, we’re losing focus on what a transit agency should be doing.
Jason, I haven’t suggested that TriMet do anything. I think this could be a community project. So what could the community do that would make the transit riding experience easier or more useful?
Well, if you want suggestions for “queryable” beyond finding out projected arrival times, imagine that every major bus stop with a shelter (if it’s major and has no shelter, why is that?) gets outfitted with weather sensors and a webcam or two.
Before heading out to your stop, you could see who’s hanging about, how cold it is, if there’s room to sit, is there trash that needs pickup (click to report to agency), etc.
I don’t think I’d prioritize that over other discretionary expenses which could serve riders, but that’s what comes to mind when I think “queryable bus stop”.
I can’t think of much of anything I’d really want to query from the stops themselves. Stuff like arrival times are more like querying a the next bus, or the transit system at large, in the context of one of the stops. If that kind of thing is on the table, I’d like to see them add to their existing APIs information allowing me to find out which stops have benches, rain protection, that kind of thing before I arrive at them.
Also, when looking at arrivals I want to know if the bus has air conditioning, if the next MAX is a Type-4, if the bike rack on the bus is full.
Jason,
Is it your position that all of this stuff is irrelevant to the “transit-dependent” (I put the term in quotes because, as Jarrett notes, it’s not a binary condition) rider, who will be waiting at the bus stop for the next bus, whenever it comes and no matter the circumstances?
Interesting, I was just talking to Max Campos about this very subject yesterday.
I’ve been working on a pilot for QR codes that would be included at stops with other information. My intention is to link to the existing mobile TriMet page for that stop, which includes links to schedules, maps, arrivals and even trip planning. It’s ridiculously easy to set up, although it should be noted that there are roughly 8,000 stops in the system.
Aaron should note that those existing pages already include stop amenities. I’ve always thought the most useful information to be added would be real-time information about capacity on a given vehicle.
This has been done before:
http://www.tbsh.info/stop_-_east_sf_bay.html#emery
Huh, cool! I actually wasn’t aware of that information. Is it exposed through any of their APIs?
Jason: The nice thing about using QR codes is that the cost is a little more ink on each sign. The technology cost is on the user.
Yes, only one in three cell phones currently is a smart phone, but that will change over time. The people who do have them now are typically higher-income, but that also means that they’re more likely to be choice riders I have to assume.
As Jeff mentioned the web sites are already there. The codes would just need to be generated, printed and posted.
The nice thing about using QR codes is that the cost is a little more ink on each sign.
[…]
The codes would just need to be generated, printed and posted.
I doubt anyone working at TriMet would do that work for free.
Is it your position that all of this stuff is irrelevant to the “transit-dependent” rider[…]
No, my position is it has nothing to do with delivery of public transit services.
How about publication (paper or online) of route maps and schedules? How about apps like TransitTracker? None of these things, by themselves, move anyone from point A to point B, but make it possible to use the system.
Certainly, TriMet shouldn’t bust the budget on ancillary things–but part of delivery of public transit service is communication and not transportation. Where should TriMet draw the line between needed communications of system information, and the frivolous stuff?
No, my position is it has nothing to do with delivery of public transit services.
Perhaps with a very strict definition of “delivery”, that might be true, but what’s it matter? That kind of thinking could be used as an argument against bus shelters or schedule information being available. I don’t really get the hostility towards improving the user experience on the bus system. Nobody seems to get mad at people grabbing the paper schedules TriMet is constantly printing out, why y’all gotta hate on the technology?
(And I think this kind of stuff really does improve the transit system. Being able to quickly and accurately predict the arrival of a bus makes my trips shorter and to an extent mitigates the pain of infrequent service.)
I’m sure that the generation of the codes could be done very cheaply if TriMet were willing to outsource it. The printing/posting thing could be done as signs are replaced. The overall cost could be made quite minimal.
I can’t imagine that would even be necessary. This isn’t rocket science. There are all sorts of free utilities that can generate these codes in every vector/raster format thinkable. If this took one coder and some kind of media person very much more than an afternoon they’re doing something wrong. The overhead in dealing with an outside company and getting them up to speed on TriMet’s processes for producing those paper signs should probably be more work than just implementing this.
While QR codes are nifty, and while I think it is absolutely worth it to display a prominent Stop ID number at every stop in the system, I don’t know if the QR codes would last. Any vandal could make them inoperable with the single swipe of a marker, whereas even obscured regular numbers can be resolved by humans with some amount of scrutiny.
Still, it’s worth a try at some stops to see how well it works and how long it lasts.
One thing about QR codes is they’ve got a lot of redundancy (and there are a few different options as far as ECC goes). I just played around and was able to read some codes I printed out and partially defaced a fair percent of the time. This, plus the fact you’d have the backup of entering the number yourself, I think makes that not so big of a deal. I’ve never seen anyone completely black out one of the digits on the existing signs with Sharpie.
There are some QR codes that appear to have been printed on a laser printer on standard paper, stapled to telephone poles, and yet they still work on the first try from my Palm that’s not supposed to be able to capture QR Codes in the first place. Oh, and these are ones I’ve seen hanging out since sometime in January or February.
If someone carries a multi-tool I’m sure they can tear into any TriMet sign used.
I hate to admit it, but I’ve known some taggers in my life. They typically aren’t looking to wreck things, just to show off that they were somewhere first. I don’t think the QR codes would be targeted anymore than schedules are now.