We’ve all waited quite some time for some data access to AtB’s real time data for public bus transportation. AtB themselves promised an Internet service not long after their release of their real time data service over SMS. We’re now in late May and still not a word about it, and I know several people who have tried to get in touch with em to get access, but it’s all been a silent answer from em..
Sad thought is what I’m thinking, public transportation data should be open to the public – it’s for AtB’s own benefit that the data should be open and easy accessible for nerdy geeks to create cool applications. “Somehow” we managed to get access, 14 days later we released our API and 3 applications. Go try our webapplication at http://busbuddy.norrs.no , or my BusBuddy Android application over at https://market.android.com/details?id=no.norrs.busbuddy or Magnus’s Busstider application for iOS (read Apple iPhone etc) you’ll see good applications made in rather a short time, and as cheap as 1 dollar. And there is even more application alternatives on it’s way from other hobby developers! We’ve spent like approx 1 week hacking together these applications and API, plus another week for internal testing. 14 days you had to wait before our release and access to an easy accessible API. I’d have to say splendid, most people already who have tested our applications – praises and loves it! The people already know the data might not be stable or reliable since it’s under developement at AtB.
Why AtB are afraid of releasing their data/services before it is “stable” is unknown for me, since they seem to be already using this data in their SMS service which has been active for quite some while, and the data so far looks pretty decent and amazing in my opinion.
There’s some loop holes in their “public” (read hidden and protected against anonymous access) data, for example all the exported data has Italian identifiers in their SOAP-encapsulated JSON. Their data also has rather an weird format for an external API in my opinion, but I guess shouldn’t judge em too hard since we don’t know all the inner workings of their systems. This might also be one of the reasons why it isn’t public yet? Still it took us only a nerdy night of debugging to hack together some sample code to extract data from their SOAP service..
Other glitches you’ll notice when using the API is fetching departures for a bus stop right before midnight, as it probably gives you no departures in return until it turns after midnight… as you clearly see – they still have things to fix which we cannot solve on our end.
You might also be interested in that their actually working on providing the community a WWW-service, but it seems rather unpolished and “far from done” if I may say so. I’ll be looking forward for their final product and what they come up with when it its done. Anyhow, I’ll at least say we beat em fairly well with the release of our applications and the usability we provide. Clean and simple if I may say so 
Let’s just praise that AtB won’t be knocking on our doors, deciding to kill our service for you users. Stats on http://api.busbuddy.norrs.no/api/stats tells us you already appreciate our applications.
And keep in mind, the data is open and freely open for everyone. If you want to dig in, just email me for an api key request at busbuddy ‘at’ norrs.no. FYI, the api key is only used for tracking a requests counter for each api key. In the next release of our API we will be adding support for UUID which the applications can generate with an UUID.generator and send along. This way we’ll be able to track how many users each application have, and of course you’ll stay anonymous as there is no IP recording in the log towards api keys or the future feature of UUID.
Example on our data:
* Bus stops .. (we’re still mining data, such as their abbreviations name and bus stop maintainer. Also the locationId plays a special part of their data.)
{"busStops":[
{"busStopId":100034,
"name":"Hangran",
"nameWithAbbreviations":null,
"busStopMaintainer":null,
"locationId":"16010732",
"longitude":10.074741,
"latitude":63.38196},
{"busStopId":100078,
"name":"Klefstadbekken",
"nameWithAbbreviations":null,
"busStopMaintainer":null,
"locationId":"16011728",
"longitude":10.155953,
"latitude":63.43434},
{"busStopId":100162,
"name":"Flatjord",
"nameWithAbbreviations":null,
"busStopMaintainer":null,
"locationId":"16010765",
"longitude":10.509505,
"latitude":63.34741}]}
* Departures for a bus stop. Use registeredDepartureTime for real time data, or scheduled departure time for no real time data. The tricky part is to not use the datestamp (only timestamp!) from schedule departure time when isRealtimeData is false. The datestamp we represents when the data got inserted to AtB’s system… we guess.. (ignore the blunty error of using “isGoinTowardsCentrum” which will be updated in the next version of the API to be “isGoingTowardsCity” )
{"isGoingTowardsCentrum":false,
"departures":[
{"line":"36",
"destination":"Stokkhaugen",
"registeredDepartureTime":"2011-05-18T05:38:00.000",
"scheduledDepartureTime":"2011-05-18T05:38:00.000",
"isRealtimeData":false},
{"line":"7",
"destination":"Reppe",
"registeredDepartureTime":"2011-05-18T05:38:00.000",
"scheduledDepartureTime":"2011-05-18T05:38:00.000",
"isRealtimeData":false},
{"line":"11",
"destination":"Brandhaugen",
"registeredDepartureTime":"2011-05-18T05:58:00.000",
"scheduledDepartureTime":"2011-05-18T05:58:00.000",
"isRealtimeData":false},
{"line":"36",
"destination":"Stokkhaugen",
"registeredDepartureTime":"2011-05-18T06:03:00.000",
"scheduledDepartureTime":"2011-05-18T06:03:00.000",
"isRealtimeData":false},
{"line":"20",
"destination":"Valentinlyst",
"registeredDepartureTime":"2011-05-18T06:08:00.000",
"scheduledDepartureTime":"2011-05-18T06:08:00.000",
"isRealtimeData":false}]}
That’s how you wanted the data in the first place isn’t it?
The data mining about bus stops isn’t complete, and we still got some job left to do. We couldn’t extract the whole bus stop lists from their web service call as the longitude and latitude coordinates was way off, at least we didn’t make any sense out of it, so we’ve been mining bus stops by storings important values from every “departures” call that is done on our API, since AtB original API delivers some “bloated” data towards the query of fetching departures. Another funny thing is all their bus stops is saved/exported in their abbreviation of the street name. As of writing this post, we basically saved all those names in the “name” attribute for busstop and we manually fixed em. We’ve also added code for the next departures requests our API does to fill out the missing fields such as bus stop maintainer, and the abbreviated name once again in it’s correct place. (why we didn’t do this in the first place is rather stupid, but I guess we were tired minds .. hehe).
