While on the subject of the MTA service status can I suggest a couple
of improvements.
The subway section of the feed often contains html/css markup that
makes it hard for us to present the data in a unified manner within
our client applications. This would be greatly improved if the
following were taken into consideration:
- The feed should not include font information
- Font size should be expressed in em rather than absolute pixel
sizes
- Markup should not use tags beyond paragraphs (p), line breaks (br),
bold (b), emphasis (em), italic (i).
- Text colour should be used very sparingly- perhaps red to indicate
a major incident, although even this isn't really necessary.
Would appreciate if someone could give this feedback to the relevant
people.
Cheers,
Will
On Apr 6, 5:29 pm, Aaron Donovan <adono...@mtahq.org> wrote:
The MTA doesn't have unlimited funds for this and clearly the markup is being used elsewhere (e.g. this is being fed from some system that winds up on the web). Personally I'm just glad they're providing a feed and I don't have to resort to screen scraping.
I (along with other developers) just take the extra step of stripping out the markup and using the other data in the feed. It's not hard or time-consuming. It would be great if they could get rid of the HTML, but only if it doesn't change the quality or timeliness of the data.
> While on the subject of the MTA service status can I suggest a couple > of improvements.
> The subway section of the feed often contains html/css markup that > makes it hard for us to present the data in a unified manner within > our client applications. This would be greatly improved if the > following were taken into consideration:
> - The feed should not include font information > - Font size should be expressed in em rather than absolute pixel > sizes > - Markup should not use tags beyond paragraphs (p), line breaks (br), > bold (b), emphasis (em), italic (i). > - Text colour should be used very sparingly- perhaps red to indicate > a major incident, although even this isn't really necessary.
> Would appreciate if someone could give this feedback to the relevant > people.
I understand that the MTA doesn't have unlimited funds and I too am very grateful that they are providing something for devs but if this is the forum to suggest improvements, I'd like to bring up JSON and API endpoints. It's just a suggestion for the future.
It would be great if the service status could return JSON. Most APIs that are designed now aren't even bothering with XML (see Instagram and Dribbble for examples). I understand that the MTA is obviously using this feed elsewhere (hence the HTML in the XML) so they rely on the feed being XML but there's no reason they can't return both. Also, allowing for JSONP would be another great improvement, especially for those writing AJAX applications. My other suggestion is endpoints. Rather than calling the Service Status URL and parsing all the XML. It would be nice to query an endpoint for a train and have the data be specific to that train. For example, a dev could query a URL that looks like: "http://status.mta.info/subway/R" and the API would return:
Now I'm not all suggestions, I also have a contribution to share since we're on the topic– I wrote a PHP library a day or two ago to make it easier for devs to interact with the Service Status feed (https://github.com/jgv/sandhog). PHP isn't my strongest suit and there's a lot of room for improvement so anyone please feel free to fork and refactor or tackle one of the issues on Github if that's your thing. There's a Ruby Gem that I'm working on and will probably release over the weekend that has a similar functionality.
On Thu, Apr 7, 2011 at 5:40 AM, Will R <w...@electriclabs.com> wrote: > While on the subject of the MTA service status can I suggest a couple > of improvements.
> The subway section of the feed often contains html/css markup that > makes it hard for us to present the data in a unified manner within > our client applications. This would be greatly improved if the > following were taken into consideration:
> - The feed should not include font information > - Font size should be expressed in em rather than absolute pixel > sizes > - Markup should not use tags beyond paragraphs (p), line breaks (br), > bold (b), emphasis (em), italic (i). > - Text colour should be used very sparingly- perhaps red to indicate > a major incident, although even this isn't really necessary.
> Would appreciate if someone could give this feedback to the relevant > people.
In June 2011 we were asked to test a new service advisories feed in XML based on MTA's TripPlanner. The feed was a huge improvement over the current feed, and it was supposed to go Live July 2011.
I haven't heard anything about the project since. Can someone at the MTA update us as to the status of the revised service advisory feed?
