MTA Bus Time SIRI XML feed error

[Will]

Hi all,

This seems to have been happening for a number of days now. The SIRI bus time feed for individual stops is working fine with the JSON end point e.g.
http://bustime.mta.info/api/stop-for-id?_=1351878649347&stopId=MTA_305364

However, the XML endpoint no longer works properly:
http://bustime.mta.info/api/siri/stop-monitoring.xml?key=[KEY_HERE]&OperatorRef=MTA%20NYCT&LineRef=B63&MonitoringRef=305364
(I've removed our key from the URL).
The response says "No such stop":

<Siri xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns4="http://datex2.eu/schema/1_0/1_0" xmlns:ns3="http://www.ifopt.org.uk/ifopt"xmlns="http://www.siri.org.uk/siri">

<ServiceDelivery>

<ResponseTimestamp>2012-11-03T11:11:47.230-04:00</ResponseTimestamp>

<StopMonitoringDelivery>

<ResponseTimestamp>2012-11-03T11:11:47.230-04:00</ResponseTimestamp>

<ErrorCondition>

<OtherError>

<ErrorText>No such stop: MTA NYCT_305364.</ErrorText>

</OtherError>

<Description>No such stop: MTA NYCT_305364.</Description>

</ErrorCondition>

</StopMonitoringDelivery>

</ServiceDelivery>

</Siri>

Any ideas?

Will
Developer of Bus New York City for iPhone

[Will]

After more testing, removing the OperatorRef URL parameter makes it work:
http://bustime.mta.info/api/siri/stop-monitoring.xml?key=[KEY_HERE]&LineRef=B63&MonitoringRef=305364
However, the API says that this is a required parameter.

[Nabil Mouzannar]

How are the guys at "Embark NYC" able to display the statuses?

Sent from my IPhone

[Jeremy Baron]

On Sat, Nov 3, 2012 at 6:50 PM, Nabil Mouzannar <nabb...@gmail.com> wrote:
> How are the guys at "Embark NYC" able to display the statuses?

IDK exactly what they're doing but the end result is at least incomplete.

They (embark, in the app on my Jelly Bean phone) are currently are
showing no alerts at all for 1,2,3,A,C,D,M,J,N,Q,R,L and those should
all have alerts. (and there's no mention of the Z at all but the
archives of this list will attest that the J and Z are twin siblings)
Also, 6,7 have no alerts but I think both of those are essentially
back to normal?

-Jeremy

[John Paul N.]

Will, if you replace the OperatorRef from MTA%20NYCT to MTA, it should
be fine. This is related to Mike Frumin's previous message about
coming changes to Bus Time:
http://groups.google.com/group/mtadeveloperresources/browse_thread/thread/b92e0ec8058a1315

On Nov 3, 11:26 am, Will <w...@electriclabs.com> wrote:
> After more testing, removing the OperatorRef URL parameter makes it work:http://bustime.mta.info/api/siri/stop-monitoring.xml?key=[KEY_HERE]&LineRef=B63&MonitoringRef=305364<http://bustime.mta.info/api/siri/stop-monitoring.xml?key=[KEY_HERE]&OperatorRef=MTA%20NYCT&LineRef=B63&MonitoringRef=305364>

> However, the API says that this is a required parameter.
>
>
>
>
>
>
>
> On Saturday, November 3, 2012 3:16:31 PM UTC, Will wrote:
>
> > Hi all,
>
> > This seems to have been happening for a number of days now. The SIRI bus
> > time feed for individual stops is working fine with the JSON end point e.g.

> >http://bustime.mta.info/api/stop-for-id?_=1351878649347&stopId=MTA_30...

[Will]

Replacing: "MTA%20NYCT" with MTA does not seem to fix it. Instead, a new error message appears (see below). I do remember now that Michael said the OperatorRef parameter would become optional, but by not including it, the response time from the server would be slightly slower. Perhaps that's my best bet for the time being.

<Siri xmlns:ns2="http://www.ifopt.org.uk/acsb" xmlns:ns4="http://datex2.eu/schema/1_0/1_0" xmlns:ns3="http://www.ifopt.org.uk/ifopt"xmlns="http://www.siri.org.uk/siri">

<ServiceDelivery>

<ResponseTimestamp>2012-11-04T07:22:19.815-05:00</ResponseTimestamp>

<StopMonitoringDelivery>

<ResponseTimestamp>2012-11-04T07:22:19.815-05:00</ResponseTimestamp>

<ErrorCondition>

<OtherError>

<ErrorText>No such route: MTA_B63.</ErrorText>

</OtherError>

<Description>No such route: MTA_B63.</Description>

</ErrorCondition>

</StopMonitoringDelivery>

</ServiceDelivery>

</Siri>

[John Paul N.]

On Nov 4, 7:24 am, Will <w...@electriclabs.com> wrote:
> Replacing: "MTA%20NYCT" with MTA does not seem to fix it. Instead, a new
> error message appears (see below).

I don't use LineRef when I do my query, so that's why I got a valid
response. When I tried setting LineRef to MTA%20NYCT_B63 that worked
for me, so I hope that helps.

[Will]

Unfortunately, this seems to be happening again. The JSON end point seems to be working fine:

http://bustime.mta.info/api/stop-for-id?_=1351878649347&stopId=MTA_305364

But the XML end point no longer seems to recognise the stop:
http://bustime.mta.info/api/siri/stop-monitoring.xml?key=[KEY_HERE]&OperatorRef=MTA%20NYCT&LineRef=B63&MonitoringRef=305364

I have tried removing LineRef, but no luck. However, if I alter the MonitoringRef to align with the stopId of the JSON API, it starts working again:

http://bustime.mta.info/api/siri/stop-monitoring.xml?key=[KEY_HERE]&OperatorRef=MTA%20NYCT&LineRef=B63&MonitoringRef=MTA_305364

and again, the other two parameters don't seem to make any difference if I do this:

http://bustime.mta.info/api/siri/stop-monitoring.xml?key=[KEY_HERE]&MonitoringRef=MTA_305364

(this works).

I'm a little confused as to whether there has been a regression in the Bus Time API, or whether I'm querying it wrong. This has certainly changed in behaviour compared to what it was doing a few weeks back. It would be useful to update the main Bus Time docs here to reflect the change notes here including sample request URLs so I know the ideal way that we should be querying the API.

Thanks,

Will

On Saturday, November 3, 2012 3:16:31 PM UTC, Will wrote:

[Frumin, Michael]

Will, good questions.

 

First, a comment: the stop-for-id is an unofficial/unsupported API call.  It is developed specifically to meet the needs of the map-based UI Bus Time provides and as such is not publicly documented nor is accompanied by any guarantee of support or backwards compatability, and can change at any time with no warning.  We *strongly* recommend only the use of the SIRI API and the OneBusAway API, which we need to publicize.

 

Also, please note that the SIRI API’s provide either JSON or XML, depending on how you make the call.  http://.../stop-monitoring.xml?... Will yield an XML reponse, while http://.../stop-monitoring.json?... will yield JSON.

 

As for your issues with those specific SIRI Calls, the issue has to do with how things changed when we launced the Bronx a couple of weeks back (since the Bronx has MTA NYCT and MTABC).  The changes were described in advance on the ChangeLog (http://bustime.mta.info/wiki/Developers/ChangeLog) with an accompanying post to the MTADevelopers google group.

 

The problem you are having is with your use of the OperatorRef.  All stops now have agency_id/OperatorRef of “MTA”.  As such, for StopMonitoring calls, please use either:

-          ….&OperatorRef=MTA&MonitoringRef=123456

-          ….&MonitoringRef=MTA_123456  (with no OperatorRef at all)

 

Hope this helps.  Sorry for the docs lagging (Bronx was launched just before Sandy), we’re working on fixing that this morning.

 

Thanks

Mike