콘텐츠로 이동

Trip Updates

여행 업데이트는 시간표의 변동을 나타냅니다. 실시간으로 예약한 모든 여행에 대한 여행 업데이트를 받을 수 있습니다. 이러한 업데이트는 경로를 따라 정류장에 대한 예상 도착 또는 출발 시간을 제공합니다. 여행 업데이트는 여행이 취소되거나 일정에 추가되거나 경로가 변경되는 보다 복잡한 시나리오를 제공할 수도 있습니다.

알림: GTFS 에서 이동은 특정 시간에 발생하는 두 번 이상의 경유지 시퀀스입니다.

예정된 각 여행에 대해 최대 하나의 여행 업데이트가 있어야 합니다. 예정된 여행에 대한 여행 업데이트가 없는 경우 해당 여행에 대한 실시간 데이터가 없는 것으로 간주됩니다. 데이터 소비자는 여행이 정시에 진행되고 있다고 가정해서는 안 됩니다.

차량이 동일한 블록 내에서 여러 이동을 제공하는 경우(이동 및 블록에 대한 자세한 내용은 GTFS trips.txt 참조):

  • 피드에는TripUpdate 위해여행 현재 서비스 중인차량 . 생산자는 현재 이후 하나 이상의 여행에 대해 TripUpdates를 포함하는 것이 좋습니다.여행 이것에차량 생산자가 이러한 미래에 대한 예측의 품질을 확신하는 경우 의 블록여행 (에스). 동일한 항목에 대한 여러 TripUpdate 포함차량 라이더에 대한 예측 "팝인"을 방지합니다.차량 하나에서 전환여행 하류 여행에 영향을 미치는 지연에 대해 라이더에게 사전 통지합니다(예: 알려진지연 여행 사이에 예정된 경유 시간을 초과함).
  • 각각의TripUpdate 엔터티는 필요하지 않습니다.추가 같은 순서로 피드에예정 블록에서. 예를 들어 trip_ids 가 1, 2, 3인 여행이 있고 모두 하나의 블록에 속하는 경우차량 여행기여행 1, 그럼여행 2, 그리고 나서여행 3,trip_update 엔티티는 임의의 순서로 나타날 수 있습니다(예: 추가여행 2, 그럼여행 1, 그리고 나서여행 3이 허용됩니다.

StopTimeUpdate

이동 업데이트는 StopTimeUpdates 라고 하는 차량 정차 시간에 대한 하나 이상의 업데이트로 구성됩니다. 과거 및 미래의 정지 시간에 대해 제공될 수 있습니다. 정지 시간을 지나서 취소할 수 있지만 필수는 아닙니다. 생산자는 주어진 여행에 대해 미래에 예정된 도착 시간이 있는 정류장을 참조하는 경우(예: 차량이 일정보다 앞서 정류장을 통과한 경우) 과거 StopTimeUpdate 를 삭제해서는 안 됩니다. 이 정류장.

예를 들어 GTFS-rt 피드에 다음 데이터가 표시되는 경우:

  • 정류장 4 - 오전 10시 18분 예상 (오전 10시 20분 예정 - 2분 일찍)
  • 정류장 5 – 오전 10시 30분 예상 (오전 10시 30분 예정 – 정시)

...버스가 실제로 오전 10시 18분에 정류장을 통과하더라도 오전 10시 21분까지는 피드에서 4번 정류장에 대한 예측을 삭제할 수 없습니다. 정류장 4에 대한 StopTimeUpdate 가 오전 10:18 또는 오전 10:19에 피드에서 삭제되고 예정된 도착 시간이 오전 10:20인 경우 소비자는 해당 시간에 정류장 4에 대한 실시간 정보가 존재하지 않는다고 가정해야 합니다. GTFS의 일정 데이터를 사용해야 합니다.

각 StopTimeUpdate 는 정류장에 연결됩니다. 일반적으로 이것은 GTFS stop_sequence 또는 GTFS stop_id를 사용하여 수행할 수 있습니다. 그러나 GTFS trip_id 없이 여행에 대한 업데이트를 제공하는 경우 stop_sequence에 값이 없으므로 stop_id를 지정해야 합니다. stop_id는 여전히 GTFS에서 stop_id를 참조해야 합니다. 여행에서 동일한 stop_id를 두 번 이상 방문한 경우 해당 여행에서 해당 stop_id에 대한 모든 StopTimeUpdates에 stop_sequence를 제공해야 합니다.

업데이트는 StopTimeEvent 를 사용하여 StopTimeUpdates 의 정류장 도착 및/또는 출발 에 대한 정확한 시간을 제공할 수 있습니다. 여기에는 절대 시간 또는 지연 (예: 초 단위로 예정된 시간의 오프셋)이 포함되어야 합니다. 지연은 여행 업데이트가 빈도 기반 여행과 달리 예정된 GTFS 여행을 참조하는 경우에만 사용할 수 있습니다. 이 경우 시간은 예약된 시간 + 지연 시간과 같아야 합니다. StopTimeEvent 와 함께 예측의 uncertainty 을 지정할 수도 있습니다. 이에 대해서는 페이지 아래의 Uncertainty 섹션에서 자세히 설명합니다.

각 StopTimeUpdate 에 대해 기본 일정 관계는 예약 됩니다. (이는 여행 일정 관계와 다릅니다). 정류장이 정차하지 않는 경우 건너뛰기 로 변경하거나 일부 여행에 대한 실시간 데이터만 있는 경우 데이터 없음 으로 변경할 수 있습니다.

업데이트는 stop_sequence(또는 여행에서 발생한 순서대로 stop_id)별로 정렬해야 합니다 .

이동 중에 하나 이상의 경유지가 누락된 경우 업데이트로 인한 delay (또는 업데이트에 time 만 제공된 경우 시간을 GTFS 일정 time 과 비교하여 계산된 지연)이 모든 후속 경유지에 전파됩니다. 즉, 특정 정류장의 정류장 시간을 업데이트하면 다른 정보가 없을 때 모든 후속 정류장이 변경됩니다. SKIPPED 일정 관계가 있는 업데이트는 지연 전파를 중지하지 않지만 SCHEDULED (일정 관계가 제공되지 않은 경우 기본값) 또는 NO_DATA 일정 관계가 있는 업데이트는 중지합니다.

예 1

20개의 정류장이 있는 이동의 경우 현재 정류장의 stop_sequence에 대한 도착 지연 및 출발 지연이 0( StopTimeEvents )인 StopTimeUpdate 는 이동이 정시에 정확히 있음을 의미합니다.

예 2

동일한 이동 인스턴스에 대해 세 가지 StopTimeUpdate 가 제공됩니다.

  • stop_sequence 3에 대한 300초 지연
  • stop_sequence 8에 대한 60초 지연
  • stop_sequence 10에 대한 NO_DATA 의 ScheduleRelationship 관계

이는 다음과 같이 해석됩니다.

  • stop_sequences 1,2에는 알 수 없는 지연이 있습니다.
  • stop_sequences 3,4,5,6,7의 지연 시간은 300초입니다.
  • stop_sequences 8,9의 지연 시간은 60초입니다.
  • stop_sequences 10,..,20에는 알 수 없는 지연이 있습니다.

TripDescriptor

TripDescriptor에서 제공하는 정보는 업데이트 중인 여행의 일정 관계에 따라 다릅니다. 설정할 수 있는 여러 가지 옵션이 있습니다.

값 논평
Scheduled 이 이동은 GTFS 일정에 따라 실행 중이거나 여전히 연결할 수 있을 만큼 가깝습니다.
Added 이 여행은 예정되지 않았으며 추가되었습니다. 예를 들어, 수요에 대처하거나 고장난 차량을 교체하기 위해.
Unscheduled 이 이동은 실행 중이며 일정과 연결되지 않습니다. 예를 들어 일정이 없고 버스가 셔틀 서비스로 운행되는 경우입니다.
Canceled 이 여행은 예정되어 있었지만 지금은 삭제되었습니다.
Duplicated 이 새 여행은 서비스 시작 날짜 및 시간을 제외하고 정적 GTFS에 있는 기존 여행의 사본입니다. 새 여행은 TripProperties에 지정된 서비스 날짜 및 시간에 실행됩니다.

대부분의 경우 이 업데이트와 관련된 GTFS의 예정된 여행의 trip_id를 제공해야 합니다.

trip_id가 반복되는 시스템

반복적인 trip_id를 사용하는 시스템의 경우(예: frequencies.txt를 사용하여 모델링된 여행, 즉 빈도 기반 여행) trip_id 자체는 특정 시간 구성 요소가 없기 때문에 단일 여정의 고유 식별자가 아닙니다. TripDescriptor 내에서 이러한 여행을 고유하게 식별하려면 세 가지 식별자를 제공해야 합니다.

  • trip_id
  • start_time
  • start_date

start_time은 먼저 게시되어야 하며 후속 피드 업데이트는 동일한 여정을 참조할 때 동일한 start_time을 사용해야 합니다. StopTimeUpdates는 조정을 나타내는 데 사용해야 합니다. start_time은 첫 번째 역의 출발 시간과 정확히 일치할 필요는 없지만 그 시간과 매우 유사해야 합니다.

예를 들어 2015년 5월 25일 10:00에 trip_id=T인 여행이 start_time=10:10:00에 시작하기로 결정하고 10:01에 실시간 피드를 통해 이 정보를 제공한다고 가정해 보겠습니다. 10시 5분쯤 우리는 여행이 10시 10분이 아니라 10시 13분에 시작된다는 것을 갑자기 알게 됩니다. 새로운 실시간 피드에서 여전히 이 여행을 식별할 수 있지만(T, 2015-05-25, 10:10:00) 첫 번째 정류장에서 출발하는 StopTimeUpdate를 10:13:00에 제공합니다.

대체 여행 매칭

빈도 기반이 아닌 여행은 다음 조합을 포함하여 aTripDescriptor에 의해 고유하게 식별될 수도 있습니다.

  • route_id
  • direction_id
  • start_time
  • start_date

여기서 start_time은 제공된 ID 조합이 고유한 이동으로 확인되는 한 정적 일정에 정의된 예정된 시작 시간입니다.

Uncertainty

Uncertainty은 StopTimeUpdate 의 시간과 지연 값 모두에 적용됩니다. Uncertainty은 실제 지연의 예상 오류를 초 단위의 정수로 대략적으로 지정합니다(그러나 정확한 통계적 의미는 아직 정의되지 않음). 예를 들어 컴퓨터 타이밍 제어 하에 운행되는 열차의 경우 uncertainty이 0이 될 수 있습니다.

예를 들어 4분의 오류 창(즉, +2/-2분) 내에 다음 정류장에 도착하는 데 15분의 지연이 예상되는 장거리 버스의 uncertainty 값은 240입니다.