# Pleasant Programmer

# Console Keymap Switching

At the office, we have some people who use DVORAK. Normally, this isn’t a problem. To each his own after all. It does become a bit problematic though, when we’re dealing with the servers around the office.

We normally leave the servers on QWERTY. After all, most people start off as QWERTY typists and migrate to something else. That said, it’s apparently difficult to stay fluent in both. People tend to forget how to type in QWERTY once they learn DVORAK or something else. While it is true that they can just look a the keyboard while typing, my coworkers would prefer it to just be in DVORAK.

For the console, they’d typically do `sudo loadkeys dvorak` after logging in. The problem with this is, after they logout, the keymapping is still on DVORAK. This has been quite annoying for a few times since I can’t even login to change the keymap. What I wanted was something like you get in the graphical login screens where you can pick your keymap before logging in. Apparently, there isn’t a readily available thing for the console.

I googled around for solutions and came across a nice idea. You could alias `asdf` to load the DVORAK mapping and `aoeu` (the equivalent to asdf in DVORAK) to load the QWERTY mapping. This actually makes sense since you don’t really have to know where the letters are. The only problem is, you once again have to be logged in to change the key mappings.

After some further searching, I found something close to what I wanted. Apparently, Alt+Up sends a KeyboardSignal keycode to the init process, which can act on that. It also works anywhere, even before being logged in. For SysVinit systems, you can just add a line to your inittab for a command to be run when Alt+Up is pressed.

In the office, however, we generally use Arch Linux which uses SystemD. But apparently, it also has a mechanism of accepting the Alt+Up press. It runs the kbrequest target whenever it gets the keypress. `kbrequest.target` is normally aliased to run the rescue service though, so you have to manually create the file in `/etc/systemd/system/kbrequest.target` and fill it with a description:

    [Unit]
    Description=kbrequest target

We can then add a service to be run whenever the target is called. Something like `/etc/systemd/system/keymap-switch.service`:

    [Unit]
    Description=Keymap Switch Service

    [Service]
    Type=oneshot
    ExecStart=/usr/local/bin/keymap-switch

    [Install]
    WantedBy=kbrequest.target

After enabling said service, we only need the actual keymap switcher, `/usr/local/bin/keymap-switch`. The StackOverflow answer provides different ways of detecting the current keymap so we know which one to switch to. Since we’re using SystemD, we can use that instead for managing which keymap we’re actually using. It stores the current settings inside `/etc/vconsole.conf`. We can also then switch keymaps by using `localectl set-keymap`.

    #!/bin/sh
    source /etc/vconsole.conf

    if [ "$TERM" = "dumb" ]; then
      if [ "$KEYMAP" = "dvorak" ]; then
        localectl set-keymap us
      else
        localectl set-keymap dvorak
      fi
    fi

After putting it all together, it works! We can switch keymaps on the fly by simply pressing Alt+Up.

Posted: 2013-10-29 | Comments

# Geocoding Services

A key component for any routing service is being able to do geocoding. Most people who are looking for routes most probably don’t know exactly where their start and end points are on the map. Even then, manually looking for a location on a map is a time-consuming task.

The gold standard for doing geocoding right now is Google Maps. It’s hard to find a better location search experience. If they actually provided routing for jeeps here in the Philippines, I imagine there wouldn’t be that much you could do for the competition.

When the competition started though, I took it as a challenge to avoid Google Maps as much as possible. I wanted to see how much is currently possible with other options such as OpenStreetMap. In fact, OSM does have a geocoding service called Nominatim.

Sadly, for a mapping app, what you want to do is not simply just geocoding. With geocoding, you take an address and turn it into coordinates. When you want to search for a place in a mapping app, you take part of an address, infer the rest of it, and give the user options to choose from.

Given a typical mapping app, you might type in “ateneo” and expect it to give you Ateneo de Manila University. With typical geocoding services like Nominatim or even Google’s geocoding API, you probably won’t get any result for this. What you want to use is the Places API which provides an autocomplete search box. Using it, when you type in “ateneo”, it automatically suggests in the dropdown, “Ateneo de Manila University”.

A downside to using the Places API is that it’s against the terms of service to use it with something that isn’t Google Maps, which means no OpenStreetMap. If there were more time, writing your own autocompletion engine using OpenStreetMap’s data will probably be a better long term solution.

For now, since the competition’s deadline is just a few days away, I’ll be using Google Maps.

Posted: 2013-09-25 | Comments

# Jeep and Bus Schedules

Wouldn’t it be wonderful if there were no buses or jeepneys in the Philippines over the weekends? It would truly be a cyclist’s paradise. Imagine biking along EDSA, normally that would be a death sentence, but according to the GTFS data, you shouldn’t worry. I can assure you, it’s still a death sentence.

The GTFS spec defines 2 ways of statically specifying trip schedules. You can define the exact times that a service will arrive at a stop. You can also specify between what times the service is active and how often a new bus or jeep leaves the first stop. You also define which days those rules apply. You could say every MWF, the bus operates from 9:00AM to 9:00PM and every TTH, the bus services from 3:00AM to 11:00PM.

This should be sufficient in theory, but real world conditions like traffic or the weather could throw the schedules off. To solve this, there’s another spec, GTFS-realtime. This allows transit agencies to push temporary schedule updates and service announcements.

Like much everything else about the Philippine transit system, there aren’t really any “schedules” to speak of. It’s generally whenever the buses or jeeps feel like it. So we have no static schedules. We don’t have a central agency or the tracking technology to make it feasible to push updates via GTFS-RT.

Ideally, we shouldn’t bother inputting the schedule information into GTFS. Only the route data is really important for jeeps and buses. However, the schedule information is required in the GTFS, and routing apps wouldn’t work without it. So we have to add a reasonable trip schedule for jeeps and buses.

The current GTFS data does define these trip schedules. We assume that jeeps and buses operate between 6:00AM and 11:00PM and a new jeep passes by every 10 minutes. Also, jeeps and buses are defined to only operate on weekdays.

While there might be jeeps who change routes or don’t operate on weekends, I’m pretty sure that jeeps and buses run on weekends. We’ll have to fix it ourselves temporarily since there’s no central GTFS feed yet.

    # 724594 seems to be the service id used by jeeps and buses
    sed -i .bak '/^724594/ s/0,0/1,1/' calendar.txt

Another thing we could do is to adjust the time between buses, although the improvement is arguable. With the current 10 minutes between jeeps, it might provide some routes a significant advantage just because the timing is right. So you might get differing route suggestions depending on what time you planned the route. This makes sense when you’re sure what the times are, so you can minimize the wait, but with jeeps, you never really know how long the wait will actually be.

If we set the frequency to one minute, it might give better routes by eliminating the timing issue. Or not, it’s kind of hard to tell.

    # jeep and bus route ids tend to start with 72
    sed -i .bak '/^72/ s/,600/,60/' frequencies.txt

Overall, the problems we’re having is a symptom of the mismatch between our transit system and the GTFS. It would be great if our transit system gets better and we don’t need to do hackish things for it to fit the GTFS, but that’s still a dream. For now, all we can really do is fit a triangle into a square hole.

Posted: 2013-07-28 | Comments

# 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 | 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 | Comments