logo
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Login


Options
View
Go to last post Go to first unread
Benjamin  
#1 Posted : Saturday, December 3, 2011 1:14:31 PM(UTC)
Benjamin

Rank: Advanced Member

Groups: Registered
Joined: 7/10/2011(UTC)
Posts: 34

Thanks: 1 times
I pull a copy of the stops.getList output after each GTFS change, and after the change on 11/29 it seems like there were a lot of changes: stops were added and the stop_ids for a bunch of text-message codes changed. Is this correct or do I have some wonky data? (Yes, I am still using API v1 for this.)
Ryan  
#2 Posted : Monday, December 5, 2011 8:30:08 AM(UTC)
Ryan

Rank: Administration

Groups: Administrators, Registered
Joined: 6/1/2011(UTC)
Posts: 88
United States
Location: Urbana

Thanks: 1 times
Was thanked: 6 time(s) in 6 post(s)
I've looked over the output from stops.getList again and everything looks OK to me.

There probably are some new stops because, in the process of updating the API, we found a bug in version 1 that was causing some stops to not be returned. We also loaded a new set of data so there may be a stop here or there that has been added or deleted (although not very many). That being said, there shouldn't be any stops that have changed SMS codes.

Can you give me an example or two of what you're talking about and I can try to give you some more specific answers.
Benjamin  
#3 Posted : Monday, December 5, 2011 10:36:20 AM(UTC)
Benjamin

Rank: Advanced Member

Groups: Registered
Joined: 7/10/2011(UTC)
Posts: 34

Thanks: 1 times
Sure. Here is a diff of the old data and the new data in the JSON format I use. Each line represents one text-message code; "id" is the stop_id and "verbose" is the stop name. As you can see, most of the differences are in the portion of the stop_id after the colon. (I don't know whether the data returned for e.g. PHILOSLVR:4 is actually different from PHILOSLVR:8.) Especially at the end you can see a bunch of completely-new stops.
Ryan  
#4 Posted : Monday, December 5, 2011 11:40:20 AM(UTC)
Ryan

Rank: Administration

Groups: Administrators, Registered
Joined: 6/1/2011(UTC)
Posts: 88
United States
Location: Urbana

Thanks: 1 times
Was thanked: 6 time(s) in 6 post(s)
I looked through your diff and I think the issue you are having is related to the previously mentioned bug where some stops were not being returned. From what I can tell all the data looks good. In regards to your example about the PHILOSLVR stop, both PHILOSLVR:4 and PHILOSLVR:8 are valid stop points.

I think it may be helpful for me to explain the difference between stops and stop points. One of the big changes we made with version 2.0 of the API was to better distinguish between the two. A stop point is a specific point where a bus stops (e.g. the NW corner of Philo and Silver). A stop is a collection of all the stop points at a location (e.g. Philo and Silver). In version 1.0 we only return stop points and don't group them in any way (This was done to reflect the GTFS format). We have since decided that this format, although matching GTFS, does not sufficiently represent our data. So, for version 2.0, we added stop objects that hold stop points. For example:

Code:

{
   "changeset_id":"08AE3609ACA4426C52F54E28363179EE",
   "time":"2011-12-05T11:28:40-06:00",
   "status":{
      "code":200,
      "msg":"ok"
   },
   "stops":[
      {
         "stop_id":"PHILOSLVR",
         "stop_name":"Philo and Silver",
         "code":"MTD3655",
         "points":[
            {
               "code":"MTD3655",
               "stop_id":"PHILOSLVR:2",
               "stop_lat":40.091365,
               "stop_lon":-88.190553,
               "stop_name":"Philo & Silver"
            },
            {
               "code":"MTD3655",
               "stop_id":"PHILOSLVR:3",
               "stop_lat":40.091457,
               "stop_lon":-88.190787,
               "stop_name":"Philo & Silver"
            },
            {
               "code":"MTD3655",
               "stop_id":"PHILOSLVR:4",
               "stop_lat":40.091564,
               "stop_lon":-88.190681,
               "stop_name":"Philo & Silver"
            },
            {
               "code":"MTD3655",
               "stop_id":"PHILOSLVR:8",
               "stop_lat":40.091519,
               "stop_lon":-88.191061,
               "stop_name":"Philo & Silver"
            }
         ]
      }
   ]
}


You can get real time departures for both stops and stop points. If you request a stop it will return all departures for that location (departures for all stop points), if you request a stop point it will only return departures for that specific point. This can be useful for high frequency locations such as the Terminal, but in the vast majority of cases I would strongly recommend using stops. The PHILOSLVR stop is a perfect example of why. Take a look at these two method calls:

http://developer.cumtd.c...&stop_id=PHILOSLVR:4
http://developer.cumtd.c...&stop_id=PHILOSLVR:8

You can see that PHILOSLVR:8 is used during the week and PHILOSLVR:4 is used on Saturdays. Using a specific stop point to request departures would result in not getting departures for either Saturday or weekdays. If you request departures for the stop however you will get all departures for Philo and Silver.

Note that if you have a a stop_id for a stop point you can simply drop everything after the colon and get the stop so PHILOSLVR:4 becomes PHILOSLVR.

Sorry for the excessive length of this answer, but I hope it was helpful...
Benjamin  
#5 Posted : Tuesday, December 6, 2011 12:49:37 PM(UTC)
Benjamin

Rank: Advanced Member

Groups: Registered
Joined: 7/10/2011(UTC)
Posts: 34

Thanks: 1 times
No, that was very helpful, thanks! Do you have a list of stops for which I should use the stop points? (I’ll guess the Terminal and the Transit Plaza?)

I’m planning to (eventually) add a look-up-your-stop feature to my app instead of making the users provide the text-message codes, so the API v2 changes will be a big help!
Ryan  
#6 Posted : Tuesday, December 6, 2011 1:23:33 PM(UTC)
Ryan

Rank: Administration

Groups: Administrators, Registered
Joined: 6/1/2011(UTC)
Posts: 88
United States
Location: Urbana

Thanks: 1 times
Was thanked: 6 time(s) in 6 post(s)
Every stop has stop points, but The Terminal and Transit Plaza are currently the only two stops where we assign different text messages codes to the individual stop points. We do this primarily because of the high frequency in these areas and the character limits associated with text messaging. Whether you want to distinguish between them in your app is up to you (I'm guessing it would depend on how much information you can display and how much knowledge of our system you want to assume your users have.)

I'm glad to hear you're planning on adding stop searching. It's one of our favorite new features with v2.0 and I'm excited to see it start getting some use.
Users browsing this topic
Guest (2)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.