Fix issue where stop points are sometimes added twice to index #5552
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
When netex data contains duplicate JourneyPatterns the scheduledStopPointsIndex will get duplicates of all the stop points for those JourneyPatterns during graph build. When the graph is loaded this will result in strange IndexOutOfBoundsExceptions in the TransferMapper.
Issue
NetexMapper uses a
Multimap
for the scheduledStopPointsIndex. But the semantics of a multimap is that putting to a key that already exists will extend any existing data that has already been added. This is not really the behaviour we want in this case.This PR fixes this issue by replacing the
Multimap
with aMap<List>
. This way we will replace the current values when calling putAll().I suppose that duplicate JourneyPatterns could cause all kinds of other problems, so to solve the underlying issue we should really add some validation of the netex data for this. But I think these changes are worthwhile anyway, since it makes the code less brittle.
Unit tests
There aren't any tests for this code that I could find, and writing them feels a bit out of scope for this PR.
Documentation
Nothing needed.
Bumping the serialization version id
Nope