-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stop_code is not returned #2
Comments
Hello Aaron, stop_code was being included previously. I had to do an emergency patch of the proxy to make it compatible with the changes in JSON format between OTP 0.11 and OTP 0.18, essentially translating 0.18 responses into the 0.11 format. Let me check and see if stop_code is still being included in the results. Those Ed |
Aaron, I've fixed the stop_codes. Old version of OTP didn't include stop codes so the proxy had to look them up via GTFS-API. New version of OTP changed how they return the stopId from Here is a test url which uses a recent day, above testing URL is from March where the data is no longer available. |
Note there are some stops which do not have codes, I don't know if this is a problem or not.
|
Thanks, Ed! Yes, we have suggested Anaheim should assign stop_codes to some these. Not On Wed, Oct 21, 2015 at 5:33 PM, Ed Groth [email protected] wrote:
Aaron Antrim, Principal |
stop_code is provided in the GTFS. I believe that OTP does provide this in planner results. We see null values in stop_code from otp-api-proxy.
Example
(http://gtfs-api.ed-groth.com/trip-planner/anaheim-ca-us/plan?fromPlace=33.8046480634388,-117.915358543396&toPlace=33.77272636987434,-117.8671646118164)
The text was updated successfully, but these errors were encountered: