[jrockway]

I went that route: https://jrock.us/mta.html

Much better than the MTA's website... though slightly less useful if you're not me commuting to work.

What I learned from this exercise is that:

1) The estimates are consistently inaccurate; downtown trains at Chambers St. always arrive when the clock says "2" (minutes until arrival).

2) They use some sort of distributed cache that doesn't remain consistent; as you bounce between backend instances you get different results, but often the same two results. (The red/green lines under the station names indicate freshness.)

3) The clocks in the stations don't work when it's too hot, but the actual data collection/processing is fine.

[vidarh]

That's interesting. Worked on a service based on TFL (London) data, and they were incredibly picky about ensuring people would not get misled by signage. Of course sometimes there are tradeoffs, but they had extensive rules to ensure the tradeoffs minimised negative experiences. E.g we had to take any buses off the boards if the data was more than x seconds old, never ever allow enough clock drift or other issues to cause our displays to be off by more than a certain amount, clear the whole display if we got no api response within a certain amount of time etc.

It was very annoying to implement, but as a user it is very nice to know how much thought has gone into it.

[infinite8s]

This is pretty awesome - I like how simple yet informative the design is. Do you have a license on the underlying code?