Working with z-quads

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.