Add AccessFeatureStatus on PathLink

[ue71603]

AccessFeatureStatus on a PathLink to indicate a broken access equipment.

#194 asks for data to tell whether, e.g., an elevator is broken, but to nevertheless show the route so that the passenger knows that this route would exist but is currently not feasible.

EquipmentStatusEnumeration has been added from NeTEx to indicate the status of an access equipment. The following would indicate that the elevator is broken:

PathLink.AccessFeatureStatus: notAvailable (new)
PathLink.AccessFeatureType: elevator

The broken elevator makes the complete TransferLeg unfeasible - this should be flagged in the TransferLeg (e.g., TransferLeg.Feasibility : accessEquipmentOutOfService) or/and at the level of the Trip.
What solution would you prefer?

To also handle the case that the TranferLeg is not feasible due to a SituationFull (can that happen?), this could be indicated by:
TransferLeg.Feasibility: seeSituations

Replaces #235

[Aurige]

I approved it since I'm ok with it, but won't be against a "partiallyAvailable" if somebody thinks that it is useful (double door with one broken, etc.) ... but I recognise that it is often difficult to use

[trurlurl]

I think the questions raised in the first comment should be answered before closing this PR - what are your opinions regarding
TransferLeg.Feasibility : accessEquipmentOutOfService / seeSituations or
Trip.Feasibility ?

[trurlurl]

Documentation regarding the PathLink part is up do date so far.

[ue71603]

Will discussed the 25.10.
Malte: Important: How to request it. I would not do this normally. The result structure is fine. The point from André and overall request must be discussed.
Christophe: Partial only in connection with a comment.
Malte: Depends, if one wants to show such a journey.
We would need a notice on the element as well.
==> Matthias: Checks the partial part.

[ue71603]

André: Can the non-working in the situation?
Stefan: This works. When I am aggregator, how do I communicate if it is still available..
André: AccessFeature and the Situation should be linked.

[sgrossberndt]

SIRI contains

• an EquipmentStatusEnumeration in siri/ifopt/ifopt_equipment-v0.3.xsd with values unknown, available, notAvailable
• a FacilityStatusEnumeration in siri/siri_model/siri_facility-v2.0.xsd with values unknown, available, notAvailable, partiallyAvailable, added, removed

As both don't completely fit I guess its fine to introduce our own enumeration. Or should we use one from SIRI? If we define our own enumeration - is "EQUIPMENT" the correct term here or should it rather be AccessFeatureStatusEnumeration?

[trurlurl]

@sgrossberndt AccessFeatureStatusEnumeration would be nicer when looking at OJP alone, EquipmentStatusEnumeration was chosen since it refers to the NeTEx term. I'm changing it to AccessFeatureStatusEnumeration.

[trurlurl]

I hesitated adding a AccessFeatureRef (siri/ifopt/EquipmentRefStructure). I didn't add it yet because the situation information relating to the Equipment can be directly attached to the PathLink (SituationFullRef).

[ue71603]

André is doing another small change, then ready for review.

[AndreasAtSBB]

OK.

[sgrossberndt]

This merge moved the position of TripStatusGroup. Was this on purpose?

[skinkie]

Please report all collateral damage due to manual merging to @ue71603

[skinkie]

@sgrossberndt and the fact that this change was not picked up by CI shows we lack examples.

[ue71603]

I did it on purpose. In all other examples Situations were the last before Extension. It thought it was a mistake during the change in Situations. Certainly I should not have done it in this PR if that was not the case (as it seems), but from homogenity, I think it is right. I can undo it in an additional PR if you like @sgrossberndt

[sgrossberndt]

No, don't undo it. But it should not have been part of this PR but handled separately.

[ue71603]

I know... I only did it, because I thought it was messed up during the merge by me or during the creation of the PR. Should have checked.