Incorrect schedules for ~1200 trips (associations)

[tafflin]

Hi @linusnorton ,
I noticed that there is a trip in stop_times of a resulting GTFS which consists only of 1 station.
Digging deeper I found that the issue might be in the trips which have association by train uid.

The example train uids are: L07257 and L07493.
In the records in mysql table "stop_time" for the train_uid='43237' I can see that it is 100% correct and is equal to what I see in the source .mca file. However when the GTFS is generated based on this trip and it's association with another train_uid it results in a trip with a trip_headsign='L07257_L07493' and it consists only of one stop which is the "assoc_locaction=DONC".

Looks like the two trips which are outbound and inbound according to the used stops in the source .mca file are being merged in a strange way.
Since there are ~1200 trips in the resulting GTFS which have concatinated train uids in the trip_headsign field I made a conclusion that ~1200 trips are incorrectly converted. I also checked some other randomly and the issue is the same as described above.

I attached the original file
https://drive.google.com/file/d/1eiRbPhwpN56ba98rQhTHm5DwZ84jStth/view?usp=sharing
and the one we converted (or it is better that you convert with your latest version)
https://drive.google.com/file/d/1nMV5kmpkMXN3YQJNtrpJzHAjMYXauYrs/view?usp=sharing

[linusnorton]

GTFS does not support associations so they are combined into a new trip. See the details on the Associations section of https://ljn.io/posts/CIF-to-GTFS

[tafflin]

@linusnorton but when the 2 trips one from X to Y (13 stops) and another from Y to X (13 stops) are combined into a new trip with the only stop X, is it a correct conversion logic?
Can these associated trips be just separated to retain at least part of the information? Currently all the trips which have association record in the source files are converted completely incorrecly. Can they be set apart or not converted at all?

[linusnorton]

It looks like a data issue to me. The base_uid and the assoc_uid appear to be the wrong way around. Normally a join consists of assoc service up to the point of join + base from the point of join. In this case the point of join is the first stop of the assoc and the last stop of the base so all you get is the one stop.

[tafflin]

Even though it may be a data issue in this very case, I have not yet managed to find any correctly converted associations in the latest data. Is it possible to add a parameter which disables the logic for associations when creating a GTFS from temp mysql tables?

[linusnorton]

I'm just going to cross reference with what is in the DTD feed

[linusnorton]

C83835_C83858 should have converted correctly - is that in your output?

[tafflin]

ok I see what you mean.
So as I understand there is a problem in the network rail atoc data as well as no 100% correct solution to convert such data to GTFS?

[linusnorton]

I've added a check to avoid outputting trips with a single stop. I should be in version 6.4.3

[tafflin]

@linusnorton I have a question about associated trips.
I looked a bit more closely to the different trips with associations. In your example the trip with trip_headsign='C83835_C83858' is combined of a base_uid='C83858' and assoc_uid='C83835'.
The trip in GTFS stop_times starts from the stops from associated trip C83835 then switches on the assoc stop to the base trip C83858. So the assoc trip merges with the base trip on the mentioned stop.
Should it be this way or the way around? e.g. start with base trip and continue with the associated?
According to the current logic the trip L07257_L07493 will indeed have only 1 stop in it

[linusnorton]

It works differently for joins and splits.

For a join, the associated service joins the base service. That means as well as keeping the original base service, we can add a new combined service of assoc start -> join point + join point + 1 -> end of base service. That's why the assoc tuid is first: assocTuid_baseTuid

For a split, the associated service branches off from the base service. That means we create base service start -> split point + split point + 1 -> end of assoc service. In this case the constructed tuid is baseTuid_assocTuid