Last week I wanted to get something running on android, anything, that included actual transit data. I got that working after a few days – it’s simply a button you can press and then it shows the nearest stops from your current location – but it’s a place to start. Finding the nearest stop is super slow though, it simply scans through all stops in the entire country and sorts them by distance. Turns out I need to be smarter to make it fast.
The rest of the week I spent working on more efficient data structures for dividing data by location, so if you want to know which stops are close by you can find them efficiently without looking through everything. I had already designed a solution for this, z-quads. That was the last time I thought about creating this kind of app and I even wrote a bunch of blog posts about it back then. So I dusted those off. A complication is that I need this kind of data structure at least three times: in the backend, in the android version, and the iOS version, and I can’t reuse the same implementation I have to create three different ones that have to work the exact same way. That’s a challenge for testing since you’d ideally want to run all three through the exact same tests to ensure they behave the same but there’s just no easy way to do that. But I really wanted to do it so I did it the hard way. That took a long time. So I’ve spent much more time on testing than implementing actual z-quads but it’ll be sure helpful in the future to have the testing work done.
Oh, and I went to the train station to see if they had any printed schedules – I got one, the last ever printed version of the train schedule. The same at the bus station, I actually got someone’s personal copy. The public library doesn’t keep transit schedules, as it turns out, but they said the state library does. I’ve just come back from the state library, boy they sure do have a lot of transit schedules.
