-
Notifications
You must be signed in to change notification settings - Fork 45
Adding different types of restrictions between Services especially for DRT #959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: next
Are you sure you want to change the base?
Conversation
|
redoing #958 TODO:
|
|
We can now have the discussion
|
xsd/netex_framework/netex_reusableComponents/netex_serviceRestrictions_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
…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>
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
|
I think what you are still missing are the unique constraints in de root xsd. And potential relationships. |
|
@skinkie will check. I made them all BookingArrangements from the id point of view. But I check |
|
I don't think that it can be a 2.0 milestone since it contains several addition from the CEN submitted version (ServiceCompetitiveCondition ...) |
|
@Aurige 2.0.1? Also those are additions, so they don't invalidate anything that is in the 2.0 specification |
|
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...) |
|
Move to milestone v2.1 due to the need of Transmodel update |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Just formal: We should not call the super type "_Dummy" in the final version, it sounds like "work in progress"
- 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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - dummy it is.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
xsd/netex_part_3/part3_fares/netex_extendedBookingArrangements_version.xsd
Outdated
Show resolved
Hide resolved
…_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>
|
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 Soa penalty factor forDRTis missing 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. |
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