Two weeks ago I finished the underlying mechanisms for splitting data into regions. Last week I worked mainly on changing the code that reads the data so that it could deal with reading it from those divided regions. I was working at a reduced pace because I had a cold. Still do a little bit. Ugh.

Part of reading the data back efficiently required figuring out some new algorithms. One data structure I use all over the place is the z-quad which is a way to give a geographical region a name (well, a number) and a lot of the work revolves around how z-quads relate to each other. Like: I’m in this z-quad over here, which other ones around me should I look at to figure out which routes pass through here. It gets kind of abstract and mathematical which I enjoy. I’ve printed out some “z-quad paper” that I’ve been spending a lot of time staring at and doodling on while trying to figure this stuff out. When I figured out how I’d like something to work I made test cases and then I wrote the code that did the actual thing. And then the last step is hooking it into the actual app and seeing it – hopefully – work and be fast and stuff. Which seems to be working at this point for stops. Routes and trips are next and I hope to be able to complete that this week too. Then the app will be back to where it was just before Christmas but now much faster, fast enough that I can build more functionality on top.

Something I worked on over the weekend was a profiler for the data bundles, basically a tool that will analyze them and say: what takes up the most space is this. For now it looks like stop names are the single biggest thing so I’d like to look into how to make those take up less space. I’ll probably spend some time on that this week too.

The epic currently is: make it faster to generate a list of departures at a given stop. That’s what I’ve been working on basically since christmas.

I have two different approaches that I want to use at the same time. One is breaking the timestables into separate “packages” such that when you’re interested in data for, say, Silkeborg, you don’t have to look through the data for Roskilde or Aabenraa. I made a rough division by packaging each transit company separately but it was too coarse. It does mean that to look up departures at a stop in Silkeborg you only have to look at Midttrafik, but that’s still a lot. The problem is, it’s hard to divide things further because if you want to split the data further into, say, Midttrafik-west and Midttrafik-east, where do you draw the line between them? You don’t want too many routes crossing the division between the packages, the more self-contained the packages are the better.

Anyway so I spent a couple of days making a program that crunches all the schedules and figures out some good places to split the packages geographically without too many routes crossing between divisions. The map above shows the result – different colors represent different packages. So Fyn is split in two basically through Odense, Sønderjylland is split in three strips, Midtjylland is split into four parts (they’re hard to see) etc.

The other approach to save information while building departure tables to make future operations faster. That won’t make it faster the first time you look at a stop but it will make it faster the next time, and possibly the first time you look a stops near a stop you’ve already looked at. I want that information to be saved even when the phone is off and it took a while to figure out how and where to do that. But that’s sorted out too now.

The used iPhone I bought arrived a while ago and now I’ve started using it, and have made my MacBook ready for development. I’m an android guy but if I want to make an iOS app I should get used to how an iPhone works. So I’ve switched to it as my primary phone. It’s okay.

I’m still not sure of what to call the app. I’m not happy with the current name, næste stop. I considered køreklar, it sounds better but I’m still not super happy. My latest idea was A til B which I like the sound of. But I’ll have to ask some people what they think.

This week I want to finish splitting up data and set up proper testing of departure lists for stops. Then I can start running comprehensive tests which will help me get the implementation right.

So far this week I’ve worked on a small and a big thing. The small thing is that now when you press the location button, if you’ve got location disabled the app will ask for it to be enabled. Simple.

The other thing is that to speed up data access I’d like to break it into several separate packages. Right now when you open a stop anywhere the app scans through all the data – literally all transit schedules for the whole country. As a first step in making things faster I’d like to divide the country into regions and then only look at data for the region you’re in. I’ll start with a few big regions and then later on if I have to I can go back and break them down further. The images above show the current division and a representation of the data structure I’ll use to decide, given your location, which region/regions to look at.

Happy new year! The holidays are over and I’m back to work, having made no progress really since the last post. Except that I had time to work on some ideas for how to make accessing the data faster – long drives and lazy afternoons are good for that kind of thing.

I also have a pretty clear idea for what kind of functionality I want the very first release to have. I want four screens:

• Saved stops/routes that also shows a list of the nearest stops
  
• A list of stops that you can search by name
• When you click a stop you get the departures from that stop (*)
• When you click a departure you’re shown the entire trip (*)

And finally, on the screens marked with (*) there should be an option to “save” or “pin” that puts an entry for that stop/route on the saved list. That’s it. It’s not everything you want but it’s enough to be useful. It’s somewhere to start.

Oh, and I’ve bought a used iPhone 5S for developing the iOS version, it should be arriving by mail within a few days. I was waiting until after Christmas so I could by it on sale. Once I’m done with the initial android version, or in parallel, I should spend some time on the iOS version as well. The problem with iOS is that I’m an android user myself so I don’t have a good understanding of how apps should work on iOS. So even though the iPhone is for work I want to use it as my own phone as well, at least some of the time, so that I can learn how iPhone apps work.

Should I give releases names? I probably should. In keeping with the working title of the whole project, pensive agouti, I’ll name them after things agouti eat. They eat a lot of different things so that should give me something to pick from. I’ll call the first release apple because, ironically, it’ll probably be android-only. Here are some more names, now that I have the list of agouti foods open,

1. apple
2. yam
3. broccoli
4. banana
5. carrot
   

That should cover me for a couple of months.

Last week was all about finally getting the app to show the next departures for a given stop. The data I want to show is there, easily accessible, in the source data dumps I get but I need to rearrange and pack everything pretty dramatically to make it smaller. Consequently, when I want to display the data I have to reverse that, I have to unpack the data again – but only the small bit that I need – to be able to display it. The images show basically what the sequence has been to implement the unpacking: I look at the original data dump to know what the list of departures is supposed to look like. Then I write a test that captures that. Then I look at the compressed data in the database to figure out how to unpack it and whether anything’s missing that I need. Then the last step is to present the result in the app.

I’m taking some shortcuts right now – I display the wrong time and I show some departures that shouldn’t be there – but fixing that is the relatively easier part. 

What’s harder to fix is that it’s really slow, as the video below shows, there are long pauses especially immediately after the app starts (it gets faster over time). Also these are small stops, I don’t date click on a large station. Right now I want to display the correct data and only then look into fixing the slowness, probably after christmas. I want this to be lightning fast since I expect listing the next departures from a stop will be a super common operation.