# Pleasant Programmer (old posts, page 2) | Pleasant Programmer

Skip to main content

# Highways in OTP

One of the weird things that happens with OTP is sometimes it gives absurdly roundabout routes. Here is OTP's suggested route for walking from UP to Ateneo:

This is just so hilariously wrong. It's much simpler to just walk along Katipunan Avenue.

OTP couldn't possibly be that dumb though, so there must be something we're doing wrong. If you notice, Katipunan Avenue is colored red compared to the other streets. OTP seems to be avoiding any path that goes along Katipunan Avenue. The problem might have something to do with the "road type" designated to Katipunan.

Apparently, by default OTP will consider roads of type `trunk` to be non-walkable and non-bikable. This is documented in the OpenStreetMap wiki and the OTP wiki as well. There are actually multiple ways to go about this then. The first solution that came to mind was to just edit the original OSM XML file.

    sed -i .bak s/trunk/primary/g manila.osm

And rebuild the graph. It doesn't really matter much because the OSM data isn't used to render the maps. It's just used to build the routing data. This is actually what I did for maps.pleasantprogrammer.com.

It's also possible to set the default way properties in OTP. Instead of disallowing walking and biking on `highway=trunk` we could allow that. This is not much better than the `sed` solution though. It's better since you keep the weighting done by OTP, but you're still saying that all trunks are walkable which might not be the case.

The most correct way to actually fix this is to go through each of the trunks and specifying `foot=yes` and `bicycle=yes` for those trunks that are actually walkable. You could either do this locally with the dumped data, or contribute it directly to OSM. I'm not sure on the particulars with updating OSM though.

Posted: 2013-07-24 23:15 | Comments

# Elevation Data in OTP

One thing I hadn't tested out last time was OTP's support for elevation data. It makes use of this by showing the elevation you have to traverse while walking along the suggested route. It can also take it into account when suggesting bike routes.

The 5 minute tutorial actually discusses the elevation data briefly, but a more in-depth thing you can look at is the GraphBuilder documentation. It suggests using the ASTER dataset which is free but requires registration. I just opted to use the SRTM data available from the PhilGIS website.

I don't know about the ASTER dataset, but the PhilGIS data was in the ERDAS img format. OTP only supports GeoTIFF so there was a need to convert it beforehand. You can use GDAL for this. You'd just then run,

     gdal_translate srtm41_90m_phl.img phil.tiff

Afterwards, it's just a matter of following the OTP instructions on using a local elevation dataset. The process actually doubled the size of the generated Graph.obj so it might not be ideal if you're running on limited RAM.

I've actually hosted a working example. It's pretty much at the limits of the RAM so it might be slow and unreliable, but you can test it out just for fun. Please don't abuse it though.

Posted: 2013-07-23 18:23 | Comments

# GraphServer

Link: http://graphserver.github.io/graphserver/

One other routing webapp I saw was GraphServer. It's actually more of a general purpose Graph library which supports GTFS and OSM data than an actual dedicated routing software like OpenTripPlanner. It's also based off python and C instead of Java, so it feels a lot less heavy.

The instructions on the website are already pretty good. There are just some minor errors with it. Where it says `gs_gtfsdb_build`, you should actually use `gs_gtfsdb_compile`. Also, when running `gs_osmdb_compile` you might need to use `-t` for tolerant in case you follow the instructions on chopping up the original OSM data.

A nice suggestion from the GraphServer instructions was to crop the OSM data to minimize the graph size. This is actually quite helpful if you downloaded the entire Philippine OSM dump. It reduced the original 900MB file to 135MB which was a lot more workable. I did hit a problem with their instructions though. The linked version of osmosis is an old one, which doesn't support 64-bit ids. The latest version of Osmosis easily did the job though.

The actual routing though, was not exactly good. I only tried one route which should normally take 1-2 transfers, it suggested a route which involved 4+ transfers. It also didn't provide any alternate routes aside from that one. I'm not sure if it's a limitation of the provided routeserver, but I didn't bother checking if it supported parameters which might provide better routes.

I think graphserver could be useful, but it seems more involved than say OpenTripPlanner. There do seem to be people who use graphserver for their routing apps, but for the bounds of the contest, or just as a side project, it might require too much effort.

Posted: 2013-07-23 14:48 | Comments

# Transit Wand

Link: http://transitwand.com

Overall, this was the simplest of the open-source transit tools to actually get up and running. There's already a deployed instance of the server, and you can easily download the phone app via the Play Store. Even running the server by yourself didn't have any of the hiccups I had with GTFS Editor.

The phone app is actually quite simple. It allows you to capture a trip, which will record your GPS coordinates as you ride public transit. It also allows you to mark points of the trip where you stop and also how long the stop took. Lastly, it allows you to record embarking and disembarking passengers which is potentially useful for ridership data.

After doing a capture session, you can review the data on the phone. It will plot out the route on a map, with markers for the stops. You then either delete the data if it looks wrong, or you can upload it to the Transit Wand server. Uploading involves registering an account, but it's free and you don't even actually need to put in a username or anything. It simply registers the phone's IMEI on the server and gives you a 6-digit identifier.

You can then use the 6-digit identifier to view the data on Transit Wand's server, which is good since uploading any data automatically deletes it from the phone. There really isn't much else you can do with it though. It just allows you to view the data, and export it as a Shapefile.

As is, this is purely a data collection client-server app. Barring looking at the database, there is no way to get a list of phones which have collected data. Only the person who initiated the data collection knows the 6-digit code to view their data. There's also no way to extract the ridership information from the server yet. This isn't to say that the data won't eventually go public though.

An interesting thing you can do with the Transit Wand data is import it into GTFS Editor to make a new route. You don't even have to manually download and upload the data. Just type in your 6-digit identifier and it will give you a list of routes you've captured via Transit Wand. This is wonderful as you get all the stop data, as well as the shape of the route.

I imagine these two tools were how the DOTC came up with all the GTFS data we have now. What I don't understand is why the shape data isn't present. Importing from Transit Wand already gets you shape data. There are even facilities to edit the shape within the editor if clean up is necessary. The only problem I saw was the fact that you can't easily move stops, you have to input coordinates to change the position.

It might also be possible that when the DOTC was still collecting the data, the route collection or editing features weren't present yet. That would just be lame and depressing though.

Overall, Transit Wand does what it's supposed to do. You collect data, and then upload it to a server. There is a lot of room for improvement though. It would be nice to have a better API that allows access to more of the data. Building in analysis tools for the ridership data might also be a welcome thing. I imagine it would also be great if you could encourage people to use the app and upload their own trips.

Posted: 2013-07-15 22:45 | Comments

# Fare Data

As part of the data released by the DOTC, we also have the fare matrix for aircon buses, ordinary buses and jeeps. All as wonderful images. The data is also actually available from the LTFRB website. Generally, the fare scheme is represented as "pay X pesos for the first Y kilometers, pay Z for every succeeding kilometer." Instead of a table, we can simply represent this as a formula instead,

    base_fare + (distance - initial) * per_km

The relevant values for the three services are:

type | base_fare | initial | per_km
bus aircon | 12.00 | 5 km | 2.20
bus ordinary | 10.00 | 5 km | 1.85
jeep aircon | 8.00 | 4 km | 1.40

It isn't as simple as that though. Fares are also rounded to the nearest 25 centavos. So we'd need to round them off correctly. This can be achieved by doing,

    round(calculated_fare * 4.0)/4.0

There's also the discounted fare for students, senior citizens and persons with disability. They get 20% off the fare (prior to rounding) and the resulting fare is rounded off as well.

Doing just this, we actually do get the same results as the fare matrices in the image for the most part. There are some discrepancies with the discounted jeep fares. I've tried to resolve it by tweaking around with the formulas, but it really doesn't make sense in any way. I presume these were manually adjusted for one reason or another.

Here's a script that generates CSVs of all the three fare matrices. If you're too lazy to run it, here are links to the aircon bus, ordinary bus and jeep fare matrices.

#### GTFS compatibility

As is, the provided GTFS data does not have any fare data. I imagine this is because the existing spec doesn't have good support for distance-based fares like we have in the Philippines. Judging from the fare examples, the only reasonable way we could implement distance-based fares is following example 6. This would involve setting a fare for each possible pair of stops based on the distance between them. This isn't exactly ideal. In fact, the people originally working on the DOTC project have voiced issues and made proposals for having distance-based fares included into GTFS.

Apparently, public transit fares are a really complicated thing. You have fares based on distance, number of stops passed through, and transfers which may or may not cost extra. Not only that, you might have discounted fares, or first-class vs economy fares. The community will want to get it right before it's formally included in the spec. You can see the current state of the consolidated GTFS fare proposal here.

Even in it's proposal form though, we might have hope of being able to see these being used. There's currently a pull request for supporting the distance-based fare scheme into the OneBusAway libraries. The libraries actually used by GTFS Editor and OpenTripPlanner for working with GTFS data.

#### Remaining Problems

Given all that, it would probably still be a long way before this allows us to make a really good routing app. We still don't have shape data, so the distance estimates would really be rough estimates at best. There's no support for rounding to the nearest centavo. I realize that's just nitpicking, but if we want something truly polished, even that has to be taken care of.

We also don't know if the jeeps or buses strictly follow the distance-based scheme. After all, if you can get on and off anywhere, you can't really measure distance that exactly. I assume they generally work off the notion of "zones" than actual distance travelled. In that sense, they work more similarly to the LRT which has fares based on how many stops you pass. For jeeps and buses, your fare is probably based more on how many "zones" you pass through.

#### Conclusion

Philip, a co-worker of mine at By Implication, had suggested that we might want to use a different model than what the GTFS proposes. I have to agree with him. At this point, the GTFS doesn't really fit with our system. But I do think that open data and standards are great. In fact, I applaud the developers who made proposals for the fare system, as those are great first steps towards making the GTFS a more universal standard.

Side note: I'd also actually really like to hear about the DOTC developers' experience with the project. It would be nice if they had a devblog.

Posted: 2013-07-13 21:15 | Comments