Facility extended with AvailabilityCondition
Closed this issue · 15 comments
- ServiceJourney should allow for facilities with Facilities and an AvailabilityConditionRef
- Call should allow for the same.
Either show how to do it correctly (dfifferently) or add this feature to ServiceJourney and Call
Discuss proposal with David and Laurent.
Stefan: needs to be denomalized in search (to ServiceJourney). We need to tell journey planners. Not against it.
@duexw : What do you think?
Stefan: In the case of the equipment. Is it no longer present. The slippery slope would be validity to ServicePattern
I agree that AvailabilityCondition can be very useful for Facilities, but I would not limit this to ServiceJourney and Call. If we go in that direction, we also need it for all Site, etc.
This said, it is tricky to add AvailabilityConditions in an elegant and backward compatible way ... we need to think about it
By the way, different but connected topic, I very recently looked for an AC (Air Conditioning) facility and didn't find any ! Did I miss something ?
I think we need AC
We might need a complete new enumeration for that.
In fact AvailabilityCondition are already there for facilities:
We are using a "facilities" wrapper:
It can contain several ServiceFacilitySet and each already have ValidityCondition that can be an AvailabilityContition thanks to the ValidityCondition_ substitution group.
So you jut need to group together the facilities having the same validity.
I add also @skinkie @klement-MENTZ to the discussion.
@Aurige Thanks for the first answer. However, we still have two issues.
ServiceFacilitySet in Call or CallPart
- For ServiceJourney this may work
- There is no ServiceFacilitySet in Call (or CallPart). Do you think we could add the structure there as well? Or do you think that a ServiceFacilitySet can only exist on a ServiceJourneyPart?
FacilityAssignment (different handling of AvailabilityCondition=
We have a huge number of ServiceFacilitySets.
If we would see it as a bundle, and because the AvailabilityCondition is there. We need a ServiceFacilitySet for each possible AvailabilityCondition (for the whole timetable). This results in 10000 ServiceFacilitySets with the same three Facilities and different AvailabiltyConditions.
Couldn't it be possible to have in facilities/ a combination of a ServiceFacilitySet and an AvailabilityCondition? Especially when only the ServiceFacilitySetRef would be used. Or is this the way to go?
So something along these lines would be intended:
``
<facilities>
<FacilityAssignment id="ch:1:facility:f2" version="any" order="1">
<validityConditions>
<AvailabilityConditionRef ref="ch:1:AvailabilityCondition:b7" version="any"/>
</validityConditions>
<ServiceFacilitySetRef ref="ch:1:ServiceFacilitySet:A___B" version="any"/>
</FacilityAssignment>
<Facility ...>
...
</Facility>
</facilities>
In noticeAssignments this was done already. So at least the concept is not new.
<noticeAssignments>
<NoticeAssignment id="ch:1:NoticeAssignment:ch_1_ServiceJourney_33-15358-1-1_2_0" version="any" order="1">
<validityConditions>
<AvailabilityConditionRef ref="ch:1:AvailabilityCondition:b8" version="any"/>
</validityConditions>
<NoticeRef ref="ch:1:Notice:I_04i" version="any"/>
</NoticeAssignment>
<NoticeAssignment ...>
...
</NoticeAssignment>
</noticeAssignments>
For ServiceFacilitySet in Call, since the Call is a view grouping information about the SCHEDULED STOP POINT, SERVICE JOURNEY, POINT IN JOURNEY PATTERN... it would be ambiguous to what the ServiceFacilitySet applies
For the FacilityAssignment that you are proposing, I don't see any big objection in my side. We can also rework a bit the FacilitySetGroup to be able to reference a list of Facilities. I put this as a discussion point for next meeting.
@Aurige on the first part. As Call is a VIEW we should be able to express things the same way.
A ServiceFacilitySet on a JOURNEY PART needs to be represented in the CALL PART (departure of call i and arrival of call i+1). Otherwise we have a problem. Or do you assume, that even if we have a fully CALL based representaiton that we still somehow should generate JOURNEY PARTs. That e.g. might solely exist, because the bar is no longer operational on the last 4 stops?
Can we clarify the actual requirement. - seemed to be several possible interpretations..
To have individual facilities on a SERVICE JOURNEY without wrapping in a FACILITY SET - undesirable?
To reuse the same FACILITY SET on multiple SERVICE JOURNEYs - already possible (use a FacilitySetRef instead of a FacilitySet )
To reuse the same FACILITY SET on just some of the CALLs of a SERVICE JOURNEYs - ie for part of a journey - this in effect already possible (use a FACILITY SET on a JOURNEY PART)
To have an AVAILABILITY CONDITION on a FACILITY SET - already possible, But note this can lead to contradictions if the condition conflicts with the scheduling of the journey
To allow multiple FACILITY SETs to be associated with a SERVICE JOURNEY, each with a different availability condition (eg restaurant on weekdays , bar at weekends) . Not currently popssible. Could consider extension to allow a list of FACILITY SETs as a choice instead of a single one on a SERVICE JOURNEY (and elsewhere)
To reuse the same FACILITY SET contents on multiple SERVICE JOURNEYS with a different AVAILABILITY CONDITION in each usage case. This is not currently possible - or desirable?
To allow SERVICE FACILITY SETs to be specified on individual CALLs - informationally derived from FACILITY SETs on JOURNEY PARTS - potentially confusing?
Hi Nick, I think you summarized it correctly. This is what you can do already with the simple HRDF (HAFAS) model and it saves you from having the same FacilitySet 100 times just because it has different availability sets. Instead of having a facility set on each call, you could also have something like FromCallRef and ToCallRef, since the main use case is that the facility is only available on a section of the journey.
> allow multiple FACILITY SETs to be associated with a SERVICE JOURNEY, each with a different availability condition
@nick this looks to be already possible
and each ServiceFacilitySet has its own ValidityConditions .
What we "miss" is the ability to reuse the same set of facilities with different ValidityConditions
and @ue71603 I still don't get what a FacilitySet on a Call would mean: let's say, as in your example, that the FacilitySet is just a Bar, would that mean that there is a Bar for the ServiceJourney, or just the JourneyPart, or et the StopPlace, or on the Quay, etc. The Call reference them all but will not target the FacilitySet.
This said, I agree that for now, the only way to say that "the bar is no longer operational on the last 4 stops" is to create a JourneyPart... which is not really convenient... we would need something like from StopPointInJP/Call to StopPointInJP/Call, or above stop order number (note that the "above stop order number" is something that can be done with a ValidityContition having a ValidityRuleParameterGroup ...)
Discussion: introduce a GroupOfFacilities (without AvailabilityConditions) that can be referenced by the FactilitySet => PR to be drafted @nick-knowles