Continue discussion for public transport types and vehicles

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 #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).