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

stopover type #35

Closed
juliuste opened this issue Mar 22, 2018 · 2 comments · Fixed by #40
Closed

stopover type #35

juliuste opened this issue Mar 22, 2018 · 2 comments · Fixed by #40
Milestone

Comments

@juliuste
Copy link
Member

juliuste commented Mar 22, 2018

Probably the most important feature FPTF is missing at the moment (IMHO) is the possibility to express departures and arrivals at a specific station (almost every public transport API has an interface for this).

I therefore propose a new type that could look like this (using fptf@1 keywords, disregarding the discussions in #27, #33 or #34 about possible changes in fptf@2 for now).

{
	type: 'stopover', // alternative proposals: 'arrival', 'departure', but this could be misleading since the accurate term in english would be "arrival or departure"
	station: '12345678', // station/stop object, required, name could be misleading since stops should also be valid. maybe 'halt' would be a better name - or two different keys "station" and "stop", but that's also probably not the best solution
	platform: '4-1', // string, optional
	arrival: '2017-03-17T15:00:00+02:00', // ISO 8601 string (with destination timezone), required if `departure` is null
	arrivalDelay: -45, // seconds relative to scheduled arrival, optional
	departure: '2017-03-16T20:00:00+01:00', // ISO 8601 string (with station/stop timezone), required if `arrival` is null
	departureDelay: 120, // seconds relative to scheduled departure, optional
	schedule: '1234', // schedule id or object
	mode: 'train', // see section on modes, overrides `schedule` mode
	subMode: , // reserved for future use, overrrides `schedule` subMode
	public: true, // publicly accessible?, overrides `schedule` public
	operator: 'sncf' // operator id or operator object, overrides `schedule` operator
}

Any opinions / further proposals?

@derhuerst
Copy link
Member

station: '12345678',

I'm in favour of stop, as it would be consistent with route.

`platform: '4-1',

Some means of transport, including some ferries and trains, have different platforms on arrival and on departure. Although I'm usually in favour of keeping things simple, in this case platform would convey something wrong essentially.

Therefore I'd propose departurePlatform and arrivalPlatform, which would be consistent with journey.

mode: 'train',

This should be required, right?

@juliuste
Copy link
Member Author

I'm in favour of stop, as it would be consistent with route.

Agreed.

Some means of transport, including some ferries and trains, have different platforms on arrival and on departure. Although I'm usually in favour of keeping things simple, in this case platform would convey something wrong essentially.

Therefore I'd propose departurePlatform and arrivalPlatform, which would be consistent with journey.

Agreed.

mode: 'train',

This should be required, right?

Agreed.

😄

@juliuste juliuste mentioned this issue Mar 27, 2018
7 tasks
@juliuste juliuste added this to the 2.0.0 milestone Jul 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants