Added Transmodel TRIP REQUEST.Flexibilitywindow

[ue71603]

No description provided.

[normanoffel]

What is the use case for this field? When should it be filled and what are its implications / what are the expectations from the enquirers?

[ue71603]

Norman: Usually departure time is a hard use case. Expected result is the problem: How important is the adherence to the defined time.
Malte: We only have DepartureArrivalTime and TimeAllowance
Matthias: NumberOfResultsBefore ...
Prefered interval (choice): "DepartureArrivalTimeRange"

siri:StopPointRef<...>
20:123Z

siri:StopPointRef<...>

...
..

Norman: What this would mean. Within this time range I give you every trip and ignore the NumberOfResult?
Tim: In airline planers one sees even date changes (+/-3 days)
Malte: We would also calculate everything. Advise needed on the usage.
Matthias: ERROR Code

==> Norman will discuss it.

[AndreasAtSBB]

added new TRIP REQUEST.FlexibilityWindow with an example and also new matching error definitions.

[trurlurl]

1. PlaceContext is also used in StopEventRequest which already contains the element TimeWindow. Isn't that too redundant / confusing?

2. As for the logic how to integrate DepArrTimeRange and NumberOfResults* - I suppose that they are treated to indicate what the results should cover at least (i.e., each one is able to extend the number of results).

[ue71603]

Wit the comment from André concerning the TimeWindow in StopEventRequest, I guess it is better to remodel the FlexibilityWindow here.

[sgrossberndt]

On it

[sgrossberndt]

Two improvements:

• Improve wording and fix typo in documentation
• Renamed problem code to TRIP_TIMEWINDOWTOOLARGE (should not contain "ERROR", will add a pull request for TRIP_DATETIMEERROR shortly) and since the problem is about the time window let's use that in the name of the problem as well.