Team 2: Homework: the 'What' part of a request

[edwinvandenbelt]

We started with the discussion yesterday, and it looks like that a trip isn't specified by legs... It is specified by the places (from, to, intermediate or virtual stops). Sometimes it is required to enlist all intermediate stops (BoB), sometimes you only have a start- or end-location (TOMP, urban modes).

We started of with this:

[edwinvandenbelt]

What I have in mind now (idea):

we request a trip, with a list of place references. The start, end and intermediate places must be separated. An array of places is not sufficient enough (If there's only one place, is it a start or an end location?). In the 'Filter' part, you can refer to a combination of place-references, and whether you want to request an offer for this, and/or what is your filter (geographical filter, like a country-border), service yourneys to use (NetworkValidity), ...

It would simplify the model, and we can add things like the requested service journey, parts of legs (cross border), in the validity-collection.

We could use this:

[ { type: temporalValidity, operatingDay: "2026-05-22", .. } ]

And this:

[ {type: serviceValidity, legId: 23, serviceJourney: ... typeOfSerice, classOfUse, ... etc } ]

Each validity should be assignable to a leg.

And this:

[ { type: fareValidity, typeOfFareProduct: .., distributionChannel: ..., fullfilmentMethod: ... etc } ]

Or this:

[ { type: routingValidity, borderPoint: placeRef ... } ]

I haven't seen a geographical one (search filter), but I guess it must be out there.

Some organisational validities:

[ { type: organisationalValidity, organisation: "DB" } , { type: organisationalValidity, mode: "Train" } ]

And this can be used in the POLICY:

[Ulf9]

A preliminary comment is that we should assume that OJP provides a list of DATED VEHICLE JOURNEYs that fulfil the search criteria as input to OTI. The search criteria for OJP could include required via-points etcetera. Thus, we should NOT redo the work of filtering out relevant DATED VEHICLE JOURNEYs in OTI.
To clarify; from OJP we need for each suggested solution a sequence of LEGs. For each timed LEG there should be a start-PLACE and an end-PLACE and a reference to the relevant DATED VEHICLE JOURNEY. This could either be a direct reference to the DATED VEHICLE JOURNEY or an indirect combined reference consisting of a SERVICE JOURNEY identifier in combination with the OPERATING DAY date in question.

These identifiers should of course match what has been provided or will be provided on the the national access points according to NeTEx profile EPIP (European Passenger Information Profile) and SIRI profile (European Real-Time Passenger Information Profile).

[edwinvandenbelt]

I think we should take a step beyond this point. It is not only about coping with TIMED LEGs, but also with the other leg types.

[edwinvandenbelt]

And OSDM has the capability to specify 'Sections', to request partial offers; e.g. from a virtual place (border) to a station.

[edwinvandenbelt]

And a collection of legs and a list of places (referred to from the legs) is very OJP like.