HU: live departures are shown for offline BKK lines

[gy-mate]

Live departures are shown for all BKK lines in Budapest—even for those that don't have any live passenger information system connected to them, like the ones below:

• M1: https://api.transitous.org/?tripId=20251022_10%3A17_hu-bkk_C7522020
• M2: https://api.transitous.org/?tripId=20251022_10%3A13_hu-bkk_C98308539
• M3: https://api.transitous.org/?tripId=20251022_10%3A00_hu-bkk_C97750469
• M4: https://api.transitous.org/?tripId=20251022_10%3A19_hu-bkk_C98050467
• D14: https://api.transitous.org/?tripId=20251022_10%3A33_hu-bkk_C0418320

Issue moved from motis-project/motis#1103.

[jbruechert]

To debug this, you can have a look at the raw data in the feed.

If there is no actual delay info in there for these trips, but MOTIS still displays it as on-time, that is something specific you can report there.

https://transitous.org/doc/#realtime-data_1

[gy-mate]

This is the data for https://api.transitous.org/?tripId=20251023_12%3A23_hu-bkk_D00838381 in the feed:

entity {
  id: "TripUpdate-20251023_BKK_D00838381"
  trip_update {
    trip {
      trip_id: "D00838381"
      start_date: "20251023"
      schedule_relationship: SCHEDULED
      route_id: "5400"
    }
    stop_time_update {
      stop_sequence: 0
      arrival {
        time: 1761214980
        uncertainty: 100
      }
      departure {
        time: 1761214980
        uncertainty: 100
      }
      stop_id: "056216"
    }
    stop_time_update {
      stop_sequence: 1
      arrival {
        time: 1761215081
        uncertainty: 100
      }
      departure {
        time: 1761215081
        uncertainty: 100
      }
      stop_id: "056218"
    }
    stop_time_update {
      stop_sequence: 2
      arrival {
        time: 1761215210
        uncertainty: 100
      }
      departure {
        time: 1761215210
        uncertainty: 100
      }
      stop_id: "056220"
    }
    stop_time_update {
      stop_sequence: 3
      arrival {
        time: 1761215283
        uncertainty: 100
      }
      departure {
        time: 1761215283
        uncertainty: 100
      }
      stop_id: "056222"
    }
    stop_time_update {
      stop_sequence: 4
      arrival {
        time: 1761215381
        uncertainty: 100
      }
      departure {
        time: 1761215381
        uncertainty: 100
      }
      stop_id: "056224"
    }
    stop_time_update {
      stop_sequence: 5
      arrival {
        time: 1761215452
        uncertainty: 100
      }
      departure {
        time: 1761215452
        uncertainty: 100
      }
      stop_id: "056226"
    }
    stop_time_update {
      stop_sequence: 6
      arrival {
        time: 1761215533
        uncertainty: 100
      }
      departure {
        time: 1761215533
        uncertainty: 100
      }
      stop_id: "056228"
    }
    stop_time_update {
      stop_sequence: 7
      arrival {
        time: 1761215629
        uncertainty: 100
      }
      departure {
        time: 1761215629
        uncertainty: 100
      }
      stop_id: "056230"
    }
    stop_time_update {
      stop_sequence: 8
      arrival {
        time: 1761215704
        uncertainty: 100
      }
      departure {
        time: 1761215704
        uncertainty: 100
      }
      stop_id: "056232"
    }
    stop_time_update {
      stop_sequence: 9
      arrival {
        time: 1761215770
        uncertainty: 100
      }
      departure {
        time: 1761215770
        uncertainty: 100
      }
      stop_id: "056234"
    }
    vehicle {
      wheelchair_accessible: WHEELCHAIR_ACCESSIBLE
    }
    timestamp: 1761211394
    trip_properties {
      shape_id: "X485"
    }
  }
}

So it contains data for the trip, but all times have an uncertainty of 100. From what I see, only those times that have an uncertainty of 0 are the real-time ones.

[felixguendling]

That's not how uncertainty is specified. A value of 100 has no special meaning and is still considered realtime.

If you want to give the consumer (MOTIS in this case) the information that no data is available at a stop, StopTimeUpdate.schedule_relationship = NO_DATA would be correct. There's no value in having a trip update with all stops set to NO_DATA. In this case, I would recommend to remove this trip update completely from the feed.

We will soon implement for StopTimeUpdate.schedule_relationship = NO_DATA in MOTIS.

[gy-mate]

Thanks, I sent an email to the GTFS-RT feed operator including this information.

They are investigating the issue.