canceled trips & departures/arrivals #27

derhuerst · 2017-12-05T19:20:56Z

What should we do with them? Omit them from the results? Mark them as canceled?

kiliankoe · 2017-12-06T11:36:02Z

Omitting elements doesn't feel like the right approach. The goal should be to be as comprehensible instead of as minimal as possible imo.

A cancelled state seems like a good idea.

derhuerst · 2017-12-06T12:21:36Z

I'm in favour of marking them as canceled. But I also think that's not enough. Just like with realtime departures, we should incentivise people to handle canceled departures properly. We could additionally set departure/when to null.

derhuerst · 2017-12-06T18:35:42Z

Also, we need to pay attention to the spelling of cancel(l)ed.

derhuerst · 2017-12-08T14:27:29Z

from derhuerst/vbb-rest#19 (comment)

IMHO: I think that is an important information for everyone. One should be able to see it at a glance. I strongly suggest to show the key all the time.

juliuste · 2017-12-11T12:50:55Z

Cancel(l)ed state LGTM, I'm not sure if it would be wise to set the departure/when to null though, since that would take away useful information (e.g. if you want to know which train (at what time) actually had been cancel(l)ed).

derhuerst · 2018-02-28T20:03:28Z

From derhuerst/vbb-rest#26:

It seems, that the when field is null when a trip has been canceled.
If it is possible, it would be nice, if you'd provide the original time even if a trip is cancelled.

It would be easier in many situations to identify the cancelled trip.

I'm sorting the departures by time in my MagicMirror module and I really would like to show the cancelled trips in the module to inform the user about cancelled trips instead of removing them from the departures list (because there's no logical position for them if they have no departure time)...

deg0nz · 2018-02-28T22:15:51Z

I must say, that I really like the canceled flag. But as stated in the comment above, I have some problems with nulling the when field when a trip has been canceled.

Removing this time value forces me to sort these departures out entirely.

Also, please consider the behaviour of the "official" applications. When you use public transport apps, the canceled trips are still shown with their original departure times, but they provide a hint or the departures are crossed out (like BVG, DB apps do).
So even if the trip is canceled, the information still exists. IMHO the API should behave in a similar way. So I agree with @juliuste's comment above (#27 (comment))

But I also agree with @derhuerst when he says, that people should be incentivised to handle canceled departures properly.

Maybe you could null the when field per default and provide a flag on the request to provide the departure time in the response. This way the requestor is actually aware what data he'll be receiving. This could satisfy both sides.

But either way, I really think this data should be accessible somehow.

derhuerst · 2018-02-28T22:21:01Z

What about this?

{
  when: null,
  canceled: true,
  originalWhen: '2018-02-28T22:19:25.066Z'
}

pros:

prevents people from handling the data properly
allows people to show the time of the canceled dep

cons:

yet another field in the spec

deg0nz · 2018-02-28T22:31:18Z

This could be a good solution. Do you want to provide the originalWhen field all the time or only on canceled trips?

If you provide it all the time you should consider providing it without the delay delta.

derhuerst · 2018-02-28T23:46:56Z

Not sure yet. I think having it all the time would be confusing. Or at least we would need a better name than "original", because "original" might also be understood as "scheduled" (vs. realtime).

kiliankoe · 2018-03-01T08:24:32Z

one could make it a nested object getting more clarity in a complexity tradeoff :/

{
    when: null,
    status: {
        status: 'cancelled',
        originalWhen: '...'
    }
}

I would however also vote for a naming change instead of this monstrosity.

derhuerst · 2018-03-05T23:36:45Z

I propose a field formerWhen (see also former vs. previous), which contains the former realtime value.

deg0nz · 2018-03-06T10:24:46Z

I would also suggest to name the field something like scheduledWhen. But maybe formerWhen makes it more clear that we are dealing with a canceled departure. So I would agree to go with formerWhen.

derhuerst · 2018-03-06T11:55:33Z

Note that scheduledWhen is something different. A departure can be scheduled (aka planned) or prognosed (aka realtime). Additionally, it may have been canceled, which is why I picked "former" instead of "scheduled".

deg0nz · 2018-03-07T14:34:00Z

I'm aware of that, but as I understand the meaning of the word "scheduled" (when I translate it to german with "geplant"/"planmäßig"), a departure is still scheduled to a certain time even if it is canceled or delayed. Because it was originally scheduled to leave at this specific time. IMHO, the cancellation itself doesn't change anything to the original scheduled time, because the schedule itself is still valid, but with a cancelled departure.

Even the delay doesn't change anything about the actual scheduled time. It just changes the actual departure time.

But this is just my opinion...

If I think about it that way, one could change the response to something like that:

On a normal departure:

{
    when: <SCHEDULEDTIMESTAMP+120>,
    delay: 120,
    scheduled: <SCHEDULEDTIMESTAMP>
}

On a cancelled departure:

{
    when: null,
    delay: null,    // Or nonexistent for less data
    scheduled: <SCHEDULEDTIMESTAMP>,
    canceled: true
}

pros:

Maybe this approach could clarify the different meanings of the different times without any more explanation to the format itself.
And since we are talking about departures in any case of this data, the words "scheduled" and "when" would be clear enough IMO.

cons:

more data on a normal request
still one more field in the spec

As I said, this is just my opinion on this. I would also be fine with a formerWhen field. :)

Edit: It could also be the case, that I'm missing something here...

derhuerst · 2018-03-07T14:40:09Z

I'm aware of that, but as I understand the meaning of the word "scheduled" (when I translate it to german with "geplant"/"planmäßig"), a departure is still scheduled to a certain time even if it is canceled or delayed. Because it was originally scheduled to leave at this specific time. IMHO, the cancellation itself doesn't change anything to the original scheduled time, beacuse the schedule itself is still valid, but with a cancelled departure.

Apparently there's been a misunderstanding. I trying to make the point that "scheduled" wouldn't be the correct name for the former when, because the former when has been a realtime value (not a scheduled point in time).

But, thinking about it, it might make sense to, if a departure has been cancelled, expose the scheduled departure, because the former realtime departure is irrelevant anyways. 👍

So, my new proposal:

{
  when: null,
  canceled: true,
  formerScheduledWhen: '...'
}

deg0nz · 2018-03-07T16:52:49Z

Ok, then I really didn't get your point ^^'

This sounds good to me. I'd say formerScheduledWhen would work fine.

see public-transport/friendly-public-transport-format#27

Comig with public-transport/hafas-client@7ce65ca and was discussed in public-transport/friendly-public-transport-format#27

juliuste · 2018-03-17T11:39:39Z

(Sorry that it took me so long to respond)

What about delay information when a trip is canceled? IMHO that information should be kept as well. Would make more sense to call it formerWhen + delay then again, though 😄

And (different topic) from what I understand, the canceled field should be required for every journey to make things clearer, right?

derhuerst · 2018-03-17T11:49:51Z

What about delay information when a trip is canceled? IMHO that information should be kept as well. Would make more sense to call it formerWhen + delay then again, though 😄

Not sure if the former delay is that relevant. After all, the departure/trip has been cancelled.

(I know arguing with what the status quo is like is not a very strong argument, but) Whenever I see cancelled departures in current signage systems, the former delay isn't being shown anymore.

And (different topic) from what I understand, the canceled field should be required for every journey to make things clearer, right?

I'm fine with that.

juliuste · 2018-03-17T11:51:48Z

Not sure if the former delay is that relevant. After all, the departure/trip has been cancelled.

For example when recording which trains have been canceled, there might be a correlation with the "former" delay (Trains that are really late might be more likely to be canceled) which IMHO makes this a relevant information.

derhuerst · 2018-03-17T11:53:38Z

I consider this a niche use case. Because we may not even have this information, I'm against adding formerDelay as a required field.

juliuste · 2018-03-17T11:56:30Z

I consider this a niche use case. Because we may not even have this information, I'm against adding formerDelay as a required field.

I never wanted the field to be required 😄 I agree that one might not have this information, after all even the delay information on regular journeys isn't required right now. But why not make it an optional field?

derhuerst · 2018-03-17T12:47:53Z

Okay, then I misunderstood you.

I'm fine with making it optional. I'm just not sure if it's necessary. Shall I add it to #31?

juliuste · 2018-03-17T12:53:17Z

Please note that instead of formerScheduledWhen we would have formerWhen (+ optional formerDelay) then.

Shall I add it to #31?

Yes 🙂

derhuerst · 2018-03-17T13:03:47Z

Please note that instead of formerScheduledWhen we would have formerWhen (+ optional formerDelay) then.

Okay, I'm against that. 😛 As I said above, I think it is more relevant to expose the former scheduled departure/arrival.

That aside, I've already built it into hafas-client and deployed among the APIs, so your proposal would be a breaking change there.

juliuste · 2018-03-17T13:09:29Z

I don't get your point. Either you have delay information on the canceled route, then my proposal is not a problem (?). Or you don't have it, but calculating the raw formerScheduledWhen is also impossible then, right? Because if you have the "normal" when, you need to to scheduledWhen = when - delay to calculate it?

That aside, I've already built it into hafas-client and deployed among the APIs, so your proposal would be a breaking change there.

I don't think this decision should depend on hafas-clients implementation 😛 (Especially since there's a breaking change coming with hafas-client#33 anyways 😄)

derhuerst · 2018-03-17T13:14:48Z

I don't think this decision should depend on hafas-clients implementation 😛

Even though hafas-client should not dictate choices made here, it is another argument (aside that I think it is a counter-intuitive proposal) against changing formerScheduledWhen.

To make it clear: Why not add formerDelay as an optional field?

derhuerst · 2018-03-17T13:19:36Z

[just a sarcastic side note]

Why I think having the delay on cancelled departures (by default) is counter-intuitive. 😛

https://mobile.twitter.com/BahnAnsagen/status/974380477040775170/photo/1

juliuste · 2018-03-17T13:20:10Z

I feel like this is inconsistent. We should either use scheduledWhen + delay in non-canceled routes as well, or use formerWhen and delay in canceled routes. Why use the scheduled keyword here and not everywhere?

deg0nz · 2018-03-17T14:53:41Z

@juliuste Has a point here...

juliuste · 2018-03-17T15:01:55Z

@derhuerst and I just had a long discussion about this, I tried my best to summarize our proposal in #33

Since #33 would introduce a breaking change, I'm fine if @derhuerst wants to add his current proposal (formerScheduledWhen) to fptf@1 since modules like hafas-client apparently already work this way.

For fptf@2 #33 seems to be a more elegant solution, though 🙂

timaschew · 2018-08-09T15:03:51Z

a bit related to #44

derhuerst mentioned this issue Dec 8, 2017

Cancelled trips derhuerst/vbb-rest#19

Closed

derhuerst mentioned this issue Dec 25, 2017

never-ending todo list public-transport/hafas-client#9

Open

15 tasks

derhuerst mentioned this issue Feb 28, 2018

Missing when on cancelled trips derhuerst/vbb-rest#26

Closed

derhuerst added a commit to public-transport/hafas-client that referenced this issue Mar 8, 2018

departures, journeys: canceled, former scheduled time

7ce65ca

see public-transport/friendly-public-transport-format#27

deg0nz added a commit to deg0nz/MMM-PublicTransportBerlin that referenced this issue Mar 12, 2018

Made preparation for future feature of canceled trips

229b5e9

Comig with public-transport/hafas-client@7ce65ca and was discussed in public-transport/friendly-public-transport-format#27

derhuerst mentioned this issue Mar 14, 2018

specify cancelled departures/arrivals #31

Closed

juliuste mentioned this issue Mar 17, 2018

expressing realtime / scheduled time data #33

Closed

This was referenced Mar 22, 2018

stopover type #35

Closed

fptf 2.0.0 checklist #37

Open

juliuste added this to the 2.0.0 milestone Jul 27, 2018

derhuerst mentioned this issue Sep 26, 2018

Two canceled properties public-transport/hafas-client#82

Closed

juliuste mentioned this issue Oct 26, 2018

trips, schedules and legs in fptf 2 #61

Open

derhuerst mentioned this issue Aug 18, 2021

Sometimes departure is missing resulting in ftpf-invalid data public-transport/hafas-client#243

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

canceled trips & departures/arrivals #27

canceled trips & departures/arrivals #27

derhuerst commented Dec 5, 2017

kiliankoe commented Dec 6, 2017

derhuerst commented Dec 6, 2017

derhuerst commented Dec 6, 2017

derhuerst commented Dec 8, 2017 •

edited

Loading

juliuste commented Dec 11, 2017

derhuerst commented Feb 28, 2018

deg0nz commented Feb 28, 2018 •

edited

Loading

derhuerst commented Feb 28, 2018

deg0nz commented Feb 28, 2018

derhuerst commented Feb 28, 2018

kiliankoe commented Mar 1, 2018

derhuerst commented Mar 5, 2018

deg0nz commented Mar 6, 2018

derhuerst commented Mar 6, 2018

deg0nz commented Mar 7, 2018 •

edited

Loading

derhuerst commented Mar 7, 2018

deg0nz commented Mar 7, 2018 •

edited

Loading

juliuste commented Mar 17, 2018 •

edited

Loading

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018 •

edited

Loading

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018 •

edited

Loading

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018 •

edited

Loading

derhuerst commented Mar 17, 2018

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018

deg0nz commented Mar 17, 2018

juliuste commented Mar 17, 2018

timaschew commented Aug 9, 2018

canceled trips & departures/arrivals #27

canceled trips & departures/arrivals #27

Comments

derhuerst commented Dec 5, 2017

kiliankoe commented Dec 6, 2017

derhuerst commented Dec 6, 2017

derhuerst commented Dec 6, 2017

derhuerst commented Dec 8, 2017 • edited Loading

juliuste commented Dec 11, 2017

derhuerst commented Feb 28, 2018

deg0nz commented Feb 28, 2018 • edited Loading

derhuerst commented Feb 28, 2018

deg0nz commented Feb 28, 2018

derhuerst commented Feb 28, 2018

kiliankoe commented Mar 1, 2018

derhuerst commented Mar 5, 2018

deg0nz commented Mar 6, 2018

derhuerst commented Mar 6, 2018

deg0nz commented Mar 7, 2018 • edited Loading

derhuerst commented Mar 7, 2018

deg0nz commented Mar 7, 2018 • edited Loading

juliuste commented Mar 17, 2018 • edited Loading

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018 • edited Loading

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018 • edited Loading

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018 • edited Loading

derhuerst commented Mar 17, 2018

derhuerst commented Mar 17, 2018

juliuste commented Mar 17, 2018

deg0nz commented Mar 17, 2018

juliuste commented Mar 17, 2018

timaschew commented Aug 9, 2018

derhuerst commented Dec 8, 2017 •

edited

Loading

deg0nz commented Feb 28, 2018 •

edited

Loading

deg0nz commented Mar 7, 2018 •

edited

Loading

deg0nz commented Mar 7, 2018 •

edited

Loading

juliuste commented Mar 17, 2018 •

edited

Loading

juliuste commented Mar 17, 2018 •

edited

Loading

juliuste commented Mar 17, 2018 •

edited

Loading

juliuste commented Mar 17, 2018 •

edited

Loading