Adding different types of restrictions between Services especially for DRT

[ue71603]

Updating DRT
Discussion here: https://3.basecamp.com/3256016/buckets/2570434/messages/9445596013
Documents here: https://3.basecamp.com/3256016/buckets/2570434/vaults/9446713460

Open points:

• Derive concrete examples from basecamp lists
• Validate the examples
• Making sure we have what is needed for the booking step mainly EUDIT/OSDM/TOMP
• Making sure, we have have everything we need for GTFS Flex transform
• Process informationed needs to be defined somewhere
• Remove FlexibleLine, FlexibleService and integrate them in the normal stuff
• Make sure that the LineType is aligned with the other discussions.
• Mixed lines from ENTUR need an example.
• 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)
• 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
• 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
  Soa penalty factor forDRTis 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)
  Temporal distance needs better definition e.g. mean between departure time and arrival time. Other functions might apply.
  He an Moriz are interested in a discusion.
• 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.
• When DRT istmodeled as a regular line with a ServiceJourneyPattern, then the new ServiceBookingArragements should be in the Line element. An extension of bookingArrangementsRelStructure is needed. Having it additionaly 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.
• Usage of RoutingContraintInFrameGroup. Optionally ok, Redudant, because RoutingContraintZones can be defined in hte Line and the ServiceJourneyPattern. If it is done a good example is necessary.

[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

[duexw]

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".

[ue71603]

but it works with cannons... Ok. I had this first but the restriction group works. You propose we do a simple element with a xs:duration then. I can live with that.

[skinkie]

I don't know if I want to switch to something simple, if we can facilitate all variants with a "more difficult" proposal.

[ue71603]

It is now possible to do the simple way again as RoutingConstraintInFrameGroup is optional

[ue71603]

reduce to max, we can do in the profile

[ue71603]

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

Soa penalty factor forDRTis 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)

Temporal distance needs better definition e.g. mean between departure time and arrival time. Other functions might apply.

He an Moriz are interested in a discusion.

[ue71603]

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.

[ue71603]

Input from Wilfried to process:

• When DRT istmodeled as a regular line with a ServiceJourneyPattern, then the new ServiceBookingArragements should be in the Line element. An extension of bookingArrangementsRelStructure is needed. Having it additionaly 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.
• Usage of RoutingContraintInFrameGroup. Optionally ok, Redudant, because RoutingContraintZones can be defined in hte Line and the ServiceJourneyPattern. If it is done a good example is necessary.