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.
• Add a structure for parametrised link
• Enforce a parametrised URI in the BookingUrl for BookingArrangement

[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

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

[TuThoThai]

As per the task force meeting of 23 Arpil 2026, additional to-do:

• Add a structure for parametrised link
• Enforce a parametrised URI in the BookingUrl for BookingArrangement

[ue71603]

For the next meeting I suggest to discuss the following:
• We could have a look at the PR and what I think needs to be done there: https://github.com/NeTEx-CEN/NeTEx/pull/959
• The PR contains also a README.md to explain examples: NeTEx/examples/functions/drt at extend_service_restrictions_new_modes · NeTEx-CEN/NeTEx
• Which brings me to the examples: The examples that I used from basecamp describe the current situation. I think we need a list of possible business models and then examples illustrating them (perhaps based on real ones).
• Especially the focus should be on the details: Which rules are necessary. The PR deals with providing the rules. We have 3 audiences for the rules: trip planners, passenger information systems, ticketing systems. E.g. a trip planner does not care about 20’000 collection points in an area. It will then assume it is a area-service.
• LineType: Can we go through the list and amend the relevant description of each type? Are they complete? NeTEx/examples/functions/drt at extend_service_restrictions_new_modes · NeTEx-CEN/NeTEx
• FlexibleLine -> Line I think this will happen, right?
• FlexibleStop/FlexibleArea remain, right?
• Do we always wrap a ScheduledStopPoint into a FlexibleStop? I think MENTZ does it.
• Who can construct an example for each LineType?
• Who can provide a HailAndRide especially?
• Will we use TypeOfFlexibleService when we have the LineType?
• Where do we define the list of rule?
• Currently we need to add a MobilityService to the Model. Wilfried suggests that we allow everything in Line/bookingArrangement. What is the opinion?
• Fares and Booking
o BookingService link. Hacon proposed which information is needed. As we are discussing NeTEx, I guess the only relevant thing is to point to the service end points and the protocols associated. The other information that was outlined is something the trip planner has to send to it. I think OJPFare can do everything except it does not know which service to send it to.. And also: In many cases the tickets can be provided by a different organization than the transport operator.
o AT has some things about zones being also propaged in the data for price calculation.