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

Stops allocated to agency arbitrarily? #2407

Closed
steveathon opened this Issue Feb 26, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@steveathon

steveathon commented Feb 26, 2017

I'm having a problem with the way the GTFS feed generates stop relationships to agencies in order to use the index API. This doesn't affect any routing or other route / trip information but specifically causes a problem when you only have the stopid and you want to interrogate data from there.

Expected behavior

stops.txt has no agency in GTFS feeds until you compile it with trips, then routes, then agencies - thus a stop has a defined agency indirectly and sometimes multiple agencies. But to call any of the index API endpoints you need to provide an agency to recall the stop information (routes servicing as an example). In theory you should be able to call a stop without an agency as multiple agencies may service some stops on many transport networks.

Observed behavior

Depending on the order of the trips data, a different agency is assigned to a stop as the owner, even if the owner was previously something else. As an example, in one GTFS feed the owner of all the stops in the target feed were assigned to one agency. A change in the trips data caused all stops to be owned by a different agency. Even when that agency does NOT have any services, trips or routes that are connected with that stop.

This caused an incompatible state between the OTP application graph and an external application graph, requiring a translation table (agency X actually means agency Y if you hit the index API) in order to provide only the stop ID and still see all routes.

Version of OTP used (exact commit hash or JAR name)

This is 0.19 stable - so it may be fixed in later versions.

@johannilsson

This comment has been minimized.

Show comment
Hide comment
@johannilsson

johannilsson Feb 26, 2017

Contributor

This has been adressed for v1.0 in #1999. Instead of using the agency id stops and other entities is now scoped by a feed id. The feed id is picked up from the feed_id field in feed_info.txt. If a feed id is not provided OTP will assign the GTFS feed an id.

You can use the index API /index/feeds to list available feed ids.

Contributor

johannilsson commented Feb 26, 2017

This has been adressed for v1.0 in #1999. Instead of using the agency id stops and other entities is now scoped by a feed id. The feed id is picked up from the feed_id field in feed_info.txt. If a feed id is not provided OTP will assign the GTFS feed an id.

You can use the index API /index/feeds to list available feed ids.

@steveathon

This comment has been minimized.

Show comment
Hide comment
@steveathon

steveathon Feb 26, 2017

Oh excellent - I'll test this out with v1.0 and create a feed_info.txt file for my feed, if that solves my logic issue I'll upgrade. Thanks @johannilsson!

steveathon commented Feb 26, 2017

Oh excellent - I'll test this out with v1.0 and create a feed_info.txt file for my feed, if that solves my logic issue I'll upgrade. Thanks @johannilsson!

@steveathon

This comment has been minimized.

Show comment
Hide comment
@steveathon

steveathon Mar 5, 2017

Indeed this has resolved the issue I was finding. Thanks @johannilsson!

steveathon commented Mar 5, 2017

Indeed this has resolved the issue I was finding. Thanks @johannilsson!

@steveathon steveathon closed this Mar 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment