First up, a little background about me: I studied computer science at NYU for three years, then I transferred to Stevens to pursue mechanical engineering for another two. It’s all part of a dual-degree program between both schools that essentially allowed NYU to appeal to engineers while having no engineering department or school whatsoever (at least back when I entered). Suffice it to say Stevens filled the gear-shaped hole in NYU’s heart, until NYU went and bought a little place in Brooklyn *cough*NYUPoly*. Either way, I enjoyed the benefits of both schools, both the breadth of a city university and the closeness of a college campus in Hoboken. If for nothing else, it was often an interesting contrast.
Scheduling is hard.
At NYU, class sections tended to follow patterns in their scheduling. They would meet either Monday/Wednesday or Tuesday/Thursday, for the same 75 minute time period each day. Recitations and labs could meet later in the day, or on Friday, and there were plenty of choices for all. My transfer to Stevens was what taught me that I had been taking this sanity for granted; schedule chaos reigned supreme across the Hudson river in Hoboken, and for reasons still unclear…
My text editor doesn’t spoil many secrets, its title bar simply glows “stop_times.txt – nycsubway”. Below that, lines of gibberish seem to cascade downward endlessly, patterns coyly exposing themselves in streaks of data as I scroll down violently. In one file hides every single stop, made by every single train, running along every single route of the MTA New York City Subway. There are a few other files in the folder that can help describe some nuances, but stop_times.txt reigns supreme in its overwhelming size. One text file that *is* the entire Subway. At last count, it’s 522,670 lines long. I could spend my entire summer just scrolling that far, surely rubbing the pads of my fingers down to the bone in the process, but my plans are slightly more ambitious, slightly less crazy.
Aesthetic Design Algorithm for Public Transit Information Diagrams, ADAPTiD for short. As of yet, it’s just a dinky line simplifier that has been fed data from NYC’s PATH rail system, which connects Manhattan with points west across the Hudson. Yes, giving such a project an acronym already is perhaps akin to publishing my work on “Hello World”. This is true, but there’s no one out there to deny my request to acronym-ize myself so soon; perhaps I’ve abused this liberty.
So why does the world need a program that can automatically generate subway maps? Well if you’re anything like me and you live in a city, public transit is how you get around. You refuel not at a gas pump but at a MetroCard machine. You laugh as drivers kill each other over parking spots.
But then there are those times you’re left standing on a train platform — you’re waiting for a train that you must eventually admit will never come. Transit maps are designed to be accurate at one time: rush hour on a weekday. Every other second (which is a lot of seconds), you need to know what the exceptions are and what they mean. And when you start considering planned and unplanned service disruptions, that map might never be accurate. So keep on waiting, that train’s not coming, not today.
But what if you could design a subway map that’s always right? It would look at the day and time and show you only the service that’s running. If you’re lucky, it would even check for reroutes and suspensions, and adjust itself accordingly. I think we have the technology.