We're trying to understand the spec better to address our needs for mapping/linking travellers to their travel documents and to the offers/products they're consuming.
An example scenario:
A user wants to buy a simple Single Ticket for a group consisting of:
• 2 adults
• 2 students
• 2 children
These could be represented in the search as 3x UserProfile with count=2 and their respective ageGroups.
With the current schema definitions, we'd rely heavily on the Leg object for this:
- The
Offer object contains a list of legs, but does not directly reference travellers
- The
Product object describes what is being sold but does not reference travellers.
- The
Leg object is the only entity that links a specific travellerId to a specific productId.
Does this mean that for a single point-to-point journey (same sequenceNumber), we are expected to generate an Offer containing 6 distinct Leg objects (one for each traveller)?
Example structure:
• Offer A (Total price: X NOK)
◦ Leg 1: sequenceNumber: 1, traveller: "adult-1", product: "standard-ticket"
◦ Leg 2: sequenceNumber: 1, traveller: "adult-2", product: "standard-ticket"
◦ Leg 3: sequenceNumber: 1, traveller: "student-1", product: "discount-ticket"
◦ ...
◦ Leg 6: sequenceNumber: 1, traveller: "child-2", product: "child-ticket"
And this is if we're able to combine everything in the offer. At Entur our offer generation service typically returns 1 offer per eligible group of travellers, so in this case we would instead have Offer A for 2 adults, Offer B for 2 students and Offer C for 2 children. If the operator allows children to travel for free with adults, we would only get Offer A for both adults AND both children.
Is this "1 Leg per traveller" approach a viable solution? Does it align with Leg from Transmodel?
Related questions:
- Travel documents: When calling
/collections/travel-documents/items, we would possibly need to support both 1 document per Leg AND other scenarios where it's a shared document for the whole group. For single tickets, it would typically be 1 QR code per person.
- Selection: When the client calls
/processes/select-offers/execute, sending the single offerId implies selecting all 6 legs for all 6 travellers. Should the spec support "splitting" the group (e.g., only buying for the adults) without re-running the search?
- Generic products: For the simple products that don't have a physical "trip" like our single tickets or zone tickets, does it make sense to generate such dummy legs just to establish the link between the product and the traveller?
We're trying to understand the spec better to address our needs for mapping/linking travellers to their travel documents and to the offers/products they're consuming.
An example scenario:
A user wants to buy a simple
Single Ticketfor a group consisting of:• 2 adults
• 2 students
• 2 children
These could be represented in the search as 3x
UserProfilewithcount=2and their respectiveageGroups.With the current schema definitions, we'd rely heavily on the
Legobject for this:Offerobject contains a list of legs, but does not directly reference travellersProductobject describes what is being sold but does not reference travellers.Legobject is the only entity that links a specifictravellerIdto a specificproductId.Does this mean that for a single point-to-point journey (same
sequenceNumber), we are expected to generate anOffercontaining 6 distinctLegobjects (one for each traveller)?Example structure:
• Offer A (Total price: X NOK)
◦ Leg 1: sequenceNumber: 1, traveller: "adult-1", product: "standard-ticket"
◦ Leg 2: sequenceNumber: 1, traveller: "adult-2", product: "standard-ticket"
◦ Leg 3: sequenceNumber: 1, traveller: "student-1", product: "discount-ticket"
◦ ...
◦ Leg 6: sequenceNumber: 1, traveller: "child-2", product: "child-ticket"
And this is if we're able to combine everything in the offer. At Entur our offer generation service typically returns 1 offer per eligible group of travellers, so in this case we would instead have
Offer Afor 2 adults,Offer Bfor 2 students andOffer Cfor 2 children. If the operator allows children to travel for free with adults, we would only getOffer Afor both adults AND both children.Is this "1
Legper traveller" approach a viable solution? Does it align withLegfrom Transmodel?Related questions:
/collections/travel-documents/items, we would possibly need to support both 1 document perLegAND other scenarios where it's a shared document for the whole group. For single tickets, it would typically be 1 QR code per person./processes/select-offers/execute, sending the singleofferIdimplies selecting all 6 legs for all 6 travellers. Should the spec support "splitting" the group (e.g., only buying for the adults) without re-running the search?