Via + AdditionalTransferTime

[skinkie]

At this moment we are able to use AdditionalTransferTime in TripMobilityFilterGroup. In order to allow the end user to modify a transfer time at a specific stop (for future use) the interface should facititate 0:n AdditionalTransferTime bound to a Place.

[ue71603]

Ways to handle Accessibility we decided on (and which should be documented):

• Exclude stop points (NotVia) [recalculation by cenquirer]
• Hard accessibility criteria as they exist [selection by enquirer]
• Concatenating trip parts [contrlled by enquirer]
• NEW: Extra time at an interchange & recalculate
• NEW: More Accessibility information on Interchanges
• NEW: More information on TripResponse
• NEW: Filter for the additional information in the Response

[ue71603]

@herlitze : You asked for NEW: Filter for the additional information in the Response

I think this is already covered with IncludeAccessibilityDetails in BaseTripContentFilterGroup

[ue71603]

@skinkie @Aurige To have the additional transfer time: Should this be part of the Via structure (MENTZ only supports a single Via). This would be easiest. Then it is possible in Trip Request/Multipoint Trip Request and Refine in one go. Or should we put it somewhere else?

[ue71603]

@Aurige @trurlurl Additional infomration about what is there. If we extend Accessibility once more. Which parts of NeTEx do we need to consider. We currently only have some Facilities in TransferLeg/Attribute and PathGuidance/PathLink is limited in OJP:

Do we want to add Equipment from NeTEx in full? Or only an EquipmentEnumeration? Or an Equipement with some Attribute key/vales that we don't specifiy?

[skinkie]

I would would tackle it via a structure with a list of Place <-> AdditionalTransferTime allowing single shot requests. There are some counter examples for example this would not allow you to get the same guaranteed trip back. @herlitze suggested to have a refinement which includes this updated time. A completely different approach would be doing a new request in the client from the arrival vertex to the endpoint with the additionalTransferTime added to the request. The latter should already be possible.

[ue71603]

14.4.2023: Adding more time at stops should be done by changing the TransferLeg and recalculating the rest of the trip with a new trip request. Dirk: Complete recalculation probably is needed also from the full trip, I would like to have a user modification of the network. Matthias IfVia/AdditionalTransferTime <-- making it clear that it is not added, but it must be at least that.comment change. Malte: It should not be supported in the interface.

Dirk's problem: In Kassel he needs more time . Possible calculation A-> Kassel -> C as first result. Then recalculate with TR(A,C,NotVia(Kassel)) and then combine result.

[AndreasAtSBB]

Stefan: We like to add it. Malte too. Others agree.

How to do it?

• Trip parameters are required.
• Add the new details, e.g. realtime or different transfer time.

Solution: (Norman and Malte agreed) New TripChangeRequest service. Reason: The TR has not the previous trip result.

Functionality:

• Add WaitingTime at transfer (timed leg end/ timed leg start)
• Add sharing operator to an estimated trip

Parameter:

• Single Trip to change (given by TR before)
• TripLegRef from and to or StopPointRef
• Flag for earlier departure or later arrival (only with StopPointRef)
• TripRequestOptions (same structure as in TR)
• Selected Operator

Possible answer (probably) is a TripResponse. (Same as from TR)

[AndreasAtSBB]

I open a new Issue for the description of the new Service, reverencing to this. The tips and tricks document I change accordingly, that we can close Issue #245 in the future. Beside of that I put Malte in the Lead to make the according Pullrequest to add the service description to the XSD documentation. Should be finished till 13.5.2023 that all things can be synchronised to this. Norman can then add the general description to the main documentation. Should be finished when woting for work Item is finished. In one of the following meetings we can then finalize and cross check everything, before closing Issues #254, #352 and Pull Request for the XSD.

[ue71603]

@trurlurl Do you think we have fixed everything from this list? `Ways to handle Accessibility we decided on (and which should be documented):

Exclude stop points (NotVia) [recalculation by cenquirer] Hard accessibility criteria as they exist [selection by enquirer] Concatenating trip parts [contrlled by enquirer] NEW: Extra time at an interchange & recalculate NEW: More Accessibility information on Interchanges NEW: More information on TripResponse NEW: Filter for the additional information in the Response`

[trurlurl]

@ue71603 I think that accessibility is covered as intended, I don't miss anything. However, please have a look at points 3, 6, 7:

1. Exclude stop points (NotVia) [recalculation by cenquirer] -- OK, NotVia in OJPTripRequest, OJPMultiPointTripRequest
2. Hard accessibility criteria as they exist [selection by enquirer] -- OK, NoStairs etc. in BaseTripMobilityFilter
3. Concatenating trip parts [contrlled by enquirer] -- NOK, one of the discussions in Bern revealed that trips should never be stitched together by the enquirer
4. NEW: Extra time at an interchange & recalculate -- OK, OJPTripChangeRequest (not merged yet)
5. NEW: More Accessibility information on Interchanges -- OK, IncludeAccessFeatures, IncludeAccessFeatureStatus, IncludeAccessibilityDetails
6. NEW: More information on TripResponse -- OK, parameters IncludeAccessFeatures, IncludeAccessFeatureStatus, IncludeAccessibilityDetails in OJPTripRequest and OJPTripRefineRequest
7. NEW: Filter for the additional information in the Response` -- OK, see previous point

[ue71603]

3. Concatenating trip parts [contrlled by enquirer] -- NOK, one of the discussions in Bern revealed that trips should never be stitched together by the enquirer

I think that was removed and is that way in the "code".

[ue71603]

So I close the issue as it is covered 100% by other PR