Add accessMethod as root-element to POST bookings-one-stop and booking

[zerwuff]

Is your feature request related to a problem? Please describe.

As a TO, for bookings i want to know which acesssMethods are used to book an asset.

Urgency

Major, otherwise meta-field is used and this should be more clarified with an separate field.

Additional context

In the bike sharing context, the TO needs to know which accessMethod is used to book a bike.
Ex: issuing a one-stop booking request:

For QR code, no distance check is done, bike opens right away. No Position is required from the user
For number pad usage, a position check is required. The logic is done by the TO.

Describe the solution you'd like

An an optional field 'accessMethod' (root level) in one-stop-booking request and booking request.
Possible values: all accessMethods of the asset object.

Describe alternatives you've considered

Using extraInfo Field with 'accessMethod' as key and values: all accessMethods of the asset object.

Possible Implementation

[edwinvandenbelt]

Hello Zerwuff, I have a question. Is the QR code directly related to the bike? The TO should know the access modes in that case (useAssets). Or in case it is related to an asset type (like a e-bike) or a station, it could be convenient to add.

[zerwuff]

Hi @edwinvandenbelt thanks for looking into this.
The QR code is directly related to the bike, i.e. in the QR code is a bike number encoded. The issue is, that the User, respectivly the MP decides how to access the asset from the TO:

scenario 1:
the end-user: selects the bike from a map (MP end user app) , out of a list of assets, the he decides to book bike number 1234 -> MP sends POST: one-stop-booking with assetId 'asset1' and accessMethod 'manual' and position data (lat,lon)
TO: does distance check, verifies if the user is close to the bike (i.e verifies last bike position against app request position) -> reject one stop booking if user is in paris and opens a bike in amsterdam.

sceanrio 2:
the end user user: scans a code from the bike, App reads the bike number 1234 from that 'qrcode', MP sends POST: one-stop-booking with assetId 'asset1' and accessMethod 'qrcode' and position data (lat,lon)
TO: does no distance check, because user must be in amsterdam close to the bike, because qrcode is scanned.

To diff between both scenarios , we need the accessMethod atttribute in one-stop booking to define on the MP side how the asset is accessed to do business checks on the TO side.

[edwinvandenbelt]

Ah clear. You don't want to know how a bike can be opened, but how the booking is initiated. Is it something for a 1.7 or can we include it in v2.0?

[zerwuff]

hi @edwinvandenbelt thanks for looking into it. exactly, how the booking is initiated.
version 1.7 would be nice, but not critical if there is a big queue already.

for open the bike, i would rather look at the legs/{id}/events, but this is not in scope yet.

to have a compliance upfront with the new api, can you already say if this field is going to be 'accessMethod' with the existing 'accessMethods' already defined in the 1.5 api ? so we can engineer against this most-probably future version :)
BR

[edwinvandenbelt]

Added it in v2. In the 'use-asset' endpoint (that's needed to 'book' a bike directly on the street or from a map), the 'accessMethod' (in v2, Transmodel compliant, it will become 'type of travel document', so it can be used to access an asset or proof of travel rights.

[zerwuff]

Thanks @edwinvandenbelt !