search

OneBusAway / onebusaway-gtfs-modules

A Java-based library for reading, writing, and transforming public transit data in the GTFS format, including database support.
Other
129 stars 106 forks source link

Transformation skips first Agency entry #199

Closed wiim00 closed 2 years ago

wiim00 commented 2 years ago

Summary:

When using the onebusaway-gtfs-transform library, the first entry (index 0) of the GTFS file is ignored/skipped.

Steps to reproduce:

Apply the transformation on the "nasa.gtfs.zip" with the "modifications-vetter-updated.txt". CLI Command: java -jar onebusaway-gtfs-transformer-cli-1.3.4.jar --transform=modifications-vetter-updated.txt nasa.gtfs.zip vetter_updated.gtfs.zip Compare the "vetter_updated.gtfs.zip" with the "modifications-vetter-updated.txt".

Expected behavior:

Only have 2 remaining Agencies in the output file. Or in other words, apply the transformation on all agencies.

Observed behavior:

The first entry in the input gtfs file is (always) included in the output file, no matter if it matches the transformation or not. The output file contains 3 agencies instead of 2. The remove operation has also no affect.

Platform:

Tested Operating Systems: Windows, Mac OS Tested Java Version: 11 Tested onebusaway Versions: 1.3.88, 1.3.112

onebusaway_bug nasa.gtfs.zip modifications-vetter-updated.txt vetter_updated.gtfs.zip

bdferris-v2 commented 2 years ago

I think this is a fluke of the way the OBA GTFS libraries are implemented. Specifically, in order to support multiple GTFS entities from different feeds with overlapping ids, most GTFS entities have an AgencyAndId object as its primary key. Aka the agency id associated with each entity is used as a unique prefix. This makes sense for things like routes and trips that have a natural association with an agency. It gets more confusing for things like stops, which can technically be used by routes from multiple agencies. Despite this ambiguity, the OBA GTFS libraries attempt to assign an agency to each stop when reading in a feed, often defaulting to the first feed in the agency.txt file.

So what does that have to do with your bug? I think when reading in your feed, the stops in your feed are getting assigned to the first agency in the feed. Then, when you retain a different agency, it retains the associated routes => trips => stop-times => stops ... and the corresponding agency.

Relevant code

I wrote that code a long time ago and even put in a comment, but I can't remember the /exact/ circumstances that required it. There's maybe a world where it makes sense to remove that line?

In the meantime, there might be a workaround to try. I believe the transformer supports a --agencyId=id command-line flag that determines the default agency used for stops. If you specify the id of one of the agencies you were going to keep anyway, I think it might just work? Aka it won't keep the extra agency.

wiim00 commented 2 years ago

Alright, thank you very much. We now use your workaround. If we stumble across this issue again, we'll see if we can work out a solution for that.

I'll close the issue.