Meeting 1: the scope

[edwinvandenbelt]

If possible, a DG Move representative will clarify what is expected at the end of the project.

We can add here questions regarding the scope, to gather and bundle them to address them in the meeting.

[edwinvandenbelt]

A few questions regarding scope (expectations):

• must it facilitate complete door-to-door travels (all modes)?
• or must it just facilitate the 'bureaucratic' part of the travels (booking, tickets, claims, guarantees)?
• or must it only facilitate the functionality that is covered by all participating standards?

[OlivierBigex]

I guess that EUDIT must support all interactions between a retailer and a distributor/fare provider for multimodal public transport services. That includes consumption of a ticket (when burned by the traveller himself, but extensible to validating machine), accounting data (or we can say that a booking contains all relevant data?), dedicated enlistment of a device for secure barcode fulfillment.
Beside that, as a first step , we could exclude postpayment services (for regular public transport services - pay as you go - and vehicle sharing services).

[OlivierBigex]

Another point which seems essential to me is to reach an agreement quickly on the sales process, particularly the offer process for urban modes : is the offer request API mandatory ? Because for flat and simple urban fares, the retailer could have all necessary informations in published NeTEx fares. Some legacy urban distribution system only need to ask for a fulfillment, or even to send only an accounting info (when they manage the fulfillment localy).
But personaly, I won't include that process in EUDIT, because

• it could be valid for silo systems, when the distribution channels are a part of the ticketing system. For external retailers (e.g travel agencies), the ticketing system (Fare Product Owner) cannot trust the fare calculations done by the retailer.
• Even urban fares could be complex and could be combined with other fares in a multimodal trip. The retailer cannot manage that.

To be discussed...

[bourdelin]

EUDIT scope includes urban modes.
Postpayment differs from payment as we are use to understand payment as 'pre-payment", payment before travel. "Payment" should be out of EUDIT scope but not the "purchases" done after the travel.
Urban fares can be exchanged between operators with many ways : API exchanging json, API exchanging files, FTP, ...

[edwinvandenbelt]

How should it relate to other (Transmodel based or de-facto) standards, that publish traveler's information (not focusing on the functionality, but on the information)?

Transmodel based:

• NeTEx: to publish MMTIS traveller information (more or less static)
• SIRI: to publish public events

Other EU standards:

• DATEX-II / APDS: parking (and some booking functionality)
• OCPI: to publish charging information (and some booking functionality)

Global standards:

• GTFS-RT: to publish public events
• GTFS-OnDemand (GOFS): to publish on-demand operator information
• GBFS: to publish urban mode data

[OlivierBigex]

I would leave aside GxFS, as the French regulator deeply insists in swithing from GxFS to NeTEx/SIRI.

[CGantert345]

We should be as agnostic as possible to standards in areas we do not cover. Whether the trip based in our API is calculated from a UN, EU or industry standard data exchange should not have an impact.

Ignoring GxFS is not an option. There are no signs that the mayor players (google, third party distributors) will move away from GxFS.

[OlivierBigex]

Let's see the business requirement around travellers information in Eudit Context. Journey should be based on OJP. For fares informations, it's a trickier question that could be debated live :)