Last minute outages by regional operators (NEB)

[timaschew]

Since I live on country side and going to work in Berlin I need take the RB35 which belongs to NEB which is also a member in the VBB.

I would love to see delay or at least outage for this line, but even VBB app is not showing this information except it's a planned construction work.

They have several lines in Brandenburg and currently they have just some alert boxed on their landing page for important notes: some examples:

• https://web.archive.org/web/20171022003839/http://www.neb.de/
• https://web.archive.org/web/20171030102231/http://www.neb.de/
• https://web.archive.org/web/20171022003839/http://www.neb.de/
• https://web.archive.org/web/20170818142020/http://www.neb.de/
• https://web.archive.org/web/20180513091449/http://www.neb.de/

And this seems to be for planned changes: https://web.archive.org/web/20171030102231/http://www.neb.de/

And here is the proof that VBB is not showing these changes (even outage) up in their result:

So I guess because their regional they don't use their own HAFAS, that's also the reason why they have a form on their page, but it's redirecting to VBB.

Let's imagine I can convince them to publish additionally something more machine readable for the outages. What would be the perfect format? Does GTFS fits for that just use case, especially if they don't have anything similar to HAFAS?

Personally, for me a RSS feed or a file with a content like this would be enough:

outages: [
  {
    line: RB63,
    start: 2018-09-09T00:00:00 
    end: 2018-09-09T:11:00:00
    reason: operational
    link: http://www.neb.de/service/fahrplanaenderungen/details/eberswalde-joachimsthal/
  }
]

What do you think?

[timaschew]

Of course we should use/add IDs of the GTFS, so the output would more look like that:

"outages": [
  {
    "scope: "DE_VBB" // does it make sense here or at all?
    "agency_id": "596", // this could be optional, since the important identifier is route_id, but on the other site: do we need a scope for the VBB, see line above?
    "agency_name": "NEB Betriebsgesellschaft mbH", // optional as well
    "lines": [
      {
        "route_id": "16919_100",
        "route_short_name": "RB63", // optional
        "start": "2018-09-09T00:00:00",
        "end": "2018-09-09T:11:00:00",
        "reason": "operational",
        "substitute": "bus", // optional (should be english version of german 'Ersatzverkehr')
        "info": "http://www.neb.de/service/fahrplanaenderungen/details/eberswalde-joachimsthal/" // optional
    ]
  }
]

[derhuerst]

IMO The perfect format would be GTFS Realtime service alerts. GTFS-RT, as the de-facto standard for realtime public transport info, is widely supported by various tools.

[timaschew]

That sounds promising, thanks!

So it would look like this then:

# header information
header {
  # version of speed specification. Currently "2.0"
  gtfs_realtime_version: "2.0"

  # determines whether dataset is incremental or full
  incrementality: FULL_DATASET

  # the time where this dataset was generated on server
  # for determining the sequence of alert feeds
  timestamp: 1536422400
}
# multiple entities can be included in the feed
entity {
  # unique identifier for the entity
  id: "0"

  # "type" of the entity
  alert {
    # multiple periods can be defined when alert is active
    active_period {
      # start time in POSIX epoch format
      start: 1536444000
      # end time in POSIX epoch format
      end: 1536483600
    }
    # selects which GTFS entities will be affected
    informed_entity {
      # valid parameters: 
      # agency_id, route_id, route_type, stop_id, trip (see TripDescriptor)
      route_id: "16919_100"
    }
    # multiple selectors (informed_entity) can be given
    informed_entity {
      agency_id: "596
    }

    # cause of the alert - see gtfs-realtime.proto for valid values
    cause: OTHER_CAUSE
    # effect of the alert - see gtfs-realtime.proto for valid values
    effect: NO_SERVICE

    # the given url provides additional information
    url {
      # multiple languages/translations supported
      translation {
        # page hosted outside of Google (at provider/agency, etc.)
        text: "http://www.neb.de/service/fahrplanaenderungen/details/eberswalde-joachimsthal/"
        language: "de"
      }
    }

    # header for the alert will be highlighted
    header_text {
      # multiple languages/translations supported
      translation {
        text: "Busnotverkehr"
        language: "de"
      }
    }

    # Alert description. Additional info to the header text
    description_text {
      # multiple languages/translations supported
      translation {
        text: "Busnotverkehr - Zugausfall - Wir bitten um Entschuldigung"
        language: "de"
      }
    }
  }
}

I have still some questions:

• Should this date be sent by NEB to VBB?
  • This means VBB needs to integrate those last minute updates into their results, what if they cannot do that (yet)?
• Or should NEB provide (host) this alert on their own namespace/domain? So not just VBB, instead everyone can consume this alert.

A general question, it's not only related to alerts also to the GTFS dataset itself. It seems that data (stops, trips, routes) belong to an agency. And a agency has a ID, but in which context this ID is unique? Just to the VBB dataset? That means multiple datasets cannot be merged due to ID possible conflicts?

[derhuerst]

Theoretically, it makes sense for the entity/agency that publishes GTFS Static to also publish GTFS Realtime. This is in order to keep the IDs consistent.

But in practice, I'm afraid that VBB lacks the skill to merge multiple realtime feeds into one GTFS-RT feed. So if we could get an NEB feed, that would already be an improvement, especially for you and your commute situation.

[timaschew]

Okay, that's exactly what I was assuming.

I'm also afraid that NEB can provide the information in the GTFS format. So I just created a simple HTML form, they can use it locally and just copy and paste the output to somewhere (of course they need to merge multiple alerts manually).

BTW: was is entity in the alert feed, it's the entity of the alerts itself right? Actually I just want to ensure that I got it right which value I use for the entity id: this part

# multiple entities can be included in the feed
entity {
  # unique identifier for the entity
  id: "0"

In my form I just use a combinatino of route_id and start date. Here is the HTML page: https://gist.github.com/timaschew/496994f0f86a29753881d230509e6bd3

Rendered HTML: https://rawgit.com/timaschew/496994f0f86a29753881d230509e6bd3/raw/e503e9cb8f457a633222d9882c95231b11b70689/neb-alert-feed.html

Ah, another question according the german translations of the cause and effect:

Does it make sense to you?

<option value="UNKNOWN_CAUSE">unbekannter Grund</option>
<option value="OTHER_CAUSE">sonstiger Grund</option>
<option value="TECHNICAL_PROBLEM">Technische Störung</option>
<option value="STRIKE">Streik</option>
<option value="DEMONSTRATION">Demonstration</option>
<option value="ACCIDENT">Unfall</option>
<option value="HOLIDAY">Urlaub</option>
<option value="WEATHER">Wetter</option>
<option value="MAINTENANCE">Wartung</option>
<option value="CONSTRUCTION">Bauarbeiten</option>
<option value="POLICE_ACTIVITY">Polizeieinsatz</option>
<option value="MEDICAL_EMERGENCY">Notfall</option>

<option value="NO_SERVICE">kein Verkehr</option>
<option value="REDUCED_SERVICE">Eingeschränkter Verkehr</option>
<option value="SIGNIFICANT_DELAYS">Signifikate Verspätung</option>
<option value="DETOUR">Umleitung</option>
<option value="ADDITIONAL_SERVICE">zusätzlicher Vekehr</option>
<option value="MODIFIED_SERVICE">geänderter Verkehr</option>
<option value="OTHER_EFFECT">sonstige Auswirkung</option>
<option value="UNKNOWN_EFFECT">unbekannte Auswirkung</option>
<option value="STOP_MOVED">geänderte Haltestelle</option>

I also not sure which value to use for "Schienenersatzverkehr", which means that there is no service for the train but there bus route/transfer as substitute.

[timaschew]

Found this page: https://support.google.com/transitpartners/answer/6374472?hl=en&ref_topic=6159819

So my first guess to use MODIFIED_SERVICE for "Schienenersatzverkehr" was wrong. This case is not covered and I guess we need to use NO_SERVICE for the original route.

Also this page on google is also available in german, so I will pick the translations from there

[derhuerst]

Ah, another question according the german translations of the cause and effect: Does it make sense to you? [...]

Yup, looks good.

I also not sure which value to use for "Schienenersatzverkehr", which means that there is no service for the train but there bus route/transfer as substitute.

I've seen "rail replacement service" a few time so far.

[timaschew]

Ah maybe DETOUR fits for "Schienenersatzverkehr"

[derhuerst]

Don't think so. "detour" sounds as if an existing, scheduled vehicle would stop add different/additional stops. "Schienenersatzverkehr" usually is an entirely different vehicle, often with a different schedule.

BTW: We once discussed that we should standardise a field that indicates the fact that a trip/vehicle is part of replacement service.

[timaschew]

I've seen "rail replacement service" a few time so far.

Ah, so the GTFS protobuf is doesn't support it yet? So, we need to define a constant for it, which hopefully will be integrated to GTFS realtime?

BTW: We once discussed that we should standardise a field that indicates the fact that a trip/vehicle is part of replacement service.

I think that is exactly what you're said, but how exactly can we do that?

[derhuerst]

I've seen "rail replacement service" a few time so far.

Ah, so the GTFS protobuf is doesn't support it yet? So, we need to define a constant for it, which hopefully will be integrated to GTFS realtime?

Ah, so you were talking about the appropriate term that is part of GTFS-RT. Didn't get that.

In this case: Pick the closest term from GTFS-RT, getting a term integrated is too much work.

We once discussed that we should standardise a field that indicates the fact that a trip/vehicle is part of replacement service.

I think that is exactly what you're said, but how exactly can we do that?

I was talking about standardising this field in FPTF.

[timaschew]

I was talking about standardising this field in FPTF.

Alright, I think we can use something not to specific, so IMHO replacement service sounds good to me.

But I wonder how would you identify this type of effect from a GTFS-RT entity if it doesn't support it itself? By matching the header or description?

Maybe I got something wrong, but almost all (raw) data comes from GTFS, right?
So there is no agency or operator (btw: what is the difference?) which provides FPTF directly, right?

[derhuerst]

But I wonder how would you identify this type of effect from a GTFS-RT entity if it doesn't support it itself? By matching the header or description?

That's a tough problem. I'd say that ADDITIONAL_SERVICE corresponds closely to the concept of "replacement service". We might want to map them 1-to-1.

Maybe I got something wrong, but almost all (raw) data comes from GTFS, right? So there is no agency or operator (btw: what is the difference?) which provides FPTF directly, right?

Depends whom you're talking about. Seen globally, a lot of data currently comes from (semi-)proprietary APIs and is being translated into standardised/well-known formats by the community. It's very rare that a public transportation agency/authority publishes data as GTFS-RT by itself.

On the other hand, the idea of the standard is that they will eventually do exactly that by themselves: publish clean GTFS-RT feeds.

[timaschew]

ADDITIONAL_SERVICE

More trips are running than normal, for example due to a sporting event.

from that description it doesn't sound like it's a different route, to me it sounds like the route has just more trips for the same route. I would say it's as close as DETOUR to the replacement service ;)

[derhuerst]

I will close this, as it is not directly related to FPTF. Would be great if you let us know when you find out about an NEB/VBB GTFS-RT feed (or a realtime feed in any other format)!

If you want to add the "is replacement service" field to FPTF please reopen.