Link: http://onebusaway.org/

TL;DR no routing; useless in Philippines

OneBusAway is a transit information app. It provides data on what bus stops are near you, which buses pass by. You can also get schedules and the route of a particular bus given the number. It can also provide realtime updates like how many minutes until the next bus arrives. It does not, however, provide routing. There is no support for providing directions to get from point A to point B.

It’s comparable to what you get in some bus stops abroad. You’d get a vicinity map and a list of buses passing through the stop. You might also get the times when the next buses will pass. It’s useful for locals who already know how to get around, and want to avoid waiting for the bus. But it’s not particularly good for people who want to know how to get around the city.

OneBusAway is quite comprehensive in its platform support though. There is a webapp, apps for iOS, Android and Windows Phone, as well as SMS and Voice support. This would all be nice but we don’t have the necessary infrastructure yet in the Philippines. We don’t have bus or jeepney stops. We also wouldn’t have realtime data to make the app particularly useful.

You can try it out for yourself by following their Quickstart Guide. One caveat is you will have to add -P tripEntriesFactory.throwExceptionOnInvalidStopToShapeMappingException=false when building the bundle. This has to do with the OneBusAway having difficulty matching the stops to the shape data.

Here’s some screenshots of the app with the Philippine data. Notice how you only see the stops but there isn’t a line for the route. This is a problem with our GTFS data. Also, at some points it’s hard to tell where the jeep is going to pass since there isn’t any indication of order either. This is more of a OneBusAway problem. It usually expects there to be shape data available.

It doesn’t really handle too many routes passing through a stop. The list just overflows past the bubble. You can still actually read it by panning the map. It’s just a bit weird though.

If you also noticed, there are usually 2 of each route. This is how the jeepney data was modeled as jeep routes might be different going one way and going back. This isn’t the case for all jeeps though, so it might also be an implementation issue with the GTFS editor.

Link: http://www.opentripplanner.org

TL;DR routes pretty well; data might cause weird issues

OpenTripPlanner, as the name implies, is a routing app. Given point A and point B, it can provide possible routes by taking transit, riding a bike, or a mix of both. You can also specify options on how much walking you’re willing to do or if you prefer fewer transfers over trip time. It could be a good competitor to the transit directions of Google Maps.

It’s actually in general use by the Trimet, Portland’s public transit system. I think a good reason why they deployed OpenTripPlanner is that Portland is a very bike friendly area. OpenTripPlanner’s support for multi-modal (bike + transit) routing is one thing that even Google Maps doesn’t have. This actually just screams Inclusive Technology Award.

Setup

Getting OpenTripPlanner up and running involves a bit more downloading than OneBusAway. I’d suggest going through the 5-minute introduction if you want to actually work with the Philippine data. You will also need to download the Philippine data dump from OSM. You will want the osm.bz2 one (WARNING: 900MB unzipped).

Once you get the webapp running, you’ll notice the map tiles won’t load correctly. This is because the default tileset used is from Mapbox which doesn’t provide publicly free tilesets anymore. To actually see things on the map, you should click the + on the upper-right of the map and change the base layer to something like Open Street Map or OSM Mapquest. This has been fixed in their latest sources.

Issues

The next thing you’ll notice is that you can’t search for a place. You can only just pick points on the map and route between those. I’m still not exactly sure if it’s supposed to have it, since the Trimet one has it. But even then adding it by using the Google Maps or MapQuest APIs shouldn’t be too difficult.

Another missing thing compared to the Trimet planner is being able to look at the routes akin to OneBusAway. And even then, Trimet’s implementation isn’t as good for exploring as OneBusAway is. Seeing the schedule or seeing which routes pass through a stop are left to an external site to do.

There have been some weird issues with the routing though. A common occurence is the steps are somewhat disconnected (see image below). The left half shows OpenTripPlanner, it shows that you get off at a “stop” in EDSA and you should magically teleport to Arguilla street and start walking. To be fair, Google Maps (right half) shows that there is a street from the “stop” to Arguilla.

I can’t say this isn’t a bug. After all, OpenTripPlanner couldn’t have magically known there really was a street there. If it did, it wouldn’t just teleport you to the corner. I’m more inclined to think though that this is a result of not having any shape data. As a result, OpenTripPlanner might try to assume the stop could mean places within a certain radius of where it was defined.

Another weird issue that pops up sometimes is where it tells you to ride a jeep past the stop you want and then after a while, get off and ride a jeep back to your stop. A more general issue is that sometimes it won’t give you the best route because it thinks you have to loop around to get to where you want to be. I don’t really know how common this issue pops up though. It’s highly dependent on where you put the marker. If you just move the marker down a little bit, it actually does give the correct route.

Much like the earlier problem, I can’t tell if this is a bug or it’s a result of the bad data. Once again though, I think the issue is more of bad data. If you look at the plotted UP-Katipunan route, the stops aren’t even on the road. This probably makes it more difficult for OpenTripPlanner to actually tell if the stop and road are connected.

From what they said during the launch, most of the route data was collected by getting a person to ride a jeep with a smartphone. That would explain why the coordinates aren’t that exact. Even then, it would have been nice if they at least cleaned up the data by moving the stops to the road. They would have had to go over them to name the stops anyway.

Conclusion

Overall though, I really like OpenTripPlanner. It handles most of the hard parts of the challenge. It provides a REST API for doing routing with the GTFS + OSM data. There’s also a lot of potential for additional open source work. A lot can be done to improve the default webapp. Adding a default location searcher would greatly improve usability. Adding in the route viewing features of OneBusAway would also be nice. Alternatively, you could even write your own client that just interfaces with the API.

In the last post, I talked about how we now have data about jeepney and bus routes in the Philippines. The data is actually in the GTFS format, which is the format the Google Maps consumes transit data. Apparently, the government will be submitting the GTFS data later this year. Transit directions for Metro Manila in Google Maps would be wonderful. That said, it definitely raises the bar for the app challenge people.

In the last post, I mentioned the quality of the data isn’t quite good. Even before seeing the data, I was already a bit unsure of it. The key problem is how you model the routes. The GTFS format was inherently designed for more well developed and organized transit agencies which isn’t exactly what we have in the Philippines now.

One potential problem is the nature of the jeeps and buses. GTFS routes are a collection of trips which are a sequence of stops. However, we don’t have jeepney stops, and even if we did they still just stop anywhere. There are also times where jeeps will take a shortcut if no passengers need to get dropped off along their normal route.

From what I’ve seen of the data, they handled the first problem well enough. Stops are defined as where people typically get on the jeep or bus. This is good, but they didn’t define a shape for the routes. There is no information as to which exact roads they pass through. All we have to go by are the stops to show the route on a map.

The problem isn’t that bad though. The agencies could still add the shapes later on. Or maybe an app challenge participant could make an app around fixing the routes via crowd-sourcing or similar. The shape itself isn’t that important for a rudimentary directions app, but if we want better apps, we will need better data.

There were also some minor issues with the data itself. Some of the files had extra columns. This normally isn’t an issue, but it caused problems for GTFS SQL importer. There were also problems with matching the shape data with the stops when I tried it with OneBusAway. They could probably be fixed but that’s for another day.

Last week, the DOTC launched the Philippine Transit App Challenge. It’s a competition to build something great using the newly available 1) jeepney/bus/rail routes and 2) traffic incident data in Metro Manila and Cebu.

I’m actually quite excited about this as it’s not everyday our government does wonderful things. Many people have been waiting for this kind of data to be available. Before, the only way to figure out which jeeps to ride to get from A to B is by asking other people. The website of the LTFRB used to just have a list of jeepney routes, but nothing else, no maps or list of stops.

During the launch, they also presented how CITOM (the Cebu MMDA) is pilot-testing a traffic tracking system. What they did was supply Android phones to taxi drivers. The phones send GPS data which can then be aggregated to see what the average speeds along streets are. This also benefits the taxi company as it provides easy tracking of their taxis compared to their old telephone/radio with pen-and-paper process.

The route data are already available, as well as the Cebu and Metro Manila incident data. You do have to register to access them though. Right now, they’re just one-off dumps of the data but the various agencies have promised to provide consistently updated data. This will be provided via ASTI later in the year.

I’ve just started looking at the route data and playing around with it. The quality could be better, but I’m glad we at least have something to work with.