GTFS 요구사항

파트너는 모든 표준 사양과 아래에 나열된 사양을 충족하는 GTFS 피드를 제공해야 합니다. 이 피드는 파트너가 표시하려는 모든 운항 일정을 포함해야 합니다. 이 정보를 제공하면 Google에 일정 및 경로 정보가 표시됩니다. 파트너는 원하는 경우 제공된 피드의 일부 또는 전체 숙박 일정에 대해 추가 가격 및 재고 정보를 노출할 수 있습니다.

기본 요구사항

정적 GTFS 참조 - 모든 기본 요구사항이 적용됩니다.

GTFS 권장사항 - 권장사항을 필수사항인 것처럼 따르세요.

GTFS 피드 업로드 - 이 절차에 따라 GTFS 피드를 업로드하세요.

업데이트: 피드가 업로드되면 여기에 설명된 절차에 따라 업데이트할 수 있습니다. 일반적으로 이러한 피드 업데이트가 완전히 전파되는 데 2~3일이 걸릴 수 있습니다.

추가 요구사항

범위

• 단일 GTFS 피드는 단일 국가 또는 국가의 일부를 포함해야 합니다. 국경을 넘는 여행은 별도의 대륙 전체 피드로 제공해야 합니다. GTFS 피드가 국가보다 큰 지역을 포함하는 경우 여행 교통팀에 문의하세요.
  • GTFS zip 파일 내 파일은 4GB 미만이어야 합니다. 이보다 큰 파일은 일반적으로 frequencies.txt 또는 유사한 기능에서 제공하는 압축 옵션을 무시하는 등 잘못된 관행을 나타냅니다. 이로 인해 처리 중에 문제가 발생할 수 있습니다. 4GB보다 큰 파일이 필요하다고 생각되면 [e-mail]의 Travel Transport팀에 문의하세요.
  • GTFS 피드 내 서비스의 전체 향후 운영 기간에 대한 데이터는 GTFS 데이터가 업데이트될 때마다 제공되어야 합니다. 서로 다른 기간별 서비스 분류는 허용되지 않습니다.
• 특정 운영자의 모든 날짜는 하나의 피드에 포함되어야 합니다.

번역

• translations.txt를 사용하여 번역을 제공할 수 있으며 다음 국가에서는 번역이 필요합니다.
  • 사용자에게 제공되는 정보는 다양한 스크립트 또는 라틴어 이외의 스크립트로 제공될 수 있습니다.
  • 사용자에게 제공되는 정보는 여러 언어로 제공될 수 있으며, 언어별로 다른 이름을 사용하는 항목 (예: 브뤼셀/브뤼셀/브뤼셀)이 있을 수 있습니다.
• 번역할 항목
  • 대행사/정류장/노선 이름
  • 운행/정류장 행선지

경로 이름, 이동 별칭, 행선지

• 모든 이동의 행선지는 trips.txt(이동 내내 행선지가 일관되게 유지되는 경우) 또는 stop_times.txt (이동의 여러 단계에서 행선지가 변경되는 경우)에 제공되어야 합니다.
• 안내판은 사용자가 지상에서 찾을 수 있는 정보와 일치해야 합니다. 예를 들어 차량이나 간판에 표시되는 행선지입니다.
• 경로에 이름이 있으면 routes.txt에서 long_name으로 제공해야 합니다.
• 경로에 해당 경로의 모든 이동과 양방향에 적용되는 특정 번호 또는 영숫자 식별자가 있는 경우 routes.txt의 short_name으로 제공해야 합니다.
• 노선 내 이동에 개별 식별자 (예: 기차 번호)가 있는 경우 이러한 식별자를 이동 짧은 이름으로 제공해야 합니다.
• 노선 번호나 이름이 없는 장거리 서비스의 경우 노선 이름을 선택하는 것이 문제가 됩니다. 이러한 상황에서 일반적인 가이드라인은 노선 이름과 행선지의 조합이 사용자가 차량을 명확하게 식별하는 데 도움이 되어야 한다는 것입니다. 예를 들어 운영 기관의 이름은 노선 이름으로 사용할 수 있으며, 차량에 표시되는 경우 이동의 목적지는 이동 행선지로 사용해야 합니다.

예

• 뭄바이에서 바라나시로 가는 인도 철도 카마야니 익스프레스 열차 11071 참고: 번호 11071은 경로 자체가 아닌 뭄바이에서 바라나시까지의 특정 기차 여행을 식별합니다.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• Chevallier Bus에서 운행하는 부에노스아이레스에서 코르도바로 가는 버스 참고: 이 서비스를 운영하는 버스에는 특정 노선 이름이 표시되지 않습니다. 대신 운영 대행사 이름과 목적지를 눈에 띄게 표시합니다. 이 특정 이동에는 동일한 기관에서 운영하거나 동일한 노선을 운행하는 다른 이동과 구분되는 개별 번호/식별자가 없습니다. 이 경우 'Chevallier'를 기관 이름 (agencies.txt)과 경로 긴 이름 (routes.txt)으로 모두 사용할 수 있습니다. 목적지는 행선지 표시에 사용해야 합니다. trip_short_name은 비어 있어야 합니다.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • headsign: Córdoba

중지 시간

arrival_time과 departure_time은 모두 stop_times.txt에 제공되어야 합니다.

여행 구조

• 여러 도시/지역을 운행하는 장거리 이동은 세그먼트 없이 엔드 투 엔드로 제공되어야 합니다 (예: A->B->C가 [A->B,A->C,B->C]가 아님). 여기서 A, B, C는 도시 지역입니다. 예를 들어 부에노스아이레스에서 코르도바로 이동하는 장거리 버스가 로사리오에 정차하는 경우 '부에노스아이레스 - 로사리오', '부에노스아이레스 - 코르도바', '로사리오 - 코르도바'의 세 가지 여정이 아닌 세 도시에서 정차하는 하나의 여정으로 표시해야 합니다.
• 데이터 제공업체가 올바른 이동경로 구조에 관한 정보를 얻을 수 없는 경우, 사례별로 도시 간 이동경로가 세분화되어 제공될 수 있습니다. 이러한 도시 간 이동에 도시 (도시 지역) 내에 여러 개의 탑승 또는 하차 지점이 있는 경우 정류장 간 세분화가 허용되지 않습니다. 모든 탑승 지점과 모든 하차 지점이 단일 여정에 나열되어야 합니다.

역 구조

플랫폼/베이가 여러 개인 대형 역의 경우 역-플랫폼 관계를 피드에 지정해야 하며, stops.txt의 platform_code 필드를 통해 특정 베이/플랫폼을 식별해야 합니다. 특정 베이 또는 플랫폼에서 일관되게 출발하거나 도착하는 차량은 GTFS 피드에서 해당 베이 또는 플랫폼에 연결해야 합니다. 출발일/시간에 따라 출발 또는 도착 승강장이나 정류장이 변경되는 경우 이 정보를 GTFS 실시간으로 제공할 수 있습니다.

역/정류장 위치

• 플랫폼이나 승강장이 여러 개인 대형 역의 경우 역의 위치는 가장 눈에 띄는 보행자 출입구 (역에 건물이나 구조물이 있는 경우) 또는 승객 대기 구역 (실외 역의 경우)의 위치로 설정해야 합니다.
• 길가에 있는 작은 정류장의 경우 식별할 수 있는 버스 기둥이 있으면 정류장 위치를 버스 기둥 위치로 설정해야 합니다. 특정 버스 기둥을 식별할 수 없는 경우 위치는 도로의 올바른 쪽에 배치해야 하며, 차량이 정차하는 실제 위치 (이상적으로는 10m 이내) 근처에 있어야 합니다.

추가 GTFS 확장

파트너 API를 구현하여 가격/재고 정보를 표시하려는 파트너에게만 필요합니다.

Google 대중교통 티켓 판매 확장

• 파트너는 GTFS 티켓 판매 확장 프로그램의 하위 집합인 Google 대중교통 티켓 판매 확장 프로그램 사양을 구현해야 합니다.
• 티켓팅 ID에는 다음 요구사항이 적용됩니다.
  • 티켓팅 ID는 안정적이어야 합니다 (즉, 타당한 이유가 있는 경우에만 드물게 변경 허용). 티켓팅 ID가 변경되는 경우 하위 호환성이 필요합니다 (최소 1주일 기간).
  • API 요청에서 SegmentKey의 매개변수를 확인하려면 ticketing_trip_id (trips.txt) 및 ticketing_stop_id (ticketing_identifiers.txt)가 필요합니다. stop_sequence의 대체는 안정적이지 않으므로 지원되지 않습니다.

GTFS-Fares v1

정적 GTFS 참조는 선택사항인 fare_attributes.txt 및 fare_rules.txt 파일을 지정합니다. 파트너가 파트너 API와 통합하는 경우 이러한 파일을 제공해서는 안 됩니다.