OTP gives "INVALID_STOP_SEQUENCE" error for "overcomplete" GTFS-RT data

[Arilith]

Expected behavior

The specified trip updates are inserted correctly. Maybe give a warning about not-found stops.

Observed behavior

An INVALID_STOP_SEQUENCE error is thrown for many trips, which causes OTP to fully ignore the message, even though there is valid data.

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

otp-2.2.0-shaded.jar

Data sets in use (links to GTFS and OSM PBF files)

http://gtfs.ovapi.nl/nl/gtfs-nl.zip

Stripped version of netherlands-latest.osm.pbf https://download.geofabrik.de/europe/netherlands-latest.osm.pbf

Command line used to start OTP

java -Xmx8G -jar otp-2.2.0-shaded.jar --load .

Router config and graph build config JSON

Router config:

{
    "routingDefaults": {
        "numItineraries": 6,
        "walkSpeed": 2.0,
        "stairsReluctance": 4.0,
        "carDropoffTime": 240
    },
    "updaters": [
        {
            "type": "real-time-alerts",
            "frequencySec": 30,
            "url": "http://gtfs.ovapi.nl/nl/alerts.pb",
            "feedId": "NL"
        },
        {
            "type": "stop-time-updater",
            "frequencySec": 60,
            "url": "http://gtfs.ovapi.nl/nl/tripUpdates.pb",
            "feedId": "NL",
            "fuzzyTripMatching": true,
            "backwardsDelayPropagationType": "always"
        },
        {
            "type": "stop-time-updater",
            "frequencySec": 60,
            "url": "http://gtfs.ovapi.nl/nl/trainUpdates.pb",
            "feedId": "NL",
            "fuzzyTripMatching": true,
            "backwardsDelayPropagationType": "always"
        }
    ]
}

Steps to reproduce the problem

Import the specified GTFS and use the given router config. Errors like these will be thrown:

21:30:34.986 INFO (TimetableSnapshotSource.java:328) [feedId: NL] 542 of 1116 update messages were applied successfully (success rate: 48.57%)
21:30:34.986 ERROR (TimetableSnapshotSource.java:343) [feedId: NL] 499 failures of type INVALID_STOP_SEQUENCE: [NL:161741042, NL:161743340, NL:161746976, NL:161745645, NL:161743345, NL:161746975, NL:161741044, NL:161744311, NL:161745649, NL:161765005, NL:161743349, NL:161752050, NL:161753260, NL:161747706, NL:161757863, NL:161757621, NL:161753267, NL:161753258, NL:161741272, NL:161742242, NL:161741032, NL:161751190, NL:161746844, NL:161744302, NL:161742246, NL:161741035, NL:161743333, NL:161746847, NL:161745636, NL:161753254, NL:161743360, NL:161741061, NL:161745663, NL:161746872, NL:161744332, NL:161742272, NL:161745661, NL:161746992, NL:161741185, NL:161742277, NL:161743368, NL:161741068, NL:161747728, NL:161753283, NL:161753289, NL:161742260, NL:161744441, NL:161745652, NL:161741052, NL:161744322, NL:161745654, NL:161743354, NL:161741057, NL:161746869, NL:161747714, NL:161755211, NL:161753278, NL:161761807, NL:161760718, NL:161745201, NL:161741087, NL:161746892, NL:161745682, NL:161743384, NL:161748835, NL:161761800, NL:161745689, NL:161744357, NL:161745205, NL:161745688, NL:161742298, NL:161747626, NL:161758514, NL:161760708, NL:161745670, NL:161743371, NL:161742282, NL:161744343, NL:161743375, NL:161745678, NL:161745675, NL:161741079, NL:161755230, NL:161761827, NL:161744012, NL:161745222, NL:161744373, NL:161760734, NL:161745227, NL:161746799, NL:161745105, NL:161766036, NL:161760728, NL:161761814, NL:161760967, NL:161743391, NL:161744001, NL:161743397, NL:161748842, NL:162141403, NL:161758525, NL:161761847, NL:161762937, NL:161745240, NL:161762936, NL:161745003, NL:161748878, NL:161760998, NL:161745122, NL:161745127, NL:161748875, NL:161760990, NL:161748860, NL:161744383, NL:161761834, NL:161746205, NL:161745116, NL:161760983, NL:161757696, NL:161745265, NL:161745144, NL:161748417, NL:161748411, NL:161762952, NL:161749502, NL:161750617, NL:161741904, NL:161755189, NL:161748881, NL:161748882, NL:161761857, NL:161745251, NL:161760401, NL:161747678, NL:161762942, NL:161760403, NL:161749610, NL:161748883, NL:162158834, NL:161748884, NL:161745259, NL:161745138, NL:161760400, NL:161748885, NL:161760763, NL:161748886, NL:161757590, NL:161746108, NL:161750600, NL:162146610, NL:161746010, NL:161745042, NL:161747580, NL:161761886, NL:161745287, NL:161749522, NL:161761883, NL:161748434, NL:161760550, NL:161740713, NL:161740716, NL:161750634, NL:161741929, NL:161747693, NL:161746120, NL:161745030, NL:161747690, NL:161748426, NL:161745156, NL:161749511, NL:161746129, NL:161746005, NL:161741913, NL:161740702, NL:161740707, NL:161748451, NL:161747242, NL:161761308, NL:161746154, NL:161745065, NL:161746031, NL:161762639, NL:161746158, NL:161762637, NL:161760577, NL:161760698, NL:161747008, NL:161761789, NL:161762877, NL:161747002, NL:161760574, NL:161762633, NL:161762875, NL:161761302, NL:161746039, NL:161760697, NL:161761301, NL:161748215, NL:161762873, NL:161762870, NL:161741941, NL:161759100, NL:161741947, NL:161750657, NL:161750656, NL:161759103, NL:161748563, NL:161746022, NL:161752823, NL:161748447, NL:161762867, NL:161745056, NL:161749538, NL:161762866, NL:161760689, NL:161745176, NL:161747596, NL:161748202, NL:161760562, NL:161762864, NL:161760565, NL:161747235, NL:161761892, NL:161740722, NL:161742900, NL:161750643, NL:161742908, NL:161746055, NL:161745087, NL:161748471, NL:161746173, NL:161761205, NL:161747029, NL:161760115, NL:161748239, NL:161760599, NL:161746178, NL:161748113, NL:161748479, NL:162158568, NL:161739994, NL:161758030, NL:161760593, NL:161741966, NL:161742933, NL:161748220, NL:161747012, NL:161748585, NL:161746044, NL:161760108, NL:161745196, NL:161760105, NL:161762645, NL:161745077, NL:161762643, NL:161748586, NL:161748103, NL:161748467, NL:161761312, NL:161748226, NL:161760586, NL:161741951, NL:161742921, NL:161740984, NL:161759111, NL:161759114, NL:161742926, NL:161749583, NL:161748255, NL:161746198, NL:161762315, NL:161746078, NL:161764976, NL:161762313, NL:161760134, NL:161760376, NL:161762311, NL:161760136, NL:161748137, NL:161760378, NL:161760130, NL:161743922, NL:161742830, NL:161742951, NL:161746080, NL:161751302, NL:162146324, NL:161749452, NL:161748484, NL:161747033, NL:161762308, NL:161762309, NL:161760369, NL:161761218, NL:161746189, NL:161760128, NL:161746067, NL:161760123, NL:161748124, NL:161748247, NL:161760121, NL:161742941, NL:161741611, NL:162158551, NL:161743913, NL:161741615, NL:161741859, NL:161742828, NL:161748274, NL:161748396, NL:161746098, NL:161761006, NL:161762697, NL:161760157, NL:161741882, NL:161740674, NL:161743702, NL:161762692, NL:161761243, NL:161742852, NL:161741526, NL:161742858, NL:161742857, NL:161749597, NL:161746088, NL:161748261, NL:161749471, NL:161761237, NL:161763899, NL:161760145, NL:161760387, NL:161762688, NL:161762685, NL:161748148, NL:161749479, NL:161741871, NL:161740664, NL:161761230, NL:161760383, NL:161743933, NL:161760143, NL:161760384, NL:161741875, NL:161741515, NL:161742848, NL:161760381, NL:161740669, NL:161750108, NL:161751317, NL:161751438, NL:161748173, NL:162137846, NL:161740690, NL:161761266, NL:161742870, NL:161740332, NL:161761026, NL:161740694, NL:161740331, NL:161740697, NL:161760174, NL:161761022, NL:161760170, NL:161741548, NL:161761260, NL:161743968, NL:161748180, NL:161751345, NL:161756900, NL:161748281, NL:161748283, NL:161748163, NL:162136746, NL:161740682, NL:161743950, NL:161761013, NL:161748169, NL:161740442, NL:161761257, NL:161740441, NL:161741893, NL:161740685, NL:161743710, NL:161760164, NL:161761250, NL:161760160, NL:161743957, NL:161741538, NL:161748290, NL:161751364, NL:161748194, NL:161753307, NL:161759092, NL:161760078, NL:161741561, NL:161740233, NL:161741203, NL:161759084, NL:161743623, NL:161742897, NL:161759088, NL:161741209, NL:161753301, NL:161751233, NL:161748185, NL:161743977, NL:161761034, NL:161759079, NL:161748191, NL:161745703, NL:161743647, NL:161741103, NL:161746911, NL:161760098, NL:161744613, NL:161763482, NL:161741229, NL:161743648, NL:161741109, NL:161745709, NL:161753322, NL:161753201, NL:161753313, NL:161748089, NL:161751253, NL:161740361, NL:161761299, NL:161763477, NL:161743992, NL:161763478, NL:161741574, NL:161763475, NL:161759096, NL:161746901, NL:161759095, NL:161760087, NL:161743634, NL:161742669, NL:161759099, NL:161759098, NL:161761293, NL:161761290, NL:161751256, NL:161755888, NL:161758918, NL:161751283, NL:161741120, NL:161742695, NL:161742210, NL:161741000, NL:161741003, NL:161743668, NL:161741488, NL:161741007, NL:161746818, NL:161746938, NL:161753224, NL:161751277, NL:161753215, NL:161758901, NL:161751394, NL:161741591, NL:161742320, NL:161746922, NL:161742326, NL:161742689, NL:161741239, NL:161746927, NL:161743659, NL:161761191, NL:161753249, NL:161752033, NL:161741263, NL:161741141, NL:161743323, NL:161741022, NL:161741025, NL:161740299, NL:161743685, NL:161743327, NL:161744417, NL:161745626, NL:161746957, NL:162139711, NL:161744415, NL:161756873, NL:161753238, NL:161751176, NL:162140826, NL:161742343, NL:161744402, NL:161742345, NL:161741013, NL:161742226, NL:161741499, NL:162135254, NL:161741018, NL:161743678, NL:161746949]

I have already contacted our public transport authority and spoke with a contact. The "problem" is, is that our train-trips overspecifies any updates (even for stops which are not in the "stop-times" files)

Let's say we have a train from Point A to point E. During this the train passed at point B, C and D. The train stops at point C, but not at point B and D. Our GTFS-RT feed will still specify point C and D as "skipped" or "ignore" them. This is probably the cause of the above errors.

Now in the GTFS-RT specification it is specified the stops should be in order, however, the order is correct, there's just "Too many". It would be nice if OTP could ignore these errors and still update the graph as now over 50% of the updates are ignored.

Example trip update with error:

   {
      "id": "161741042",
      "tripUpdate": {
        "trip": {
          "tripId": "161741042",
          "startTime": "21:53:00",
          "startDate": "20230112",
          "scheduleRelationship": "SCHEDULED",
          "routeId": "17522",
          "directionId": 0
        },
        "stopTimeUpdate": [
          {
            "departure": {
              "delay": 0,
              "time": "1673556780"
            },
            "stopId": "2422005",
            "scheduleRelationship": "SCHEDULED"
          },
          {
            "stopId": "2423255"
          },
          {
            "stopId": "2423251",
            "scheduleRelationship": "SKIPPED"
          },
          {
            "arrival": {
              "delay": 0,
              "time": "1673557680"
            },
            "departure": {
              "delay": 0,
              "time": "1673557800"
            },
            "stopId": "2422149",
            "scheduleRelationship": "SCHEDULED"
          },
          {
            "stopId": "2423329"
          },
          {
            "arrival": {
              "delay": 0,
              "time": "1673559360"
            },
            "stopId": "2427767",
            "scheduleRelationship": "SCHEDULED"
          }
        ]
      }
    }

Looking up these stops in stop_times.txt gives:

161741042,1,2422005,,21:53:00,21:53:00,0,1,1,1,0
161741042,4,2422149,,22:08:00,22:10:00,0,0,1,17036,0
161741042,6,2427767,,22:36:00,22:36:00,1,0,1,69921,0

So the specified stop of "2423251" in the GTFS-RT is not in the stop_times file as the train won't actually stop there, but simply passes it.

Kind regards, Tristan

See attached files for some more data.

OTP Error.txt TrainUpdatesErrors.csv TrainUpdates.txt

[leonardehrenfried]

Hi and welcome to OTP.

I feel that this is definitely a data error and should be fixed in the GTFS-RT feed. Why does the feed contain stops that the train does no stop at? SKIPPED means that there was a plan to stop at this stop but for some reason that won't happen anymore. How is OTP supposed to tell the difference between a genuinely skipped stop and your example?

Whilst the preferred option is to fix the RT input, dealing with messy feeds is just a fact of life that we as the OTP developer often have to deal with.

We decided a while ago that we are ok with fixing the data in OTP itself as long as we make it explicit, visible and no longer automagically, perhaps through some kind of opt-in clean-up pipeline.

If you're willing to help out with this, we would love you to join our dev meetings twice a week or the Gitter chat.

In any case, even if you can't work on it, you can join as it would be good to have someone from the Dutch OV project talk to.

[skinkie]

@leonardehrenfried this is not a data error. The intermediate stops are available in the realtime data, but are not part of the regular GTFS feed, as they are not passenger data. The case is here an intercity train that passes along stops. This has been design already since 2013 as part of the original OTP realtime implementation.

From my point of view OTP should not judge the data other than guard it time is increasing, and just apply the data from the stop times it knows about. The original implementation in OTP1 actually replaced the entire journey pattern with the new sequence which gives the same effect.

[leonardehrenfried]

Did it do that for trips of schedule relationship SCHEDULED?

The code that produces this error was actually written by Jordan Verwer back in the day. We tried to preserve the original behaviour when refactoring all of this but maybe this case didn't have a test. I don't think it was changed on purpose. One thing to consider: the statistics about whether the update was successful are a recent addition. Is it possible that this never worked and you just didn't notice?

In any case, we are very happy to talk about all of this and would love to have OV contribute to OTP2.

[skinkie]

Did it do that for trips of schedule relationship SCHEDULED?

Yes. At the time we basically defined the entire OTP Realtime interface to allow deviations to work natively.

The code that produces this error was actually written by Jordan Verwer back in the day. We tried to preserve the original behaviour when refactoring all of this but maybe this case didn't have a test. I don't think it was changed on purpose. One thing to consider: the statistics about whether the update was successful are a recent addition. Is it possible that this never worked and you just didn't notice?

Lets say I don't know if it ever worked with OTP2. It certainly did with OTP1. As it was part of the funding to have trip deviations, and a testset was created. https://github.com/plannerstack/testset You will recognise the person that made the last commit :-)

In any case, we are very happy to talk about all of this and would love to have OV contribute to OTP2.

I'll add @sven4all in this discussion too.

To add some rationale why the times are added in the first place. Some applications are drawing vehicle positions on a map by interpolating between stations (since not all trains in The Netherlands have locations). Having the intermediate times available allows linear interpolation at a better granularity. In addition you can do cool things with network analysis. So yes, it is a use case outside of the realm of "travel information" it is certainly not "inconsistent" with the generic GTFS feed, if only these stop_times would be updated.

[Arilith]

Hi and welcome to OTP.

I feel that this is definitely a data error and should be fixed in the GTFS-RT feed. Why does the feed contain stops that the train does no stop at? SKIPPED means that there was a plan to stop at this stop but for some reason that won't happen anymore. How is OTP supposed to tell the difference between a genuinely skipped stop and your example?

Whilst the preferred option is to fix the RT input, dealing with messy feeds is just a fact of life that we as the OTP developer often have to deal with.

We decided a while ago that we are ok with fixing the data in OTP itself as long as we make it explicit, visible and no longer automagically, perhaps through some kind of opt-in clean-up pipeline.

If you're willing to help out with this, we would love you to join our dev meetings twice a week or the Gitter chat.

In any case, even if you can't work on it, you can join as it would be good to have someone from the Dutch OV project talk to.

Hi Leonard,

Thanks for the openess and quick response! I would definitely like to join one of those meetings, however, as you have probably noticed, @skinkie is much more well-versed in the Dutch public transport data world, so I'm not sure if I could add anything that he hasn't mentioned yet.

Anyhow, I'll see if I can join some day so that you could ask some more questions!

[leonardehrenfried]

This a pure speculation but you could try the following: In https://github.com/opentripplanner/OpenTripPlanner/pull/4424 I introduced these typed errors to replace the flood of logs.

You could try and find out if it was this PR that broke your use case. This might give you an indication how to revert it.

[Arilith]

@leonardehrenfried I just tried reverting to 2.1.0 (according to github didn't have the commit you mentioned), and although it doesn't neatly specify the "success percentage", I still get flooded with quite a big amount of errors.

It's difficult to say if it's less / more, but seeing that the OTP Webapp doesn't specify "too late" or "on time" for any trains, I feel like it did not work as expected. So I guess there's something more behind it next to that commit.

[Arilith]

After some further research, it seems like (some) of the errors come from the following situation:

Say I've got Stop A which has tracks 1 (which is subdivided in 1b and 1a). In my scheduled data (stop_times) this trip is designated to start at track 1. However, the GTFS-RT stream gives the more specific track that is now known, Track 1a. This would result in OTP immidiately not being able to find the first stop, as it now has a different ID than the original planned stop. This makes OTP throw an STOP_SEQUENCE_ERROR.

The problem is is that the match at https://github.com/opentripplanner/OpenTripPlanner/blob/edadd0954fd73fa71cecdf9222f4d8ddfdf7e5c2/src/main/java/org/opentripplanner/model/Timetable.java#L227

is not found. This is because the matching only looks at the stop sequence or stop_ids, however, without a stop sequence, in the situation described above, of course the stop_id matching at

https://github.com/opentripplanner/OpenTripPlanner/blob/edadd0954fd73fa71cecdf9222f4d8ddfdf7e5c2/src/main/java/org/opentripplanner/model/Timetable.java#L223

fails.

However, this "updating" of a new more specific stop as first stop is within the GTFS-RT spec. See: https://support.google.com/transitpartners/answer/10106587?hl=en#zippy=%2Cupdate-the-platform

As long as the new stop (platform) is under the same "parentstation", it is still valid. It seems like OTP does not handle this case. This is most likely not the only issue that creates the specified error, but it definitely one of them.

EDIT: What in case of a serious disruption? This could make it so that some stops will not be passed anymore and maybe some new stops are added at another place, this would result in both the stop_sequence and stop_ids not lining up anymore. Isn't it better/easier to just overwrite the whole journey pattern with the updated data instead of matching each stop 1 by one?

[skinkie]

I think the way how tripUpdates are applied should be configurable per feed. Andrew and Jorden agreed before we need to establish some kind of quality statement per feed like "this feed is complete and allows trips to be replaced" versus "this feed only makes next stops delays available which should then be propagated for all stops to make them coherent again without time travel".

[Arilith]

After doing some more digging, it seems like the "Replacement" "ScheduleRelationship" case comes very close, as it just cancels the old trip and dumps all new stops into the graph. However, it seems like "REPLACEMENT" is depricated in the GTFS spec?

[skinkie]

The deprecation is a political move that forces a (complex) specification change. https://github.com/google/transit/issues/113

[leonardehrenfried]

Even though it's deprecated, the REPLACEMENT code is still in OTP from the original Dutch implementation, persumably because the spec changed that @skinkie refers to never materialized. Is this correct?

It's worth trying if it still works.

[Arilith]

Even though it's deprecated, the REPLACEMENT code is still in OTP from the original Dutch implementation, persumably because the spec changed that @skinkie refers to never materialized. Is this correct?

It's worth trying if it still works.

Hi Loenard,

I tried customizing our GTFS-RT feed to make all trips "MODIFIED" instead of "SCHEDULED", however, although the import errors were much lower, it seemed like the OTP graph was actually removing most of the trips. As soon as OTP processed the pb file, the routing engine wasn't able to find any train trips anymore. Seems like something went wrong there, but can't put my finger on what.

Anyhow, for my personal implementation, I have now just created my own custom Dutch GTFS-RT feed for trains which works almost perfectly with 95% import success. I noticed the other 5 percent is all international trains with a different stop sequence, so that is still something that would be worth figuring out. Anyhow, I can confirm that the problem with the official Dutch GTFS-RT feed is both the lack of sequence numbers and the many "unofficial" (skipped) stops. I've removed these from my own feed and as stated before, with 95% import success. I guess we have some digging to do on our side as well to make the official feed better!

[leonardehrenfried]

Good to hear that you managed to the errors down to a low number.

BTW, you're welcome to ask even very detailed questions in our Gitter room: https://gitter.im/opentripplanner/OpenTripPlanner

[skinkie]

@koch-t ^^^

[slvlirnoff]

For the remaining errors, could it be due to stops that aren't part of the original feed (with the same id) and not in the graph as a result? That would prevent the update from being applied.

[Arilith]

For the remaining errors, could it be due to stops that aren't part of the original feed (with the same id) and not in the graph as a result? That would prevent the update from being applied.

The biggest problem (for now) seems to be the following: (this applies mostly for our International trains) In the GTFS files, the stopsequences for international trains go like: "1, 3, 10, 17, 23, 36". This would mean the train passes about 36 stops during its journey. However, the stops that are put into our national "InfoPlus" system from Dutch railways, only specifies about 20 stops (it doesn't specify international "skipped" / "passed" stops). This means the stop sequence generated by my GTFS-RT constructor and the stop sequence in the planned GTFS don't line up any more. This makes the importing immidiately fail, as we have the skipped stops in the feed, which OTP doesn't like, and the sequences don't line up any more. In this case, it would just be better to overwrite the whole journey pattern instead of matching each stop one by one.

[skinkie]

For a high quality feed. Is there ever a reason not to overwrite everything?

[leonardehrenfried]

@Arilith BTW, you don't need the sequence number. You can also just use the stop id. (Of course if you have a circular route this will not work, but these are pretty rare, particularly for trains.)

For a high quality feed. Is there ever a reason not to overwrite everything?

If your input data is good, I don't see a reason why you should not.

[skinkie]

For a high quality feed. Is there ever a reason not to overwrite everything?

If your input data is good, I don't see a reason why you should not.

Is it an idea to have a configuration option to set the default behavior?

[leonardehrenfried]

I think it is.

We decided a while ago that OTP is now a sort of enterprise software and we don't shy away from having lots of configuration options. We also have automatic generation of the documentation for these config options. We prefer that over everybody having their own fork and implementing their custom logic downstream.

You could also test/fix the REPLACEMENT schedule relationship again which does what you want.

[hannesj]

Also the way to define platform changes, such as from 1 to 1a, was recently adopted in the official GTFS-RT protobuf schema in https://github.com/google/transit/pull/219. It is not currently implemented in OTP, but should be quite straight forward for you to implement.

[Arilith]

@Arilith BTW, you don't need the sequence number. You can also just use the stop id. (Of course if you have a circular route this will not work, but these are pretty rare, particularly for trains.)

For a high quality feed. Is there ever a reason not to overwrite everything?

If your input data is good, I don't see a reason why you should not.

I added the sequence number as the current way of dealing with platform changes does not work with only stop ids. For example, when we have a train that is planned from Amsterdam Centraal platform 4 and is later updated to depart from platform 4b after more information has become available, that trip would instantly fail to be inserted, as the stop ids don't match anymore (I debugged OTP step for step and found this out, not sure if that's correct behaviour). This is the same problems for stops that are on the route and have changed platforms.

This creates a massive issue, as platform changes are quite common. I've only re-created our trainUpdates.pb until now, and I feel like the 10% of errors in the tripUpdates.pb from other vehicles is mostly due to the same problem described above.

I could try removing the stop sequence for international trains, but it also sometimes happens (very rarely) with local trains, that the planned sequence doesn't line up with the actual sequence. (Think of a train that was planned to go through station X, but there was a switch issue, which made it go through station Y and Z which were not even in the original planning).

Another problem @skinkie and I actively discussed is how to deal with "TVV" (Train Replacing Transport). Currently, if I have a trip that is not in the pre-defined GTFS definition, but my realtime data has it, it can not be inserted into the OTP graph as the tripId won't be found. (And/or serviceId) (As even the handleAddedTrip method checks for these properties)

This is quite a big problem for scenarios where a big disruption happens, and non-planned busses/replacement transport is actived. What is your guys' view on this? Is there a "to the book" solution for this?

About changing everything to "Modified", this would (I think) only solve the stop sequence errors for the International train problem I described earlier (though, as described, there's no clear "I'm wrong" sign in our dataset). But for all new trips, this also won't work due to the problems with missing trip information.

It would be nice to have a way of adding a whole new trip (with headsign, serviceId, etc) with a linked "originalTripId" so that it could still be referenced to the original (now cancelled trip).

Now I'm very new to GTFS-RT, so maybe this is already in the works, but this is what I experienced over the last week. IMO, GTFS(RT) is quite limited, especially in comparison to the (realtime)data we work with nationally.

[leonardehrenfried]

For adding completely new route you will be interested in this PR: https://github.com/opentripplanner/OpenTripPlanner/pull/4667

I'm using it for dynamically adding carpool "routes" but technically that is the same as an emergency rail replacement service.

It adds the ability through a protobuf extension but if it's more than a single organization using it, it would be worth getting it into the official spec. Also @skinkie has lots of experience doing just that.

[Arilith]

Oh that PR looks good! Thanks for the heads up. As soon as it is accepted, I'll definitely build that version and try it out.

[skinkie]

Also the way to define platform changes, such as from 1 to 1a, was recently adopted in the official GTFS-RT protobuf schema in google/transit#219. It is not currently implemented in OTP, but should be quite straight forward for you to implement.

Experimental feature. Would not be required if data is 'just' replaced.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[skinkie]

@Arilith did you have a patch?

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[skinkie]

Keep open.

[Arilith]

Keep open.

@Arilith did you have a patch?

I have not patched OTP directly (yet). I have been looking into #5230, to fix the current issue of there not being an "official" way to have platform changes under the same station using the SCHEDULED relationship, even though according to the spec this should be possible. However, this seems to be a little more complex than what I have had the time for to put into developing, so that'll take some time.

Currently I'm using a modified GTFS-RT stream that makes use of the (sadly) deprecated MODIFIED schedulerelationship. For "ritbeeldmatchende (replacement / extended)" trains I simply use the CANCEL / ADDED combination. This generally results in a fairly stable way to make OTP consume our Dutch InfoPlus system, with about 99-100% import success, except for very specific cases.

I can always try to take a look where exactly our official (openOV/OVAPI) GTFS-RT streams go wrong and try to patch that out, but it seems like that would require a substantial change in the way OTP deals with the SCHEDULED trips, as that currently does not allow any kind of stop modification (as far as I've seen). I'm having a discussion with Leonard today, so if I get any more information about this, I'll update it here.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[skinkie]

Keep open.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days

[skinkie]

Closure is stupid.

[leonardehrenfried]

With that kind of language you're not helping your cause.

Resources are limited and without developers being funded to look into the code, there is no point in pretending that it will be magically fixed.

[skinkie]

@leonardehrenfried there is no inteligence in github-actions, it cannot be offended. Lets not forget this used to work in OTP1. Closure does not make issues disappear. That is a really stupid management paradigm.

[leonardehrenfried]

The good news is that you can keep using this non-standard feature in OTP1 forever.