[ue71603]

This PR is the first major overhaul of the DRT part. It is based on the discussions on Basecamp: https://3.basecamp.com/3256016/buckets/2570434/messages/9445596013
Documents here: https://3.basecamp.com/3256016/buckets/2570434/vaults/9446713460

Some open questions will be deferred to a later PR or several as to not overload this one.

As this is a 2.1-wip PR: changes to existing functionality should be avoided.

Open points:

• README: Remove German parts

• README: Improve readability

• README Descriptions in examples should describe, what happens

• README Copy better examples for the different types

• Positiv list for possible transfers to regular public transport (perhaps directly in the flexible area) (or in ServiceCompetitiveCondition

• Include MOTIS input: Input from Felix Gründling for more parameters: https://felixguendling.github.io/transit-qa/
  - This would also allow for perpiece linear functions in the form of a table
  - from 0 mim taxi: 35 penalty points per taxi minute
  - from 1 min taxi: 12 penalty points per taxi minute
  - So a penalty factor for DRTis missing
  - DistanceFromClassical seems problematic, as an existing line may not operate (at this hour).
  - There may be other dominance rules for DRT vs DRT (first -mile/last-mile DRT vs direct DRt)

      apply.
   - He and Motis are interested in a discussion.
  

DONE:

• Temporal distance needs better definition e.g. mean between departure time and arrival time.
• Make a correct example for deep links
• Making sure that ServiceBookingArrangements can be used in Line and ServiceJourney
• Making clear that bookingArrangements on the Line are valid for the whole Line. Changes can occur in the ServiceJourney. If nothing is there, then the one from the Line or the MobilityService is used.
• Changing parameter names for deep link and update them
• Drive -> Travel
• Fixing BookingDeepURL
• fixed problem with SupportedSteps
• Checking id in example
• Minimum/MaximumBooking Duration in relation to departure time
• Modeling some stuff that in the flexible version of HRDF: Modeling some stuff from new flexible HRDF.
  - need for reservation
  - no bicyles allowed
  - additional fare necessary
  - *R * U 5 additional time for transfer at stop
  - *R *DT 14 14 no competition to classical line
  - *SS *FAT 00 30 Minimal-maximal drive duration.
• Usage of RoutingContraintInFrameGroup. Optionally ok, Redudant, because RoutingContraintZones can be defined in the Line and the ServiceJourneyPattern. If it is done a good example is necessary.
• additional example https://www.skyss.no/globalassets/reise/rutetabellar/bat-og-ferje/b%C3%A5t-og-ferje/[293](https://www.skyss.no/globalassets/reise/rutetabellar/bat-og-ferje/b%C3%A5t-og-ferje/293.pdf).pdf
• if necessary to split example test how.
• define what needs to be done for Transmodel
• google/transit@4ba262f make sur this is integrated
• Making sure we have what is needed for the booking step mainly EUDIT/OSDM/TOMP
• Process information needs to be defined somewhere
• Do the boat example from ENTUR
• Line interactions we need probably the simple mechanism. Wilfried pointed out that the provider usually does not have the detailed information. If not lines are mentioned, it is valid for all lines. Wilfried: Adding "RoutingConstraintInFrameGroup" is like shooting sparrows with cannons. It adds huge complexity to the model where we originally only wanted to state "do not compete with regular PT operating within +-15 minutes"
• explanatory document needed for each example (md)
• Making sure, we have have everything we need for GTFS Flex transform (see pr below)
• Add new examples from the Swiss profile (@duexw )
• Use the parameters of NL
• We should also allow the ServiceBookingArrangement in the existing bookingArrangements_RelStructure and bookingArrangementsInFrame_RelStructure. Currently, we export the DRTs as FlexibleLines also if they are taxi-like. It would break existing implementations if we had to move them to MobilityServiceFrame just in order to use ServiceBookingArrangement. Maybe it is also possible to add the new elements to the regular BookingArrangement
• Derive concrete examples from basecamp lists
• Validate the examples
• Add a structure for parametrised link
• updated to v2.1-wip
• add a hail and ride example
• Enforce a parametrised URI in the BookingUrl for BookingArrangement
• Remove FlexibleLine, FlexibleService and integrate them in the normal stuff in the examples
• Make sure that the LineType is aligned with the other discussions. Tu-Thos list is better, so update the definitions
• When DRT ist modeled as a regular line with a ServiceJourneyPattern, then the new ServiceBookingArrangements should be in the Line element. An extension of bookingArrangementsRelStructure is needed. Having it additionnaly in MobilityServiceFrame is also possible, But it should not be only there. This max cause conflicts in the relations where stuff is. things would need to be moved from part 5 to part 3.

[ue71603]

redoing #958
not working yet and not adapted examples

TODO:

• fix problem with substitutionGroup
• change examples
• reduce to the max

[ue71603]

We can now have the discussion

• if this fixes everything: @duexw @klement-MENTZ
• If this fits in the main structure @nick-knowles @Aurige

[felixguendling]

This lacks a clear formula and definitions.

In its current state, every journey planner and booking system would interpret those parameters differently as they like.

Please do not standardize it in this state.