使用 RProtoBuf 读取传输数据会产生 S3 方法错误

Question

我目前正在 R 中处理来自 WMATA 和 Arlington Regional Transit 的 GTFS 文件。使用 R 的目的是为了 Shiny；否则就会使用Python。我对静态文件没有任何问题（目前使用 tidytransit pkg），但作为新的协议缓冲区用户，我正在努力处理实时文件（我花了几个小时尝试解码 R 中的二进制输出，如果有的话）指示）。

我使用 httr2 从 WMATA 中提取实时行程更新，并将响应存储在 .pb 文件中。我使用 readProtoFiles 读取默认的 GTFS 原型文件，描述符显示正常。我尝试了以下方法：

mb_trip <- read-methods("transit_realtime.TripUpdate", "update.pb")[["timestamp"]]

.S3methods（generic.function，class，envir，dropPath = dropPath）中的错误： 没有函数“transit_realtime.TripUpdate”可见

[编辑：下面的代码块最初具有 --decode_raw 输出。它现在包含带有原型结构的解码输出的一部分，如评论中所述。]

header {
  gtfs_realtime_version: "2.0"
  incrementality: FULL_DATASET
  timestamp: 1709699913
}
entity {
  id: "23564020"
  trip_update {
    trip {
      trip_id: "23564020"
      start_date: "20240306"
      route_id: "16A"
    }
    stop_time_update {
      stop_sequence: 2
      departure {
        time: 1709701200
      }
      stop_id: "13524"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 3
      arrival {
        time: 1709701392
      }
      stop_id: "3625"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 4
      arrival {
        time: 1709701408
      }
      stop_id: "3641"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 5
      arrival {
        time: 1709701448
      }
      stop_id: "3680"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 6
      arrival {
        time: 1709701475
      }
      stop_id: "3696"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 7
      arrival {
        time: 1709701557
      }
      stop_id: "3858"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 8
      arrival {
        time: 1709701626
      }
      stop_id: "28172"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 10
      arrival {
        time: 1709701729
      }
      stop_id: "3727"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 11
      arrival {
        time: 1709701893
      }
      stop_id: "3581"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 12
      arrival {
        time: 1709701957
      }
      stop_id: "3534"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 13
      arrival {
        time: 1709702003
      }
      stop_id: "3507"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 14
      arrival {
        time: 1709702101
      }
      stop_id: "3429"
      schedule_relationship: SCHEDULED
    }
    stop_time_update {
      stop_sequence: 15
      arrival {
        time: 1709702176

我的理解是，这些数字应该与静态 GTFS 文件中的键匹配（我在某处读过此内容，但现在找不到来源）。第一个括号指的是 GTFS 版本（2.0）、增量和时间戳。之后您看到的是 Metrobus T18 的行程更新。

[旁注：我知道 R 有一个 WMATA 包，但我的理解是 GTFS 数据比 REST API 更新。另外，GTFS 是 ART 的唯一选择。]

我查看了原型结构的文档。我按照 this thread 上的答案进行操作，但无法完全复制，因为悉尼数据出现 404（无法获取 GTFS 原型）。 pb 数据是否需要包含与原型相同的标头？解码后的 Sydney .pb 文件似乎与我的 WMATA 数据具有相同的结构（即没有标头，只有 ID）。在调用 RProtoBuf::read-methods 之前我需要对 API 数据做些什么吗？

Answer 1

出于某种原因，这里使用

transit_realtime.TripUpdate$read("update.pb")

而不是

read-methods("transit_realtime.TripUpdate", "update.pb")

有效。我不完全理解后台发生的事情（并且尝试回溯不会产生任何结果），并且我仍然有一些方法可以实际解析数据，但我提出的原始问题已得到解答。