Last week I came down sick so, again, a slow week.

I’ve started looking into moving the core functionality to C++.

Right now I’ve implemented the basic functionality (searching for nearby stops, building transit plans, etc) twice: once for android and once for processing the transit data on the server. The android version is the only really complete one, the python version I use on the server is hacky and limited. When I start working on the iOS version I’ll have to implement everything all over again and also if I want to have a web version, which would make a lot of sense, I have to put a lot of work into improving the python version. And it was a lot of work just creating the android version.

What’s occurred to me is that all the three places I need the functionality, android, iOS, servers, can integrate with code written in C++. So maybe, just maybe, if I create a C++ version I can use that everywhere. For now I’m working on confirming that it can replace my existing code for android and servers and soon I’ll look into making it work on iOS.

I’ve also continued to work on generating transit maps. Having programs build maps that look decent is really super hard, it turns out. I think I can find a solution but there’s still a long way left to go.

This week I’ll take my first concrete steps in terms of marketing. I’ve thought a lot about things I could possibly do, now I’ll start doing them.

Whew, it’s really been a while since my last update. Much has happened – though not with the app.

The reason I’ve been away is that I took a break from the project to work as a consultant, from September until now. But now that’s over and I’m back to working on the app.

Oh one more thing, I’ve moved into a new office too. I moved out of the old one while I was consulting since I was working out of the office of the company I was consulting for. The new office is really just a desk but it’s somewhere to work from again.

While I’ve been away I’ve had a ton of new ideas and thoughts around the project. Nothing major has really changed but I feel like I’m at a good place to continue the project. In particular I’ll focus more on the non-technical side of things. I was planning on doing that while I was consulting but I just didn’t have the bandwidth to do both. But I do now so that’s going to be the focus for now.

For the last few weeks I’ve been on vacation so not much has happened. Except, even on vacation I couldn’t help play around with some ideas for how to build recurring Voronoi tessellations as part of some ideas I’m playing around with for how to include maps in the app. Because I think, ultimately, there’s a really fundamental choice I have to make around whether I center the app around text or maps. Maps is much harder but it solves a ton of problems and provides a much better user experience. So I’m trying to work out how I make that work – even when you’re offline – without replicating google maps. Some of my ideas around how to do that relies heavily on recurring Voronoi tessellations.

Now that I’m back home I’ve implemented some of my ideas and the result seems to work pretty well. The first three images above show part of the process that goes into building a tessellation, it’s all about generating random points and “massaging” them appropriately.

The last three images show how you use the result, here one with 256 tiles. The square itself looks pretty random, which it is, and then you can build larger areas of random tiles just by repeating the one square. At least to my eyes, it’s hard to tell from the 2-by-2 square in the last image that it’s not completely random but actually made by repeating the 1-by-1 square four times unless you’re looking for it. You need them to be color coded to tell. And that’s exactly the effect I was going for. Plus in what I’m using them for the basic squares will be bigger, probably 1024 or 4096 tiles, and you won’t see the tiles directly there will be something built on top of it that will blur them somewhat.

How that plays into making the maps of Denmark that I’ll display in the app, that’s the next step and I may or may not start working on that right away.

What I’ve been working on for the last few days is breaking up routes.

You can think of a route as like a page in the transit schedule, it’s the thing that has a name like “bus 13″. I’ve been relying on that concept a lot internally. For instance, to list all the departures from a stop I first find all the routes that visit the stop and then I find the departures for each route.

The problem is that some of these routes are really big. For instance, all IC trains are listed as a single route: “IC”. That means that when I’m looking for trains that depart a station that gets visited by some IC train I have to look through all IC trains in the entire country. What I’ve been wanting to do is break up the really big routes into separate parts and that’s not too difficult if you look at a route on a map – but there’s more than 1000 routes so that would take way too long, I have to find a way to do it automatically. That’s what I’ve implemented over the last few days. What the video shows is first the big routes that were there before, and that now each of those big ones are made up of a number of smaller ones that have been determined by analyzing the trips that make up the route and grouping similar ones together. With this in place everything should now be a bit faster, and the slower a stop was before the greater an improvement it should see.

The next thing I’ll implement is related to performance too. Right now, to find departures at a particular time I have to take all trips for all days into consideration. I’d like to group trips such that to find a departures at some time you only have to look at the trips around that time. That should give a nice speedup too.

The reason I’m working on making the app faster is that I’d like to implement some operations that build on top of these, for instance departures from a set of stops to another set of stops rather than just from one to another. If the simple operations are slow the larger and more complex operations that I’d like to make will be suuuper slow. And I want those to be fast too.

Something else I’m playing around with a little bit at the moment is whether it’s feasible to represent information on maps rather than just as text. It’s tricky but I think it’ll be a game changer if I can make it work – picking places to go from and to, showing routes, etc directly on maps.

There’s still a ton of work left to do, at this point I’m just planting acorns. But something I’ll definitely need whatever I do are the basic maps that everything will be displayed on. So I’m drawing those. It takes a lot of time and sometimes it’s tricky but it’s also pretty relaxing and I think they’re turning out okay.