This week’s theme so far: importing data. The transit data that’s helpfully being provided from rejseplanen comes in a big zip file and everything you could need is in there. But it’s in a cumbersome format and needs to be massaged and processed such that the app can extract the information it needs quickly. Also, it can’t take up too much space.
So far I’m just trying to understand what’s in there. The massaging and processing comes later when I know what it is I’m trying to process.
Started the week by going to the state library, which is just across the university campus from where I live, to look at transit schedules through time. I was mainly looking for some inspiration for how to present transit schedules. It turns out they have lots and lots of those.
The ones that are most relevant are the most recent ones – they seem a lot easier to read than the older ones – and I have some recent ones myself. So my main takeaway is that I have all I need already.
But on the other hand the ones I found most interesting were the older ones. They had ones going all the way back to the 1850es and it’s a shame I was in a hurry because there’s so much to look at and take in. I don’t know if I learned that much that I can use in practice but I enjoyed it enormously.
As always the librarians were super helpful and knew a ton about the subject. Turns out they’ve even posted about it online. Librarians are great.
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.
Bundling transit data with an android app, getting the current location, and figuring out the closest stops. The app now does… something at least, anything.
Spent some time drawing an icon today. The style of the book is close to other book icons I’ve seen but I’ve tried to make it narrower and thinner – when I think of a transit schedule it’s narrow and thin. What I’ve drawn is actually thicker than what I wanted but I don’t want to spend a huge amount of time polishing it. When I want something polished I’ll redo it completely.
