Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`mode` tracking issue #4

Closed
derhuerst opened this issue Mar 4, 2017 · 45 comments

Comments

@derhuerst
Copy link
Member

commented Mar 4, 2017

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:

@juliuste

This comment has been minimized.

Copy link
Member

commented Mar 6, 2017

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

Feel free to add comments or to expand it further.

@juliuste

This comment has been minimized.

Copy link
Member

commented Mar 6, 2017

see #2

@derhuerst

This comment has been minimized.

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Jul 16, 2017

@juliuste

This comment has been minimized.

Copy link
Member

commented Oct 5, 2017

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

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Oct 5, 2017

Where did you see this? 🙈

@juliuste

This comment has been minimized.

Copy link
Member

commented Oct 23, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 23, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 24, 2017

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:

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

@kiliankoe

This comment has been minimized.

Copy link
Member

commented Oct 24, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 24, 2017

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.

@juliuste juliuste added this to the 1.0.0 milestone Oct 24, 2017

@kiliankoe

This comment has been minimized.

Copy link
Member

commented Oct 25, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 26, 2017

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

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Oct 26, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 28, 2017

I'd probably choose system.

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Oct 28, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 29, 2017

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

@kiliankoe

This comment has been minimized.

Copy link
Member

commented Oct 29, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Oct 29, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 30, 2017

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

This comment has been minimized.

Copy link
Member

commented Oct 30, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 12, 2017

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

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Nov 12, 2017

@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

This comment has been minimized.

Copy link
Member

commented Nov 13, 2017

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

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Nov 13, 2017

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

@juliuste

This comment has been minimized.

Copy link
Member

commented Nov 13, 2017

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

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Nov 15, 2017

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

This comment has been minimized.

Copy link
Member

commented Nov 17, 2017

We could mark the subMode field as reserved.

+1 Could you send a PR?

@juliuste

This comment has been minimized.

Copy link
Member

commented Nov 17, 2017

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

@juliuste

This comment has been minimized.

Copy link
Member

commented Nov 17, 2017

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

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Dec 11, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Dec 11, 2017

@kiliankoe are you ok with this?

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Dec 11, 2017

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

@kiliankoe

This comment has been minimized.

Copy link
Member

commented Dec 12, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Dec 12, 2017

water transport sounds good!

@juliuste

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

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

@derhuerst

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Dec 13, 2017

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

@kiliankoe

This comment has been minimized.

Copy link
Member

commented Dec 14, 2017

watercraft sounds great 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.