This week I’ve been working on how schedules are stored.

What I’m really working towards is showing other stops in walking distance when showing departures from a particular stop. But that requires some nontrivial changes to how I compute departures in general and at this point I’m reluctant to just keep working on the existing implementation because that only works on android, and that way I’m working my way further and further from the iPhone version.

So I first want to get the version that will work on both android and iPhone, the C++ version, up to the point where it works as well as the android-only version, and from then on the improvements I make will benefit both platforms. However, now that I’m back to working on the basic algorithms I realize that some of the decisions I made with how schedules are stored weren’t optimal and I’d rather not implement them again in C++. Which brings me to what I’ve been working on this week: changing the format to make it simpler, smaller, and easier to access.

It’s all about data compression which may sound boring but in my experience always turns out to be fun. It tends to be a cycle of: come up with an idea for how to make things smaller, implement it, try it on real data, see if it actually works, if not start over again.

The screenshot above is what it looks like when it actually works, it’s the latest approach I’ve tried which is probably what I’ll end up going with. It reduces the list of stops visited by a trip down to 3.4% of its original size, from 11.1 MB down to 0.4 MB, and timing information about when stops are visited to 7.1% of the original size, from 21.6 MB down to 1.5 MB. Then on top of that there’s another different compression step which will squeeze it even more.

I’d like these improvements to be part of the next update to the app and I’m not quite there yet, but I’ve just about nailed down how I want things to work and now I just have to implement it.

Media attention: I has it. Well, around Aarhus anyway. I gave an interview two weeks ago and so now the corresponding article is out.

For the last few days I’ve been working on the UI for the next set of features to add to the app, plus some improvements to features that are already there. I’ve been spending a lot of time in sketch.

As I’m working on it it’s really super useful, for myself and when demoing for others, to show the designs on an actual phone, interactively. Sketch, together with sketch cloud to get a website that behaves like the app, together with fullscreen browser for android so I can use the prototype full screen, have been super useful for that.

The video above is an example of what that looks like. It’s just dumb pictures I’ve drawn in sketch but it really feels like you’re looking at a real app, doesn’t it? The next version of the UI probably won’t end up looking like this but this shows the direction I’m going.

After a long vacation I’m back to work. Actually I came back two weeks ago but I’ve had to spend some time figuring out what I should be working on.

What I’ve been doing in the meantime, since I can’t sit at my desk all day every day figuring stuff out, is implementing stop searching in C++. The app already has functionality running in C++ but this is the first major feature. You won’t see a difference, the app looks and works exactly the same except maybe a little faster, but now when I go to make the iPhone version I can use the exact same implementation which is key really to ever getting an iPhone version done.

The main thing I’d like to work on for the next while is a partial redesign of the app and a new feature, places. A place is somewhere like home, or work, or wherever, that the app knows about and can display in different places. A place will likely have an icon and a color so it’s easily recognizable when displayed in different places. It’s one of the oldest ideas I’ve had and I think I’ve thought it through enough that I can start implementing it. For instance, it was months ago that I made the list of colors and icons I’d like to offer.

Recently I’ve been spending some more time working on generated transit maps. For those I need some “ground truth” – like, I need to know where the land is, where the cities are, where there are lakes and forests, and so on, since I’d like to be able to draw those on the transit maps.

Luckily there is a source for that kind of information, Open Street Maps. They have super detailed maps of Denmark and they’re all open data. The downside is that the data is a little hard to access so I’ve had to spend a fair amount of time massaging, manipulating, converting, the OSM data to get something I can use to draw my maps. I’m pretty much done with that now though. The images above give some examples. The first is the OSM viewer showing Region Nordjylland in its viewer. The second is an image I’ve created based on the data I’ve extracted. The third is a lake near where I live, the fourth is an image I’ve created that includes all lakes in all of Denmark.

The point is, now I have all this data and it’s in a format that I can work with. The next step is to build maps using it but I’ll probably put this effort on hold for a little bit since I might switch my focus to some simpler, more low-hanging, changes I’d like to make to the UI.