in MEP, a search destination is not truly valid if the expected mode was not used. this is trivial to confirm for trip modes that are unimodal, such as "walk" or "drive". however, when more than one mode was available, such as ["walk", "drive"] for a trip with a trip mode of "drive", we would not expect to treat destinations walked to as drive-mode destinations.
this can be modeled with a new DestinationPredicate variant but would require sharing access to the mode list / MultimodalStateMapping to both the isochrone and opportunity output plugin, likely from a single location such as the bambam output plugin config:
ModeUsed {
/// travel mode name to test for a nonzero distance traveled. confirmed by checking the
/// mode_distance stored in the (multimodal) state vector is not 0.0.
mode: String
}
in MEP, a search destination is not truly valid if the expected mode was not used. this is trivial to confirm for trip modes that are unimodal, such as "walk" or "drive". however, when more than one mode was available, such as ["walk", "drive"] for a trip with a trip mode of "drive", we would not expect to treat destinations walked to as drive-mode destinations.
this can be modeled with a new
DestinationPredicatevariant but would require sharing access to the mode list / MultimodalStateMapping to both the isochrone and opportunity output plugin, likely from a single location such as the bambam output plugin config: