OpenTTC, and the love/hate relationship of XML

Well. Here’s my post about OpenTTC, and a mini rant on how Toronto structures their own data.

I started working on the revamped version of OpenTTC. My old module used a built in XML Python Library called “ElementTree”, and while it got the job done, it was incredibly slow, and prone to breakage really easily.

Thankfully, BeautifulSoup and lxml’s XML Library does a great job parsing data, and querying is also quite fast, (0.5s). Now let’s get to what’s ported, and my next steps moving forward.

Right now, OpenTTC is structured in a way that stores any important piece of data we may use later on. We currently store the route(as an int), route name, and the next buses/streetcars coming.

The Object Data at Hand

Now, oh boy. Let’s talk about XML. The API I use for the live data is called “NextBus”, and their XML structure is so…. messy. They don’t structure the stops and data all in multiple array/lists, but as one gigantic XML document with multiple children.

What a mess…

Great… but on the bright side, it did make me practice List Comprehensions in Python, and voila! Clean list of TTC Stops for a specific route!

Clean List of Stops for the Spadina Streetcar (Route 510)

So…. what’s next? Well, now that I have the list all ready, now we get to work on storing TTC Stop Times by Stop ID’s (unique ID use for a specific stop)