Closed derhuerst closed 6 years ago
I already added a section on mode
s a few days ago.
Feel free to add comments or to expand it further.
see #2
see also OpenTransport/vocabulary#3, OpenTransport/vocabulary#4 and OpenTransport/vocabulary#15
Following OpenTransport/vocabulary#4 we might consider using cycle
instead of cycling
and walk
instead of walking
.
Where did you see this? ๐
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
.
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?
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.
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.
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.
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 ๐
Following this, I'd keep the name mode
for the really fundamental types and call the 'subcategory' something like system
or subMode
.
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:
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?
I'd probably choose system
.
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?).
It's not really a modeDescription
though, right? It's rather a subMode
or a modeSubcategory
.
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 ๐ค
Again, I think we're talking about two different things.
For 1, I'd vote for subMode
. For 2, I'd vote for something like nameInSystem
.
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 ๐)
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
.
@derhuerst Could you provide an example for the subMode
and nameInSystem
keys?
@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.
I meant if you could a specific example on what would be the difference between subMode
and nameInSystem
๐
subMode
might have values like: midibus
or double-decker-bus
, whereas nameInSystem
might have values such as MetroBus
(Berlin) orGo Transit Bus
(Toronto).
Ok, should we try to propose some values for the subMode
field then? (At least for the most common types)
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.
We could mark the
subMode
field as reserved.
+1 Could you send a PR?
I will add the base mode proposals to the checklist at the top.
As @derhuerst and I already discussed, we might actually consider renaming ferry
to vessel
, since that's a more general term.
we might actually consider renaming
ferry
tovessel
, 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. ๐
@kiliankoe are you ok with this?
"ship" is a bit less general, but doesn't have a second common meaning, whereas "vessel" also means "containment" or "container".
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
? ๐
water transport
sounds good!
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 ๐
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.
I'd vote for ferry
then, to sustain the possibility of having something distinct like cruise
or cargo
.
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...
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?
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
.
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.
I don't get your point. But good to hear that we can agree on watercraft
. @kiliankoe opinions? ๐
watercraft
sounds great ๐
The list ofAs discussed, we will want to keepmode
s is still missing.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: