Include empty rail stops in transfers

[t2gran]

Summary

Include regular transfers with from/to "empty" rail stops (platforms) when using the OTPFeature#ConsiderPatternsForDirectTransfers. It is common for stops to be assign at realtime for rail, if so turning OTPFeature#IncludeEmptyRailStopsInTransfers on will help to avoid dropping transfers witch is needed when the realtime is applied. We assume the set of truly unused rail stops is limited; Hence the performance overhead of adding them all should be limited.

Note! This is only applied to stops witch has vehicleType Rail. If the input feeds does not have a mode set for the stop
this fix will not work! Consider turning off ConsiderPatternsForDirectTransfers instead or fix the feeds.

Issue

This will help for issue #5461, but is not the ideal fix. The real fix is to generate transfers (both ways) for stops used in realtime - especially stops going from zero patterns to having at least one.

Unit tests

This is hard to test, no test exist for the PatternConsideringNearbyStopFinder as is. I have manually tested the case in issue #5461 - and this fix does work for it.

Documentation

✅ The new feature flag is documented.

Changelog

✅ Minor feature

Bumping the serialization version id

Only a new feature flag is added to the model, so there is no need to bump the ser-ver-id.

[codecov]

Codecov Report

Attention: Patch coverage is 72.72727% with 6 lines in your changes missing coverage. Please review.

Project coverage is 69.70%. Comparing base (a9a23fd) to head (b3c63f9).
Report is 161 commits behind head on dev-2.x.

Files with missing lines	Patch %	Lines
...earbystops/PatternConsideringNearbyStopFinder.java	70.00%	2 Missing and 1 partial ⚠️
...nner/apis/transmodel/model/stop/StopPlaceType.java	0.00%	1 Missing ⚠️
...opentripplanner/netex/mapping/FlexStopsMapper.java	0.00%	0 Missing and 1 partial ⚠️
...pentripplanner/transit/model/site/RegularStop.java	75.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #6208      +/-   ##
=============================================
- Coverage      69.75%   69.70%   -0.05%     
- Complexity     17652    17683      +31     
=============================================
  Files           2006     2008       +2     
  Lines          75525    75812     +287     
  Branches        7731     7761      +30     
=============================================
+ Hits           52679    52847     +168     
- Misses         20134    20251     +117     
- Partials        2712     2714       +2     

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

[miklcct]

Note! This is only applied to stops witch has vehicleType Rail. If the input feeds does not have a mode set for the stop
this fix will not work!

I don't think setting this is possible for GTFS feeds. Is it possible to make this work? My deployment returns vehicleMode = null for unused stops.

[t2gran]

@miklcct For the record, it is possible to set vehicle_type and OTP do support it trough the Google Extensions: https://developers.google.com/transit/gtfs/reference.

This PR is a temporary fix, and we are removing this feature when the underlying bug is fixed.

[miklcct]

@miklcct For the record, it is possible to set vehicle_type and OTP do support it trough the Google Extensions: https://developers.google.com/transit/gtfs/reference.

This PR is a temporary fix, and we are removing this feature when the underlying bug is fixed.

I have set the vehicle_type in our GTFS and this pull request behaves as expected. Our journey planner is now returning the expected journeys.

[leonardehrenfried]

A couple of typos but generally this looks good.

Look forward to the more general solution.

[optionsome]

What is this used for? Vehicle type information is not required, I don't know how much we should rely on that information in general.

[optionsome]

I just noticed this is in the netex mapping, perhaps it's required there and this is fine.

[t2gran]

I have no clue, I just renamed the very confusing method name - as you noticed, it is used for both GTFS and NeTEx so having GTFS as part of the name is wrong.

[leonardehrenfried]

It's used to show a stop's mode in the API. However, since it's not required we also deduce it from the patterns that visit the stop:

OpenTripPlanner/application/src/main/java/org/opentripplanner/transit/service/DefaultTransitService.java

Lines 730 to 739 in 09e2de7

	/**
	* For each pattern visiting this {@link StopLocation} return its {@link TransitMode}
	*/
	private Stream<TransitMode> getPatternModesOfStop(StopLocation stop) {
	if (stop.getGtfsVehicleType() != null) {
	return Stream.of(stop.getGtfsVehicleType());
	} else {
	return getPatternsForStop(stop).stream().map(TripPattern::getMode);
	}
	}

[leonardehrenfried]

Can you update the generated documentation?

[miklcct]

Unfortunately, as expected, this won't work for a real time rail replacement bus where it calls at stops normally unused but reserved for them, because they are not a rail stop.

[miklcct]

I have just deployed a version without the rail check and the number of transfers has gone from 31.7k to 33.0k, so it is a minor difference in GB, and it has fixed the issue of routing people to a rail replacement bus from a dedicated stop.