SPTrans mapper
Earlier this year, I participated in the MOOC Design: Creation of Artifacts in Society through Coursera. Part of the course is identifying a real-world design gap and coming up with a solution.
Here, in São Paulo, the public bus transport system is quite pervasive, but also badly documented in the public sphere. It’s almost impossible to figure out which bus goes where, let alone when, unless you already know. Since the World Cup Soccer, several of the bus stops now carry a list of busses that halt at a stop, but these lists only show each bus’ final destination and, at best, the days on which they run.
Paulistas (people from São Paulo) resolve not knowing which bus to take by asking other passengers or bus drivers which is the best connection. But, obviously, this information is not necessarily accurate, if not always available. What’s more, for foreigners with a limited (or no) Portuguese vocabulary, this is not an option.
The design gap I identified was the lack of public transport information at the bus stops in São Paulo.
The bus company operating the bus network, SPTrans, provides both a real time API with public transport information and a static collection of GTFS data. GTFS is a Google-driven standard for public transport information.
SPTrans apparently dragged its heels for a long time in making their public transport information publicly available, but more recently provided, first only Google with, GTFS data as well as making the API available to developers.
Amongst others, this has resulted in several mobile applications that rely on this data, in part developed during a hackathon at the start of this year. These apps, Cadê o ônibus is one of them, as well as Google Maps, are the only real way to get routing information for the city of São Paulo. SPTrans also provides this information in a searchable form online, but their interface is quite opaque and only available in Portugues.
The apps provide real-time information based on the API.
For my project, I wanted to use the API to dynamically generate information panels for each bus stop, showing:
+ A map of the area, showing nearby bus stops.
+ A map of the city, with an overlay of the metro and train network in São Paulo.
+ A list of the most important (tourist) destinations in the city, and how to get there by public transport.
+ A list of all the bus lines stopping at the current bus stop, including all their past and future stops and frequency, with, for each of these stops, the list of busses to which a traveler could transfer.
The above information could be printed, whenever needed.
Imagining the possibility of dynamic displays, drawing directly from the API, this could be extended with:
+ Arrival times and locations of upcoming busses.
So, I set out to create this, only to find that the SPTrans API was providing both incorrect and incomplete information. For example, the location of currently running busses was often incorrect or missing. But, more importantly, for many of the bus routes, not all bus stops would be available and, even worse, would not be available in the right order. (To get around the latter, I had the system monitor individual busses, storing their location at regular intervals and, from that information, I had the system infer the correct order of the bus stops on a particular route.)
The incorrect and incomplete information provided by the API is the reason the existing mobile apps are not overly reliable for real-time information, meaning that the best source of public transport routing is Google Maps, though, there, as they only rely on the GTFS data, they only provide routing and frequency data, not real-time information.
Using the API, I could not create a complete picture of the São Paulo public transport system.
I considered combining data from both the GTFS source and the API, effectively recreating the functionality built by Cadê o ônibus, and investigated a number of GTFS tools out there, but eventually decided to put this project on hold. I originally purposely wanted to use the API to create a real-time information source. The GTFS data, by design, needs to be updated regularly to remain relevant, while an application combining both the GTFS and API is the only type of application that could deliver the complete picture I envisioned.
It appears it would be possible to build static information displays only from the GTFS data, for one, it’s possible to create pretty maps, but I did not fully investigate this. For now, I’m putting this project on hold.