Continue discussion for public transport types and vehicles

[ialokim]

Since we are now working on getting release 2.0.0 closer (see the checklist #37), I think it's time to continue the discussion which stopped about a year ago in #4 about mode and subMode.

Currently, mode can have its value from a very short list (about 9 different values), which already enables a first differentiation between different public transport types such as train or bus. There is also the already reserved field subMode which should allow a more fine-grained distinction between e.g. tram or subway, but there was no decision about the exact values.

As already pointed out by @derhuerst in #4, there are two main purposes of specifying more precisely the type of a public transport:

1. There is the more-detailed, machine-readable field specifying the type of vehicle.
2. And there is its name in its local public transport system.

I wanted to present my idea about how we could include both pieces of information to FPTF.

• Add a new item type product with the following fields:

{
    type: 'product', // required
    id: '123456', // required
    name: 'Métro', // required
    mode: 'train', // see the current list on modes, required
    subMode: 'subway', // see my proposal below, optional
    scope: 'urban', // see my proposal below, optional
    stoppingPattern: 'all_stops' // see my proposal below, optional
}

• Add a new required field line.product and optional fields route.product, schedule.product and leg.product (plus probably trip.product, see trips, schedules and legs in fptf 2 #61) which would override the product specified by the corresponding line/route/trip pretty similar to the current mode overriding mechanism.

• Discuss whether to keep mode on the FPTF types mentioned above as it could lead to inconsistence between mode and product.mode, but at least marking it as optional or even deprecated.

• Discuss the different values for subMode which should depend on the specified value for mode. I would propose the GTFS specification for extended route types as a starting point, but adapting it to the following point.

• To be able to provide a better machine-readable description, I wanted to add some of the ideas I already proposed quite a time ago for OSM tagging of public transport services (see the OSM-Wiki):

  • product.scope would allow the values urban, local, regional, national, international to specify the area served by the public transport service
  • product.stoppingPattern to express the frequency a public transport type stops: all_stops, limited, main_stops, non_stop

product.subMode, product.scope and product.stoppingPattern are explicitly marked as optional and should only be specified if there is no ambiguousness. product.name would serve for the public transport service name in its local public transport system whereas the other fields would allow a machine-readable distinction between them. As with other FPTF objects, it should be possible to reference or in-line a product directly.

As already mentioned, this is only a proposal and I'm very open to suggestions and comments (also regarding the names I've chosen for now).

[ialokim]

While thinking about my proposal, I've noticed that the current mode fields are used for two slightly different purposes:

1. line.mode, schedule.mode and route.mode is used to specify the public transport type. So here, it only makes sense with one of the values that represent public transport while e.g. the values walking or bicycle (and even taxi and car) will not be used here.
2. leg.mode is used to specify the way the passenger should pass this section of the journey (which does not have to be by public transport). This is the only field where all the current values really make sense.

This is also a weak point of the new product type: It seems quite unintuitive to use some sort of walking or cycling product. I would therefore propose to only use the product type for real public transport services and add a new field leg.transport with values public, walking, bicycle, car and taxi (feel free to suggest a better name!). Then we could remove the latter four from the mode values and this way eliminate the current inconsistent usage of mode.

I am aware that all of this would be a quite huge breaking change to the current specification, but I think it allows much better differentiation and specification of real public transport services and products in different cities.

What do you think? (especially pinging @juliuste)

[andaryjo]

I like the idea of introducing separate fields for a mode's name and it's machine-readable type. However, it even might make sense to decouple the product from the line, because:

1. There are use cases where a line does not necessarily have just own or at least a static mode. I've seen scenarios where replacement busses drive using a tram's line name. Not sure how this would be mirrored in the data delivered by a provider though.
2. It would solve the problem addressed by @ialokim of having modes in a leg that don't apply to "scheduled" legs. I'm not too sure about calling wrapping modes like walking or car in a product, but having another seperate transport field that is only populated under certain circumstances seems overkill to me.

Unrelated to the previous points, I think it would make sense to introduce unknown for both mode and subMode. There might be scenarios where an API returns a mode that a client is not able to map and rather than returning null or a fallback selection, it would be a better approach to return unknown.