Remove service date from cache key of SiriTripPatternCache

[leonardehrenfried]

Summary

In today's real time meeting we talked about the indexing of trip patterns in the SiriTripPatternCache and we came to the following conclusion:

• we don't really know why the cache key contains the service date
• even though we are uneasy about it, @vpaturet agreed to just try it out on Entur's staging system to find out if there are negative consequences

Issue

#4002

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.24%. Comparing base (698df74) to head (c4d5fb9).
Report is 321 commits behind head on dev-2.x.

Additional details and impacted files

@@            Coverage Diff             @@
##             dev-2.x    #6069   +/-   ##
==========================================
  Coverage      70.24%   70.24%           
- Complexity     18369    18370    +1     
==========================================
  Files           2087     2087           
  Lines          77381    77370   -11     
  Branches        7839     7837    -2     
==========================================
- Hits           54358    54351    -7     
+ Misses         20249    20245    -4     
  Partials        2774     2774           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[leonardehrenfried]

After a long break I'm re-opening this topic. @vpaturet has said that Entur might have the capacity to tests this.

[habrahamsson-skanetrafiken]

We did decide to remove the date, and I think that is a good thing to do since it's hard to figure out a reason for having the date in the key.

If we wanted to improve this further, I think what would make the most sense is having the key for the TripPatterns be based on the contents of the trip patterns like:

key = new TripPatternKey(
  trip.getRoute(),
  trip.getMode(),
  trip.getNetexSubMode()
  stopPattern
  originalTripPattern
)

That way we would be sure that we wouldn't reuse an incorrect TripPattern in (very unusual) case where two unrelated trips with different routes were modified to use the same StopPattern.

What do you think about that?

[leonardehrenfried]

We could do that but then we should do it both for GTFS and SIRI, isn't it?

[habrahamsson-skanetrafiken]

Yeah I think we should do the same for GTFS in that case. If you want to do this smaller change first in order to unify the caches I think that's a good move in the right direction.

[miklcct]

That way we would be sure that we wouldn't reuse an incorrect TripPattern in (very unusual) case where two unrelated trips with different routes were modified to use the same StopPattern.

This case is not unusual. It is fairly common that two bus routes share the same stop pattern, especially if one is a day route and the other is the corresponding night route.

For example, in London, the 98 and the N98 short working services share the same stop pattern, as the full length of N98 is just the 98 extended further to cover a section where the tube is not running at night.

In Hong Kong, there are 3 minibus routes (52A / 54A / 56A) which are exactly the same, because they are short working services of 3 different routes running in a common corridor, and are operationally belong to the 3 different routes instead.

[leonardehrenfried]

We talked about this in today's meeting and we decided that we will keep the scope of the PR small so we will leave Henrik's suggestion for a follow up.

[vpaturet]

Briefly tested with Norway real-time feeds. No visible difference.