Post has attachment

Post has attachment
Transit Screen Brings First Multimodal Transit Displays to San Francisco Bay Area - Displays include Muni (Buses and Metro), AC Transit (Oakland, Alameda Co.), BART, Emery Go Round & Dumbarton Express

Post has attachment
the German #OpenKnowledgeFoundation has its own g+ community now! come and join the keep posted...

Post has attachment

Post has attachment

Post has attachment
This could be an opportunity to gain some momentum and gain some members. 

"White House Announces National Day Of Civic Hacking, Asks Americans To Solve Problems With Govt Data From NASA And More" (TechCrunch, January 22):

"The White House wants you to hack for a better America. Today it announced the National Day Of Civic Hacking on June 1-2 where many government agencies will liberate data for citizens across the U.S. to use to build tech that helps their communities. Twenty-seven cities have planned events where hackers will have access to data from The Department of Labor, The Census Bureau, and even NASA’s space stats."

Post has shared content

G+ now includes a new community feature, designed for people with similar interests to share links, photos, and other content with each other.  I wanted to try it out, so I figured I would make a community around a subject near and dear to my heart: open transit technology.  Admittedly, I'm not sure how this will work differently than a blog vs a email discussion group vs that +Brian Ferris - Transit page I occasionally post to, but let's see.

Post has attachment
tl;dr - Public Transit Fare Systems are complicated!

I do a lot of work with the GTFS spec (, a data specification for sharing public transit information.  Historically, one of the areas where GTFS has struggled is in the area of fare modeling: aka, how do you pay for your ride?  This is both a reflection of some deficiencies in the spec, but also reflects the fact that public transit fare models seem to be like beautiful snow-flakes: no two are alike ; )

Every so often, a new proposal comes up on the GTFS Changes mailing list for extending the current GTFS fares specification, and I always get the feeling that we're just rearranging the deck-chairs on the Titanic.  There are just so many edge-cases we're not handling and I don't think we'll eventually end up with a spec that covers all of them if we do it piece-meal.

For that reason, I started a GTFS Fares Working Group this summer to try to take a holistic look a fare modeling in GTFS and how we might cover more fare systems.  We're certainly not the first to look at fare modeling (see for example), but maybe this time it will be different? ; )  We've got a mailing list!forum/gtfs-fare-wg and a plan:

1) Do a literature search of existing fare models, fare data standards, and other existing work to map out the space of fare systems we'd like to cover. 
2) Run the results of #1 by the larger community to see if we've missed anything.  Iterate and repeat.
3) Stare really hard at the wall to think about how we might model these fare systems in a GTFS-friendly way, either extending the existing fare model or coming up with something new as needed.
4) Assuming heads don't explode in step #3, profit.

Currently, we're in the middle of step #2.  We've compiled a list of common properties, features, and idiosyncrasies of transit fare models:

It references examples from transit systems from around the world that GTFS currently has trouble handling.

Want to contribute to the process?  If you know of a transit system with a particularly convoluted fare system, we'd love to hear about it!  We're still looking for examples of systems that will be tricky to model, so the more the merrier.

Once we've got a better idea of the full scope of the problem, then the real fun begins: how do we model this all in GTFS?  What should we model?  What should be left out?

My personal base goal is to be able to model a standard adult base fare for most any transit system in the world.  However, there has also been a lot of discussion about modeling different fare products and fares with different eligibility requirements.  These definitely add yet another layer of complexity to things and I have a lot of open questions about how this information could even be used in applications in a consistent way, but it's definitely on the table for discussion either way.

So we've got a lot of work left to do, but my one take-away so far is simple: public transit fare models are complicated ;)

And I guess it goes without saying, but if you are into Open Transit Technology as well, feel free to join up and post.
Wait while more posts are being loaded