To be accurate, the message wasn’t complete gibberish – but {"Colour": "#009639", "text": "Flinders Street"} – JSON formatted data for ‘Flinders Street’ and hex colour code for green ‘#009639‘.

Many people guessed that the cause of this bug is “colour” vs “color” spelling, with CSS requiring the use of the American ‘color’ spelling, but it’s actually a much more obscure bug…

The backstory

When first delivered back in the early-2000s, the fleet of Siemens trains in Melbourne were fitted with a low resolution LED matrix display to show the names of upcoming stations.

However two decades later this passenger information and communication system was approaching the end of life, so an upgraded system was installed in two stages – the first being the new hardware being installed, but operating the same as the previous system, but on the new high resolution LED displays.

And followed by stage two – a software change to show a dynamic route map to passengers.

But there was one problem – the Siemens trains are 3-car sets, coupled together to form a 6-car train in normal operation, with communication signals sent across the coupler.

But if an train with the updated dynamic route map software leads an unmodified train, the payload for other half of the train to display is JSON formatted, which an unmodified train doesn’t know how to handle, and so blindly spits out the gibberish to the passenger facing displays.

At least the data structure they chose wasn’t XML – or even worse, YAML.

A Twitter related footnote

I originally posted the above video to Twitter, went to bed, and realised a few days later it had 830,000 views, 21,000 likes 1,900 retweets and 83 comments against it.

I didn’t notice it at the time because I’m not a heathen who enables notifications on their phone.

Post retrieved by 35.215.163.46 using

The post On a Siemens train headed to JSON station appeared first on Waking up in Geelong.

Some background

An integral part of the original Myki system was ticket machines onboard trams – they would have allowed passengers to top up their myki, or to purchase a ‘Short Term Ticket’ if they didn’t hold a myki.

A single ticket machine was installed onboard a Melbourne tram in early 2009 as part of the myki field trial program, with it remaining in place but not in use until at least November 2011.

Short Term Tickets were a cardboard smartcard which entitled the holder to 2 hour of travel, for a cost slightly more than the normal fare charged to standard myki users.

Sales of these tickets commenced in 2009 when Myki went live in Geelong, and they continue to be sold onboard buses in Geelong, Ballarat, Bendigo, Seymour and the Latrobe Valley until 2013.

In Melbourne the sale of Short Term Tickets was never enabled, with the option to do so being disabled for all myki machines located in the city.

The rollout of short term fares and myki machines onboard trams was cancelled by the Baillieu Government in June 2011, acting on advice contained in a secret report by consulting firm Deloitte.

One reason given for the reason for the withdrawal of Short Term Ticket was due to the cards costing $0.40 cents each to manufacture – making up almost half of the $0.90 charged for a concession bus fare in Geelong!

In 2011 Yarra Trams said that the change would reduce the tram company’s costs, boost space for passengers and reduce fare evasion issues by eliminating a key reason given for not buying a ticket.

Everyone else says the cancellation of Short Term Tickets and onboard top ups make it much more difficult for passengers who only use trams to pay their fare.

Enter the Public Transport Victoria API

Back in March 2014 Public Transport Victoria finally opened up the application program interface (API) which powers their mobile apps, so I decided to have a play around with it.

With the mobile landscape already littered with hundreds of different trip planning apps, I decided to build something slightly different – something to point out how the lack of ticket purchase options onboard trams was wasting the time of the intending passengers.

The API allows programmers to access all kinds of data – tram routes and Myki retailers being two of them, so I built an app that caters for two use cases:

• you’re at home, work, or a friend’s house – and you’ve discovered that you don’t have a Myki on hand. Where is the nearest place to buy a new one, and how far will this detour take compared to purchasing a ticket onboard the tram?
• you’ve just stepped onto a tram and discovered that you don’t have any credit left on your Myki. How far will you have to walk to top up, and then where can you get back on your way?

The end result is ‘walki‘ – a small app that works on any device with a web browser.

The logic in the app is as follows:

1. Show the user their current location,
2. Calculate distance to nearest tram stop,
3. Calculate distance to nearest Myki retailer,
4. Calculate distance from Myki retailer back to nearest tram stop,
5. Plot the walking routes on a map,
6. Compare the distances for each,
7. And finally, show the user much further they have to walk thanks to the lack of ticket sales onboard trams.

Simple?

You can see it for yourself at https://wongm.com/walki/, or using these examples.

Technology

The app itself isn’t anything revolutionary from a technology standpoint.

In the backend I’m using boring old PHP to gather tram stop and myki retailer locations through calls to the PTV API, with the resulting data being mashed around in Javascript until they are drawn out on a pretty map.

The frontend code is static HTML files with a smattering of jQuery Mobile (‘state of the art’ for 2014? :-P) over the top, with the maps being drawn using the Google Maps JavaScript API v3.

The files are all hosted on my vanilla Apache web server, and you can find the source code on GitHub.

Footnote

Here is the original article from The Age – Melbourne’s myki retailers: Where is the nearest place to top up my myki?, by Craig Butt and Andy Ball.

They are the myki dead zones – the tram stops where the nearest place to top up your myki is at least a kilometre away.

If you do not have any credit on your myki you are expected to take reasonable steps to top up, but from these locations you rack up at least 1200 paces to get to the nearest store or machine.

Using the interactive below, you can detect myki dead zones on your tram line and find out where the nearest myki retailer is, in case you ever find yourself short on credit.

One consideration I completely forgot about was the opening hours of Myki retailers:

But keep in mind the opening times of the retailer. When we trekked 1.5 kilometres through Melbourne’s biggest myki desert on a scorching 31 degree day to top up at Bundoora Post Office, we were fortunate enough to get there half an hour before closing time.

But we would have been out of luck after 5pm that afternoon, after midday on Saturday, or when it is closed all day on Sunday.

About 95 per cent of the state’s 800-plus myki retail outlets are open on Saturday, 75 per cent on Sunday and 32.5 per cent are open all hours.

But one thing we did agree on is the lack of Myki retailers along route 86.

And if you live near Plenty Road in Bundoora and rely on the route 86 tram, you’re in the worst spot in Melbourne.

The stop at the corner of Plenty Road and Greenwood Drive is the worst myki dead zone in Victoria for trams. If you forget your card or are out of credit, it’s a 1.5 kilometre walk to the nearest post office to top up.

I included a few examples in my app, one from Reservoir resulting in an extra 1.86 kilometre (23 minute) long walk!

Post retrieved by 35.215.163.46 using

The post How far is Myki making you walk? appeared first on Waking up in Geelong.

Unlike other public transport operators, Yarra Trams actually took my feedback on board and released an updated web version of TramTracker a month later, but unfortunately for me, they were not enough to make it work with my ancient WAP only phone.

As a result, I took inspiration from my recent experiments with PTV’s new API, and came up with a simple website to give access to TramTracker data.

Called ‘Jake Junior: TramTracker for Dumbphones’, you can give it a go at http://jakejunior.wongm.com/.

Some background

TramTracker first appeared in Melbourne way back in December 2006, with only two ways of accessing tram arrival information: voice or SMS reply. However usage of the service didn’t take off until 2009, when an incredibly well designed iPhone app was released, providing a much more convenient way to find tram stops and arrival times.

Since then additional methods of access have been provided – a mobile friendly website for non-iPhone devices, a ‘webPID’ for desktop computers in 2009, and an Android app in October 2012. Third-party developers have also built their own apps for the TramTracker service – the most interesting one I’ve found so far is TramFinder for Pebble watches!

One thing these third-party apps have in common is their source of tram arrival data – a public API found at http://ws.tramtracker.com.au/pidsservice/pids.asmx. This API isn’t the easiest thing to play around with because it follows the SOAP specification for webservices – a horrible tarball of XML requests being sent back and forth between devices.

Messing around with SOAP isn’t my idea of fun, so I put building my own ‘simple’ version of TramTracker on the backburner, until I discovered that the new version of the TramTracker website was actually using RESTful calls to a backend service that was returning JSON

I was unsure if that version of the API was actually designed for the public to consume, so I posed the question on Twitter, only for the original developer of the TramTracker iPhone app to give me an answer:

@aussiewongm @petehare they’re on the same infrastructure so it shouldn’t matter so much.

— Rob Amos (@bok_) March 14, 2014

With that in mind, I spent a few hours cobbling together some PHP code, with ‘Jake Junior’ being the end result.

How it works

Internally ‘Jake Junior’ is just a single PHP file – you can find the source code at https://github.com/wongm/jake-junior.

All of the HTML is incredibly simple and all of the heavy lifting is done server side – no javascript or images are required. The home page presents a simple TramTracker ID input box and a ‘Go button, which then loads the next three trams for each route passing through the given stop. Where multiple routes pass through a stop, links are provided to allow you to filter by route. Bookmarking a stop is also simple, as the URLs always lead you back to your intended tram stop and route combination.

Stop information and tram arrival times are retrieved using two hits to the TramTracker API: unfortunately it doesn’t combine the two types of data into a single method.

To get the name and direction of a tram stop, I used to the ‘GetStopInformation’ endpoint:

http://tramtracker.com/Controllers/GetStopInformation.ashx?s=1234

And for the arrival times, the ‘GetNextPredictionsForStop’ endpoint:
http://www.tramtracker.com/Controllers/GetNextPredictionsForStop.ashx?stopNo=1234&routeNo=0&isLowFloor=false

By the way – TramTracker ID 1234 is on route 1 in South Melbourne!

Once I had the results of the two API calls as a JSON string, I was able to deserialise the data, do some simple maths to convert the JSON timestamp into a minutes until arrival figure, and then output it all as HTML.

You can play around with the end result at http://jakejunior.wongm.com.

Footnote

If you are wondering about the ‘Jake Junior’ name – the official TramTracker mascot is dog named Jake.

Post retrieved by 35.215.163.46 using

The post Making TramTracker work on ‘Dumbphones’ appeared first on Waking up in Geelong.

Unfortunately the new API isn’t perfect – it doesn’t meet the Google-defined GTFS standard that many existing apps support, and no real-time arrival data is available – for trams you have to turn to TramTracker, and for trains and buses you’re on your own.

Despite the above limitations, I jumped into playing around with the API. The full set of documentation can be found at www.data.vic.gov.au, and after I made my API key request on the evening of March 6, I received a reply yesterday – March 11.

With my developer ID and security key received, the first thing to try out is the ‘healthcheck’ endpoint. Each API request needs to be digitally signed with a HMAC-SHA1 hash – this ensures that each request to the PTV servers is coming from a registered developer – and the healthcheck page allows a developer to test if their requests are being built up correctly.

For some people, working out the HMAC-SHA1 signature of each request is easy – the API documentation includes sample code in C#, Java and Objective-C to do just that. Unfortunately for me, my random hacking about is done in PHP, so I needed to roll my own version.

(jump to the end of my sample code)

My initial attempt generated something that looked like a HMAC-SHA1 signature, but it didn’t pass validation – I screwed something up! An hour or so of bashing my head against the wall followed, as I played around with Base64 encoding and byte arrays. but it still wasn’t working

I then tried a different tack – getting the sample C# code working in Powershell. For such an odd tactic it was simple enough to achieve, and I was able to get the code to run and generating a valid signature, which I used to make my first valid API hit. From there I was able to hack about my PHP code until it generated the same signature as the C# code generated – the bit I missed was the upper casing.

The end result from PTV – a small snippet of JSON.

Sample code

Here is the method I wrote to take an API endpoint URL (for example “/v2/healthcheck”) and build up a valid signed URL to request data from.

function generateURLWithDevIDAndKey($apiEndpoint, $developerId, $key)
{
	// append developer ID to API endpoint URL
	if (strpos($apiEndpoint, '?') > 0)
	{
		$apiEndpoint .= "&";
	}
	else
	{
		$apiEndpoint .= "?";
	}
	$apiEndpoint .= "devid=" . $developerId;
	
	// hash the endpoint URL
	$signature = strtoupper(hash_hmac("sha1", $apiEndpoint, $key, false));
	
	// add API endpoint, base URL and signature together
	return "http://timetableapi.ptv.vic.gov.au" . $apiEndpoint . "&signature=" . $signature;
}

And here is a sample usage of the above method. (note the sample data for key and developer ID!)

$key = "9c132d31-6a30-4cac-8d8b-8a1970834799"; // supplied by PTV
$developerId = 2; // supplied by PTV

$date = gmdate('Y-m-d\TH:i:s\Z');
$healthcheckEndpoint = "/v2/healthcheck?timestamp=" . $date;

$signedUrl = generateURLWithDevIDAndKey($healthcheckEndpoint, $developerId, $key);

Now all I need to do is build the wonderful app I have in mind…

Code in GitHub

You can find the above sample code on GitHub at https://github.com/wongm/ptv-api-php-test-harness – all you need to do is update the $key and $developerId values with your own credentials, and it should work on your own server.

Footnote

It looks like plenty of other people are interested in the API – here is a media release from Data.Vic, who host it on behalf of PTV.

The recent release of the PTV Timetable API has, not surprisingly, created the highest level of interest and activity for a single data release on Data.Vic.

In the 7 days since the release of the API data record we have seen:

– Over 3500 data record page views
– More than 700 downloads of the API document, and
– Close to 100 API key requests

Post retrieved by 35.215.163.46 using

The post Testing the PTV transport data API using PHP appeared first on Waking up in Geelong.