mode tracking issue

[derhuerst]

The list of modes is still missing. As discussed, we will want to keep mode as general as possible, in order to avoid having to deal with 100 different values.

• train
• bus
• ferry

Proposed:

• walking
• car
• bicycle
• taxi
• aircraft
• gondola

edge cases:

• trolleybuses
• coaches

[juliuste]

I already added a section on modes a few days ago.

Feel free to add comments or to expand it further.

[juliuste]

see #2

[derhuerst]

see also https://developers.google.com/transit/gtfs/reference/extended-route-types

[derhuerst]

see also OpenTransport/vocabulary#3, OpenTransport/vocabulary#4 and OpenTransport/vocabulary#15

[juliuste]

Following OpenTransport/vocabulary#4 we might consider using cycle instead of cycling and walk instead of walking.

[derhuerst]

Where did you see this? 🙈

[juliuste]

Following OpenTransport/vocabulary#4 we might consider using cycle instead of cycling and walk instead of walking.

Actually, I thought about this again and my proposal would be using the -ing gerund verb form whenever the user has to operate the vehicle him-/herself while using nouns whenever the vehicle will be operated by someone else (like a transport agency).

For example: If someone uses car- or bikesharing, the mode should generally be called cycling or driving, whereas if someone uses a Rikscha, the mode would be cycle, bike or maybe even rikscha.

[juliuste]

Apart from that, I propose not using specific train types like tram because the transition between a tram and a train like a subway can be smooth (see Stadtbahn Hannover). Objections?

[juliuste]

Ok, @derhuerst and me had a long discussion, found dozens of edge cases, that's why we tried to keep this list as simple, intuitive and especially as useful in the "mainstream usecases" as possible. We propose the following:

• walking
• car
• bicycle
• taxi (any car or bicycle operated by another person)
• train (railbound: including subways, trams, rack wailways, maglev, San Francisco cable cars, Wuppertaler Schwebebahn, Hyperloop…)
• bus (municipal transport buses, shuttle buses, rail replacement buses, long-distance coaches…)
• ferry
• aircraft
• gondola (see here)

@kiliankoe If you agree with this, I'll edit the checklist at the top of this thread.

[kiliankoe]

I've mostly been building stuff in a local context, e.g. for Dresden. There's a clear distinction between trams and trains here. I have been dealing with API endpoints in the past that don't deal with mode information, which lead to me having to parse that information from the line's name, which is a special kind of hell. On the other hand, the extensive list of modes that services like the VDV's TRIAS support is a clusterfuck in its own regard.

I'm not really sure where exactly the best middle ground lies. The above list looks to fit a the general idea rather well. To add my two cents I would add a specific tram and subway type to the list. I'd say that most people have a clear notion in their head as to what the differences between a train, tram and subway are. Of course there are overlaps and smooth transitions, but I'm sure that either providers will choose what best fits the bill in their opinion or that FPTF's mode overrides for specific journeys etc. would be very useful here to make the distinction where necessary.

[juliuste]

I have been dealing with API endpoints in the past that don't deal with mode information, which lead to me having to parse that information from the line's name, which is a special kind of hell.

You're definitely right. We forgot proposing another thing we had in mind in order to "fix" this. Our idea was to have the really basic mode key which is limited to a short list of universal keywords that are operator-unspecific and would allow a distinct classification of modes, not depending on the user's knowledge of the system. Example: For the Stadtbahn Hannover, people could disagree on whether to use tram or subway, depending on their preferences or their knowlegde of the system, while everyone could agree that those vehicles are indeed a train.

But since you're right about the need for more information than just "this is a train", we thought about adding a product* key with an operator-specific mode type that - unlike mode - probably wouldn't be limited to some fixed keywords. This could be things like s-bahn, u-bahn, subway, suburban, tram, schwebebahn, stadtbahn, cablecar…

I have to admit though that it could still be nice to also have some predefined "proposals" for the most common product* keys, like subway, tram, suburban etc.

* I'd be really happy to hear other proposals for the name of this key, since product might not be the most intuitive name.

[kiliankoe]

That sounds like a great solution! As to the naming, maybe use mode directly for the new value and something like mode_category for the short list? Or the other way around with something like mode_subcategory for the new value? Or mode_specific, mode_descriptive. Not sure if any of those are good 🙈

[juliuste]

Following this, I'd keep the name mode for the really fundamental types and call the 'subcategory' something like system or subMode.

[derhuerst]

Ok, we seem to have consensus on the fact that a small number of mode values (in order to keep this future-safe) as well as a field for sub-types or local names are necessary.

I must admit that the term "product", which I have used until now, is an awkward choice for what I try to describe:

• It should convey how a certain type of vehicles behaves in local public transport, e.g. trams have different functions in Berlin vs. Hannover).
• It should convey different types of access vehicles. E.g. in London, there are more than two types of trains, each with separate membership programs. They would all be characterised as regular non-highspeed metropolitan rail, but for commuting, it matters a lot which is which.

[juliuste]

Ok, so far we have the following proposals for the name of the new key:

• mode_subcategory / modeSubcategory
• mode_descriptive / modeDescriptive
• system
• sub_mode / subMode

Any other proposals and/or opinions on those?

[juliuste]

I'd probably choose system.

[derhuerst]

IMHO system is way to general. It might mean anything, for example a transport system (as in one or more connected transport agencies). If you intention is to convey something like "name of the vehicle/mean of transport in its own transport system", then I'd at least use something like nameInSystem or systemName.

Even then, I find modeDescription better, although it sounds like a human-readable description (we're talking about a machine-readable field, don't we?).

[juliuste]

It's not really a modeDescription though, right? It's rather a subMode or a modeSubcategory.

[kiliankoe]

I think modeSubcategory or similar might describe the field best in the way that it's machine-readable and not a text describing mode. At least from the current list of suggested names. I'm sure there's got to be a better term for this out there somewhere 🤔

[derhuerst]

Again, I think we're talking about two different things.

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

For 1, I'd vote for subMode. For 2, I'd vote for something like nameInSystem.

[juliuste]

If we differentiate the two keys, why not just call the first one vehicle? (If that's what you wanted to express, I don't know 😄)

[juliuste]

Even though one might like to reserve vehicle for the actual model number/series of the vehicle, such as Baureihe X or vehicle 125-332.

[juliuste]

@derhuerst Could you provide an example for the subMode and nameInSystem keys?

[derhuerst]

@juliuste As you said, vehicle sounds to me like the model name or even individual number of a single vehicle. I'm talking about things like "S-Bahn, Stadtbahn, Hochbahn, Metro, … Express". Another good example is Toronto, where GO Transit trains are distinct from national rail trains, but yet a different operator wouldn't be enough.

[juliuste]

I meant if you could a specific example on what would be the difference between subMode and nameInSystem 😄

[derhuerst]

subMode might have values like: midibus or double-decker-bus, whereas nameInSystem might have values such as MetroBus (Berlin) orGo Transit Bus (Toronto).

[juliuste]

Ok, should we try to propose some values for the subMode field then? (At least for the most common types)

[derhuerst]

I would do that in a later version. Given that I finally want to be able to let documents point to and libraries validate against a fixed version of FPTF, IMO it is more important to publish a first version. We could mark the subMode field as reserved.

[juliuste]

We could mark the subMode field as reserved.

+1 Could you send a PR?

[juliuste]

I will add the base mode proposals to the checklist at the top.

[juliuste]

As @derhuerst and I already discussed, we might actually consider renaming ferry to vessel, since that's a more general term.

[derhuerst]

we might actually consider renaming ferry to vessel, since that's a more general term.

This seems to be the last pending question to decide on, before we can finally release 1.0.0. 🙌

[derhuerst]

@kiliankoe are you ok with this?

[derhuerst]

"ship" is a bit less general, but doesn't have a second common meaning, whereas "vessel" also means "containment" or "container".

[kiliankoe]

Personally I'd prefer keeping ferry, even if some of its edgecases become a bit awkward. A vessel can refer to pretty much anything from a wine barrel to a TARDIS. And I feel that it's a tiny bit unintuitive for people trying to understand the FTPF spec or data for the first time. A ferry makes it clear that we're talking about some kind of water transport. Or maybe even just use water transport? 😄

[derhuerst]

water transport sounds good!

[juliuste]

I'd much prefer ferry over water transport. If we used the ladder, it would only be consistent to rename the other modes to something like rail transport, road transport, cable transport or even land transport, which would be too much IMHO 😄

[derhuerst]

water transport would include cruise ships, which are clearly distinct from ferries. On the other hand, the term also includes maritime trade vessels, and the wikipedia article redirects to "Maritime Transport", which mainly shows container ships.

[juliuste]

I'd vote for ferry then, to sustain the possibility of having something distinct like cruise or cargo.

[derhuerst]

I'd rather vote for water transport. My point was that I want cruise ships to be in one category with ferries. Also, I'm not sure if cargo ships will ever be relevant to FPTF, as travelling with them is usually not public. But who knows...

[juliuste]

To be consistent with that, we would also have to use cable transport instead of gondola, rail transport instead of train and air transport instead of aircraft, right?

[derhuerst]

Would would we have to use that? Also ferry/water transport is different from rail/rail transport. Analogous to aircraft, we may also want to use watercraft.

[juliuste]

Would would we have to use that?

To be consistent, because rail/air are not so different from water, IMHO. watercraft sounds very good to me, though.

[derhuerst]

I don't get your point. But good to hear that we can agree on watercraft. @kiliankoe opinions? 😛

[kiliankoe]

watercraft sounds great 😊