Skip to content

Conversation

@ue71603
Copy link
Contributor

@ue71603 ue71603 commented Sep 24, 2025

Implementing more restrictions/eligibilty for services.

This is needed to describe many rules that exist for DRT services.
Based on the discussion of: https://3.basecamp.com/3256016/buckets/2570434/messages/8778284879
based on #920
redoing #958 for next

#958
not working yet
@ue71603 ue71603 added this to the netex_2.0 milestone Sep 24, 2025
@ue71603 ue71603 added the change-request Additional feature, discussed withe the group and having a proper Change Requet in Basecamp. label Sep 24, 2025
@ue71603
Copy link
Contributor Author

ue71603 commented Sep 24, 2025

redoing #958
not working yet and not adapted examples

TODO:

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

@ue71603 ue71603 added the needs documentation update The NeTEx document needs to be updated label Sep 24, 2025
@ue71603 ue71603 marked this pull request as ready for review September 24, 2025 12:01
@ue71603
Copy link
Contributor Author

ue71603 commented Sep 24, 2025

We can now have the discussion

ue71603 and others added 4 commits September 24, 2025 16:12
…rictions_version.xsd

Co-authored-by: Stefan de Konink <stefan@konink.de>
…_version.xsd

Co-authored-by: Stefan de Konink <stefan@konink.de>
…_version.xsd

Co-authored-by: Stefan de Konink <stefan@konink.de>
…_version.xsd

Co-authored-by: Stefan de Konink <stefan@konink.de>
@ue71603 ue71603 changed the title redoing #958 for next Adding different types of restrictions between Services especially for DRT Sep 24, 2025
@skinkie
Copy link
Contributor

skinkie commented Sep 24, 2025

I think what you are still missing are the unique constraints in de root xsd. And potential relationships.

@ue71603
Copy link
Contributor Author

ue71603 commented Sep 25, 2025

@skinkie will check. I made them all BookingArrangements from the id point of view. But I check

@Aurige
Copy link
Contributor

Aurige commented Oct 6, 2025

I don't think that it can be a 2.0 milestone since it contains several addition from the CEN submitted version (ServiceCompetitiveCondition ...)

@ue71603
Copy link
Contributor Author

ue71603 commented Oct 6, 2025

@Aurige 2.0.1? Also those are additions, so they don't invalidate anything that is in the 2.0 specification

@Aurige
Copy link
Contributor

Aurige commented Oct 6, 2025

yes, but additions need documentation .. the idea behind the 2.0 is to stay as close as possible to the document. I'm of course fully Ok to have such PR in post 2.0 (also note that it also triggers a TM change request...)

@TuThoThai
Copy link
Collaborator

Move to milestone v2.1 due to the need of Transmodel update

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not think it is a good idea that as a data producer you have to enumerate all regular services ("LINE") to state the competition rules. The data producer will not have these in their system, unless they are a data integration system. Even if they do have all LINEs, the process for determining the competing LINEs is not straight forward. Taxi-like DRT will usually be determined by a geographical area and by operating days and times. So the system would need to determine the stops in the area, then determine the LINEs serving the stops, and then find out if there are any journeys during the operating time of the DRT. I suggest that it is not necessary to state the competing regular LINEs, the journey planner can work that out at run time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@duexw counter-proposal? how would you state them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is now optional. Also I added some more points.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is what I had in mind - If you do not state any LINEs, it means that the competitive rule applies to all LINEs.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Just formal: We should not call the super type "_Dummy" in the final version, it sounds like "work in progress"
  2. 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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_Dummy is the defintion that facilitates the substitutionGroup. If you have any better proposal speak out fast. Because this does result in breaking changes for anyone that is generating code from the schema.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we discused in the group and agreed to call it _Dummy. We always will have problems with the name,whateverwe choose I guess.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - dummy it is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have any better suggestion. Please tell us.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reduce to max, we can do in the profile

ue71603 and others added 3 commits November 19, 2025 10:59
…_version.xsd

Co-authored-by: Stefan de Konink <stefan@konink.de>
…_version.xsd

Co-authored-by: Stefan de Konink <stefan@konink.de>
…_version.xsd

Co-authored-by: Stefan de Konink <stefan@konink.de>
@ue71603
Copy link
Contributor Author

ue71603 commented Nov 20, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

change-request Additional feature, discussed withe the group and having a proper Change Requet in Basecamp. needs documentation update The NeTEx document needs to be updated needs transmodel update

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants