콘텐츠로 이동

GTFS Realtime에 새 필드 추가

생산자 또는 소비자가 GTFS Realtime 사양에 새 필드를 추가하는 데 관심이 있는 경우 제안된 필드를 설명하는 GTFS Realtime GitHub 저장소 에서 새 문제를 열고 GTFS 에서 이 새 필드(문제에 대한 링크 포함)를 발표해야 합니다. 실시간 메일링 리스트 .

사양 수정 프로세스

  1. 프로토콜 정의, 사양 및 문서 파일(번역 제외)의 모든 관련 부분을 업데이트하여 git 분기를 만듭니다.
  2. https://github.com/google/transit 에서 풀 요청을 생성합니다. 풀 요청에는 패치에 대한 자세한 설명이 포함되어야 합니다. 풀 리퀘스트를 만든 사람이 옹호자 가 됩니다.
  3. 끌어오기 요청이 등록되면 지지자가 GTFS Realtime 메일링 리스트 에 알려야 합니다. 발표되면 풀 요청은 제안으로 간주됩니다.
  4. 제안에 대한 논의는 다음과 같습니다. 풀 요청 댓글은 유일한 토론 포럼으로 사용해야 합니다.
    • 토론은 옹호자가 필요하다고 느끼는 기간 동안 지속되지만 최소 7일 이상이어야 합니다.
    • 지지자는 동의한 의견을 기반으로 제안서(예: 풀 요청)를 적시에 업데이트할 책임이 있습니다.
    • 어느 시점에서시간 옹호자는 제안이 포기되었다고 주장할 수 있습니다.
  5. 옹호자는 토론에 필요한 초기 7일 간격 이후 언제든지 제안 버전에 대한 투표를 요청할 수 있습니다.
    • 투표를 요청하기 전에 최소한 한 명의 GTFS-realtime 제작자와 한 명의 GTFS-realtime 소비자가 제안된 변경 사항을 구현해야 합니다. GTFS-realtime 생산자는 공개 GTFS-realtime 피드의 변경 사항을 포함하고 끌어오기 요청 댓글 내에서 해당 데이터에 대한 링크를 제공하며 GTFS-realtime 소비자는 링크를 제공할 것으로 예상됩니다. 풀 리퀘스트에서 사소한 방식으로 변경 사항을 활용하는(즉, 새로운 기능이나 개선된 기능을 지원하는) 애플리케이션에 대한 설명입니다.
    • 투표를 요청할 때 옹호자는 투표가 해당 필드를 사양에 공식 채택하기 위한 것인지 아니면 실험적 필드를 위한 것인지 명확하게 명시해야 합니다.
  6. 투표는 7일(역일 기준) 및 5일(스위스 영업일 기준)을 포괄하기에 충분한 최소 기간 동안 지속됩니다. 투표는 23:59:59 UTC에 종료됩니다.
    • 지지자는 투표 시작 시 특정 종료 시간을 발표해야 합니다.
    • 투표 기간 동안 제안서의 편집 변경만 허용됩니다(오타, 문구는 의미를 변경하지 않는 한 변경될 수 있음).
    • 누구나 풀 리퀘스트에 댓글 형식으로 예/아니오 투표를 할 수 있으며 투표 기간이 끝날 때까지 투표를 변경할 수 있습니다. 유권자가 자신의 투표를 변경하는 경우 투표를 취소하고 새 투표를 작성하여 원래 투표 댓글을 업데이트하여 변경하는 것이 좋습니다.
    • 투표 기간이 시작되기 전의 투표는 고려되지 않습니다.
  7. 제안은 최소 3표 이상 찬성으로 만장일치로 승인되면 수락됩니다.
    • 제안자의 투표는 총 3표에 포함되지 않습니다. 예를 들어 제안자 X가 풀 요청을 생성하고 찬성 투표를 하고 사용자 Y와 Z가 찬성 투표하면 총 2개의 찬성 투표로 계산됩니다.
    • 반대 투표는 동기를 부여해야 하며 이상적으로는 실행 가능한 피드백을 제공해야 합니다.
    • 투표가 실패하면 옹호자는 제안에 대한 작업을 계속하거나 제안을 포기하도록 선택할 수 있습니다. 옹호자의 결정은 메일링 리스트에 발표되어야 합니다.
    • 지지자가 제안 작업을 계속하면 언제든지 새로운 투표가 요구될 수 있습니다.
  8. 30일 동안 비활성 상태로 남아 있는 풀 요청은 종료됩니다. 풀 요청이 종료되면 해당 제안은 포기된 것으로 간주됩니다. 옹호자는 대화를 계속하거나 유지하려는 경우 언제든지 풀 요청을 다시 열 수 있습니다.
    • 지지자는 공식 사양의 일부가 아닌 사용자 정의 확장 으로 기능을 구현하도록 선택할 수 있습니다.
  9. 제안이 수락된 경우:
    • Google은 풀 요청의 투표 버전을 병합하기 위해 최선을 다하고 있습니다(기여자가 CLA 에 서명하고 영업일 기준 5일 이내에 풀 요청을 수행하는 경우).
    • Google은 https://github.com/google/gtfs-realtime-bindings 저장소를 적시에 업데이트하기 위해 최선을 다하고 있습니다. 제안의 결과인 gtfs-realtime-bindings에 대한 커밋은 제안의 풀 요청을 참조해야 합니다.
    • 번역은 원본 풀 요청에 포함되어서는 안 됩니다. Google은 궁극적으로 관련 번역을 지원되는 언어로 업데이트할 책임이 있지만 커뮤니티의 순수 번역 풀 요청을 환영하며 모든 편집 의견이 처리되는 즉시 수락됩니다.

실험 분야

  1. 커뮤니티가 (a) 제안된 필드가 유용하다고 생각하고 (b) 필드 유형 (optional vs repeated , string vs int vs bool )에 합의할 수 있는 경우 GTFS Realtime 메시지에 필드 번호가 할당됩니다. 그리고 .proto 파일 과 설명서에 이것이 실험적인 분야이며 향후 변경될 수 있다는 메모가 작성될 것입니다.
    • 합의는 아래의 사양 수정 프로세스 와 동일한 토론 및 투표 프로세스를 통해 이루어지지만 만장일치 동의 대신 승인을 위해 80%의 찬성 투표만 필요합니다.
    • 새로운 실험적 필드를 사용하려는 GTFS Realtime 생산자와 소비자는 새 필드가 있는 .proto 파일을 사용하여 라이브러리를 다시 생성하고(예: Google에서 gtfs-realtime-bindings 라이브러리 업데이트) 필드를 채우고 파싱하기 시작합니다. 라이브 데이터로.
    • 실험 필드가 가치 있고 생산자와 소비자 모두 필드를 사용하고 있다고 만족하면 아래 사양 수정 프로세스 에 따라 해당 필드를 사양에 공식적으로 추가합니다.
    • 실험 분야로 승인된 후 2년 이내에 사양 수정 프로세스 를 통해 실험 분야가 채택되지 않으면 .proto 파일 파일의 필드 값 옆에 [deprecated=true] 를 추가하여 더 이상 사용되지 않습니다. RESERVED 대신 [deprecated=true] 를 사용하면 이미 필드를 채택한 생산자와 소비자가 사용에서 제거할 필요가 없습니다. 또한 사양 수정 프로세스 에 따른 후속 투표에서 승인되면(예: 추가 생산자 및/또는 소비자가 필드를 사용하기 시작할 때) 필드는 향후 "사용되지 않음"이 될 수 있습니다.
  2. 새 필드가 단일 생산자에게 특정한 것으로 간주되거나 데이터 유형에 대한 분쟁이 있는 경우 생산자가 자신의 피드에서 필드를 사용할 수 있도록 사용자 정의 확장 을 할당합니다. 가능하면 우리는 확장을 피하고 소비자가 사양에 대한 다양한 확장을 지원하기 위해 단편화 및 추가 작업을 피하기 위해 많은 기관에 유용한 필드를 기본 사양에 추가해야 합니다.

지침 원칙

GTFS Realtime의 원래 비전을 보존하기 위해 사양을 확장할 때 고려해야 할 여러 지침 원칙이 설정되었습니다.


피드는 실시간으로 생산하고 소비하기에 효율적이어야 합니다.

실시간 정보는 반드시 효율적인 처리가 필요한 연속적이고 동적인 데이터 스트림입니다. 프로토콜 버퍼는 개발자의 사용 용이성과 데이터 전송 효율성 측면에서 좋은 절충안을 제공하기 때문에 프로토콜 버퍼를 사양의 기반으로 선택했습니다. GTFS와 달리 많은 에이전시가 GTFS Realtime 피드를 직접 편집할 것이라고는 생각하지 않습니다. 프로토콜 버퍼 선택은 대부분의 GTFS Realtime 피드가 프로그래밍 방식으로 생성 및 소비된다는 결론을 반영합니다.


사양은 승객 정보에 관한 것입니다.

이전의 GTFS와 마찬가지로 GTFS Realtime은 주로 승객 정보와 관련이 있습니다. 즉, 사양에는 무엇보다도 라이더를 위한 전동 공구에 도움이 될 수 있는 정보가 포함되어야 합니다. 대중 교통 기관이 시스템 간에 내부적으로 전송하기를 원할 수 있는 잠재적으로 많은 양의 운영 지향 정보가 있습니다. GTFS Realtime은 이러한 목적을 위한 것이 아니며 더 적절할 수 있는 잠재적으로 다른 운영 지향 데이터 표준이 있습니다.


사양에 대한 변경 사항은 이전 버전과 호환되어야 합니다.

사양에 기능을 추가할 때 기존 피드를 무효화하는 변경을 피하고 싶습니다. 피드에 기능을 추가하기 전까지는 기존 피드 게시자를 위해 더 많은 작업을 생성하고 싶지 않습니다. 또한 가능할 때마다 기존 파서가 새 피드의 이전 부분을 계속 읽을 수 있기를 바랍니다. 프로토콜 버퍼를 확장하기 위한 규칙은 어느 정도 이전 버전과의 호환성을 강화합니다. 그러나 이전 버전과의 호환성을 깨뜨릴 수 있는 기존 필드에 대한 의미 체계 변경을 피하고자 합니다.


투기 기능은 사용하지 않는 것이 좋습니다.

모든 새 기능은 피드 생성 및 읽기에 복잡성을 추가합니다. 따라서 유용하다고 알려진 기능만 추가하도록 주의를 기울이고자 합니다. 이상적으로는 새로운 기능을 사용하는 실제 교통 시스템에 대한 데이터를 생성하고 이를 읽고 표시하는 소프트웨어를 작성하여 모든 제안을 테스트했습니다.

개정 내역

2020년 3월 12일

  • GTFS Realtime 참조 페이지에서 TripDescriptor 설명을 업데이트했습니다.

2015년 2월 26일

  • TripDescriptor 에 실험 필드 direction_id 를 추가했습니다( 토론 ).

2015년 1월 30일

  • 아직 없는 모든 나머지 GTFS 실시간 메시지(예: FeedMessage 및 FeedEntity )에 프로토콜 버퍼 확장 네임스페이스를 추가했습니다.

2015년 1월 28일

  • TripUpdate 에 실험 필드 delay 을 추가했습니다( 토론 ).

2015년 1월 16일

  • TripDescriptor.start_time 의 설명을 업데이트합니다.

2015년 1월 8일

  • 정의된 실험 열거형 OccupancyStatus .
  • VehiclePosition ( 토론 )에 실험 필드 occupancy_status 를 추가했습니다.

2014년 5월 22일

  • StopTimeUpdate 메시지의 ScheduleRelationship 열거형에 대한 설명이 업데이트되었습니다( 토론 ).
  • TripDescriptor 메시지의 ScheduleRelationship enum 값에서 REPLACEMENT를 제거했습니다( 토론 ).

2012년 10월 12일

  • TripUpdate 메시지에 타임스탬프 필드를 추가했습니다.

2012년 5월 30일

  • 사양에 대한 확장에 대한 특정 세부 정보를 추가했습니다.

2011년 11월 30일

  • 사양에 대한 쓰기 확장을 용이하게 하기 위해 주요 GTFS 실시간 메시지에 프로토콜 버퍼 확장 네임스페이스를 추가했습니다.

2011년 10월 25일

  • alert , header_text 및 description_text 가 모두 일반 텍스트 값임을 명확히 하기 위해 설명서가 업데이트되었습니다.

2011년 8월 20일

  • TimeRange 메시지의 의미 체계를 명확히 하기 위해 문서를 업데이트했습니다.

2011년 8월 22일

  • 초기 버전.