Quote:some of the requests are missing certain key information that i think should also be supplied, and all of the requests don't tell you what you requested.
for each request there should be a parameters array listing all of the parameters that the server processed for your request (except maybe your apikey).
eg: i could request multiple shapes for some planned trip itinerary but when the server returns the shape points i have no idea which shape it is giving me let alone what route that corresponds to or how to color it.
since the data isn't loaded via some direct function call, but is loaded by some http request there can be a bit of lag time and it might come in different orders than requested. each time i get data it would be useful to know what precisely i asked for and am getting so i can use and display it accordingly.
currently i have to remove the existing data (eg times) i have displayed, go and change the (stop) label, request the new data (times), and once that goes through display the new data, hoping that whatever data i got last corresponds to the last label i set. i'd much rather leave the existing data and label up until the new data arrives and change them both at the same time, instead of worrying about the label not matching the data.
We've talked about this before and we've been on the fence about it for a while, but we've decided to add this to v2.1. What do you think about the following format:
Code:{
"request":{
"method":"GetShapeBetweenStops",
"params":{
"begin_stop_id":"blah",
"end_stop_id":"blah",
"shape_id":"blah blah"
}
}
}
Quote:GetStopTimesByStop, GetPlannedTripsByLatLon, and GetPlannedTripsByStops need to tell me the date for the provided data in one up front easy to access location. there is also the issue of some requests use your 30hr clock and some only a 24hr clock, i doubt now would be the right time to address that.
StopTimes reference a service_id and are not directly associated with any one date in particular. I don't think there's anything to add on that method. The trip planner methods do have dates and times in each leg. Is that not sufficient?
Quote:GetDeparturesByStop, GetStopTimesByStop, and GetRoutesByStop should also supply the "stops" array that GetStop supplies namely: code stop_lat stop_lon and stop_name should all be provided for each baby stop_id. i shouldn't have to make a separate request to know the name and location of the stop im getting the times for.
Can you make an argument why it's unreasonable to make two requests? I would guess most of the time you'll get the stop_id through one of the stop methods anyways. We've also made it very easy to cache relatively static information like stops using the changeset_id.
Quote:GetStopTimesByTrip should also display the stop location and name for each stop, but instead of an additional stops array, that data would fit better in the existing stop_times array.
You're right. GetStopTimesByTrip should have the full stop and GetStopTimesByStop should have the full trip. We'll change this in v2.1.
Quote:GetShape and GetShapeBetweenStops should list the direction and route_id(s??) that drive that shape, so it can be colored accordingly.
are there different route_id's that drive the same shape???
The route data is very small and should not be an issue to cache. Whatever method you are using to get the shape_id to make this request had to have provided the full trip object with the route_id or the route object itself.
Quote:my understanding is each block consists of multiple trips. each trip has only one service_id and headsign. each service_id has only one shape_id which has only one direction and route_id. multiple service_id's can drive the same shape (eg night and weekend). multiple trip_id's can have the same service_id (eg 10 W at 4pm n 3pm).
correct me if im wrong??? (these terms are not clearly defined on the site)
The structure of our data is largely based on the
GTFS. We've also provided a page with
important definitions to try to make things a bit clearer. Yes each block consists of multiple trips, but keep in mind that a block represents what a physical bus does. If two trips have the same block_id, they will be serviced by the same vehicle. Yes each trip has only one service_id and headsign. I think you might be confused about service_ids. The service_id is used to define what days a given trip operates. Multiple trips with different shapes can reference the same service_id if they operate on the same days. Trips have a direction and belong to a route, not the service_id.
Quote:what i don't understand about GetStopTimesByTrip is: why each stop time lists the trip info over and over again, the stop info(location and name) is what changes so that should be listed for each stop and the trip info should be at the same level as stop_times and listed only once to reduce the transmission size.
As I discussed above, we'll fix this.
Quote:i use the json format and i extract the data i need using object oriented techniques i imagine other people use similar techniques for json and xml. in any event the techniques im familiar with should not affect any of the apps with regards to functionality if this additional info is also provided, seeing how they are most likely ignoring a bunch of the data and only extracting what they need (instead of removing the data they don't need). so can you add this additional data or is there some sort of backwards compatibility thing that it would break???
We'll release a v2.1 with a different URL to ensure no one has issues. While hope everyone is using some sort of OO method of deserializing the data, we can't make any assumptions.
Edited by moderator Monday, January 23, 2012 2:10:45 PM(UTC)
| Reason: formatted json
