LinzAG Linien Status
April 9th 2026 09:00I was reading a news article about where and how much time wrongly parked cars waste in Vienna and I got interested in where they got the data from since it didn't come from the Wiener Linien directly. The original source ended up being f59.at which is an open data project created by Martin Piskernig fetching data from the Viennese public transport company's open data source. I was curious if there was such a thing for a city more local to me: Linz; but there was only the official page which doesn't keep log of past incidents. So I saw an opportunity to experiment with web-applications and open data and got to work.
LinzAG Linien, the public transport company in Linz, also has some datasets they publish over at data.gv.at, a collection of datasets published by public bodies like city governments and applications utilizing them. The dataset I was interested in was originally a few endpoints that provide XML data of schedules and trips; but has since been split off into a static download for the fixed schedules and the endpoints have been end-of-life since 2014 but they still seem to serve the realtime information. There is no documentation directly linked but I found what I believe to be the latest version here.
There are four endpoints:
XML_DM_REQUEST to fetch information on the monitors at stations, XML_TRIP_REQUEST to find
trips from station A to B, XML_STOPFINDER_REQUEST to find and validate stops and XML_ADDINFO_REQUEST to get current service interruptions.
All the endpoints return current incidents but the ADDINFO_REQUEST has more and is also more detailed. I'm not sure why the others return a slimmed down
version, but I originally ended up using STOPFINDER_REQUEST because it had the least amount of extra stuff if you don't supply any arguments. Only while writing
this post was when I found the newest version of the documentation featuring the "new" ADDSTOP_REQUEST endpoint. Meaning I had to rewrite some of the code
after the fact...Anyways, the bits of the XML I care about are the incident ID, times, and description. I've isolated one incident to show you what the XML contains:
The elements I want are two
paramList parameters, infoLinkText, infoText and concernedLines. The paramList
parameters I need are the ID and incidentDateTime because validityPeriod seemed a little wonky with multi-day incidents sometimes.Since the only language I sort of know is C# I decided to use ASP.Net for the backend. You can find the source on GitHub. ASP.Net is a little funky to figure out at first but once I managed to get the basics I put something together that requests the XML, parses it and put it in an object that I can put in a list and save as a JSON. The backend gets the incidents and saves them to disk every 5 minutes. The data is then served as a HTML table.
The incidents are sorted by
StartTime and get deleted once EndTime is longer than 30 days ago. Though I might not delete them in the future and
instead just not have them show up on the list. If anyone ever wants to do a statistical analysis or something a longer timeframe would be more useful.
The next challenge was how to bring the data onto my website. There were a few options: Build the entire site in ASP.Net which I really didn't want to do, have the app on a subdomain or do weird redirects. I really wanted to have it on the main website in a subfolder so I ended up something kind of weird and have a PHP script retrieve the page serving only the table, and then include that in the projects page. Styling can then be done as if it was a regular table.
I set it up as a service running on a VM for hosting it, and added a monitor for the subdomain in Uptime Kuma for the little status badge at the bottom of the project page.
I'm quite happy with how it turned out considering it's my first real attempt at a web-application. Though I am also a little worried about problems that might come up since the audience for this project is broader and the contact method isn't just a Discord ping from a friend saying "??? plz fix".