GTFS 권장사항

핵심 GTFS

일반 대중교통 피드 사양(GTFS)의 대중교통 서비스를 설명하기 위한 권장사항입니다. 이러한 권장사항은 GTFS 권장사항 실무 그룹 구성원의 경험과 애플리케이션별 GTFS 권장사항을 종합한 것입니다. 자세한 내용은 자주 묻는 질문(FAQ)을 참고하세요.

문서 구성

권장사항은 다음과 같은 3가지 기본 섹션으로 구성됩니다.

자주 묻는 질문(FAQ)

이러한 GTFS 권장사항이 중요한 이유가 무엇인가요?

GTFS 권장사항의 목표는 다음과 같습니다.

  • 대중교통 앱의 최종 사용자 고객 환경 개선
  • 소프트웨어 개발자가 손쉽게 애플리케이션, 제품, 서비스를 배포하고 확장할 수 있도록 광범위한 데이터 상호 운용성 지원
  • 본래 목적인 이동 계획 이외에 다양한 애플리케이션 카테고리에서 GTFS 사용 촉진

조율된 GTFS 권장사항을 채택하지 않는 경우, GTFS를 사용하는 애플리케이션에서 조율되지 않은 방식으로 요건 및 기대치를 설정할 수 있으므로 요건과 애플리케이션별 데이터 세트가 서로 달라지고 상호 운용성이 감소할 수 있습니다. 권장사항이 제공되기 전에는 올바른 형식의 GTFS 데이터를 구성하는 항목이 모호하고 서로 충돌하는 부분이 많았습니다.

GTFS 권장사항은 어떤 과정을 거쳐서 누가 작성했나요?

이러한 권장사항은 앱 공급자, 데이터 소비자, 대중교통 제공업체, GTFS에 광범위하게 참여하는 컨설턴트 등 GTFS에 관여하는 17개 기관의 실무 그룹에 의해 개발되었습니다. 실무 그룹은 Rocky Mountain Institute에 의해 소집되어 도움을 주었습니다.

각 권장사항은 실무 그룹 구성원의 투표를 받았으며 대부분의 권장사항이 만장일치로 승인되었습니다. 일부 소수 권장사항은 대부분의 조직에 의해 승인되었습니다.

GTFS 참조를 변경만 하면 안 되는 이유가 무엇인가요?

좋은 질문입니다. 사양, 데이터 사용량, 요구사항을 검토하는 과정에서 일부 변경이 필요한 사양을 발견했습니다( GitHub의 종료된 pull 요청 참고 ). 사양 참조 개정안은 권장사항보다 더욱 높은 기준의 철저한 검토와 비판이 적용됩니다. 그러나 여전히 명확한 일련의 권장사항 추천과 일치해야 합니다.

실무 그룹에서는 일부 GTFS 권장사항이 결과적으로 핵심 GTFS 참조의 일부가 될 것으로 예상하고 있습니다.

GTFS 검사 도구에서 이러한 권장사항을 준수하는지 확인하나요?

검사 도구에서는 현재 모든 권장사항 준수 여부를 확인하지 않습니다. 다양한 검사 도구에서 일부 권장사항 준수 여부를 확인할 수 있습니다. GTFS 검사 도구의 목록은 피드 테스트를 참고하세요. 이 권장사항을 참조하는 GTFS 검사 도구를 개발하는 경우 gtfs@rmi.org로 이메일을 보내주세요.

대중교통 기관의 담당자입니다. 소프트웨어 서비스 제공업체 및 공급업체가 이러한 권장사항을 따르게 하려면 어떻게 해야 하나요?

귀하의 공급업체 또는 소프트웨어 서비스 제공업체가 권장사항에 대해 알아보도록 하세요. GTFS 제작 소프트웨어 조달 시 GTFS 권장사항 URL과 핵심 사양 참조를 참고하는 것이 좋습니다.

GTFS 데이터 피드가 이러한 권장사항을 준수하지 않는 것으로 확인되면 어떻게 해야 하나요?

feed_info.txt제안된 feed_contact_email 또는 feed_contact_url 필드가 있는 경우 이를 사용하거나 대중교통 기관이나 피드 제작자 웹사이트에서 연락처 정보를 찾아 피드의 연락처를 확인하세요. 해당 문제를 피드 제작자에게 전달 시 관련 GTFS 권장사항의 링크를 제공하세요. 이 문서에 연결하기를 참고하세요.

권장사항 수정 또는 추가를 제안하려면 어떻게 해야 하나요?

gtfs@rmi.org로 이메일을 보내거나 GitHub GTFS 권장사항 저장소에서 문제 또는 pull 요청을 여세요.

어떻게 참여할 수 있나요?

gtfs@rmi.org로 이메일을 보내주세요.

데이터 세트 게시 및 일반 권장사항

일반 권장사항
데이터 세트는 zip 파일 이름을 포함해 공개 영구 URL로 게시해야 합니다(예: www.agency.org/gtfs/gtfs.zip). 파일에 액세스하기 위해 로그인할 필요 없이 URL을 직접 다운로드할 수 있도록 하여 소프트웨어 애플리케이션 사용을 통한 다운로드를 촉진하는 것이 가장 좋습니다. GTFS 데이터 세트를 공개적으로 다운로드할 수 있도록 만드는 것이 가장 일반적이고 권장되는 방법이지만, 데이터 제공업체가 라이선스 또는 기타 이유로 GTFS에 대한 액세스를 제어해야 하는 경우 API 키를 통해 GTFS 데이터 세트에 대한 액세스를 제어하는 것이 좋습니다. 이렇게 하면 자동 다운로드를 더욱 쉽게 구현할 수 있습니다.
GTFS 데이터는 안정적인 위치에서 파일 하나에 대중교통 기관의 서비스 관련 최신 공식 설명이 포함되도록 반복적으로 게시됩니다.
가능하다면 데이터 반복 과정 전체에서 stop_id, route_id, agency_id의 영구 식별자(ID 필드)가 유지되게 하세요.
하나의 GTFS 데이터 세트에 현재 및 향후 서비스('병합' 데이터 세트라고도 함)가 포함되어야 합니다. Google transitfeed 도구의 병합 함수를 사용하면 서로 다른 두 개의 GTFS 피드에서 가져와 병합한 데이터 세트를 만들 수 있습니다.
  • 어떤 경우든 게시된 GTFS 데이터 세트의 유효기간은 향후 7일 이상이어야 합니다. 운영자가 확신하는 일정의 기간과 유효기간이 일치하면 가장 좋습니다.
  • 가능한 경우 GTFS 데이터 세트는 향후 30일 이상의 서비스 기간에 적용되어야 합니다.
피드에서 오래된 서비스(만료된 캘린더)를 삭제하세요.
서비스 수정이 7일 이내에 적용되는 경우 정적 GTFS 데이터 세트가 아닌 GTFS-realtime 피드(서비스 권고 또는 이동경로 업데이트)를 통해 서비스 변경사항을 알리세요.
GTFS 데이터를 호스팅하는 웹 서버는 올바르게 파일 수정 날짜를 보고할 수 있도록 구성되어야 합니다(섹션 14.29의 HTTP/1.1 - Request for Comments 2616 참고).

파일별로 정리된 권장사항 추천

이 섹션에서는 GTFS 참조에 맞게 파일 및 필드별로 정리된 권장사항을 보여줍니다.

모든 파일

필드 이름 권장사항 추천
대소문자 혼용 모든 고객 대면용 텍스트 문자열(예: 경유지 이름, 경로 이름, 표지판)에서는 대소문자를 혼용(일부만 대문자로 처리)해야 합니다. 화면에서 소문자를 표시할 수 있으면 장소 이름의 대소문자 사용에 대한 현지 규칙을 따르세요.
예:
Brighton Churchill Square
Villiers-sur-Marne
Market Street
약어 장소 이름이 약어(예: 'JFK Airport')인 경우가 아니면 이름 및 기타 텍스트에 약어를 사용하지 마세요(예: Street 대신에 St.를 사용하면 안 됨). 약어를 사용하면 스크린 리더 소프트웨어와 음성 사용자 인터페이스의 접근성 기능이 제대로 작동하지 않을 수 있습니다. 소프트웨어를 사용하면 안전하게 전체 단어를 약어로 변환하도록 구성할 수 있지만, 약어를 전체 단어로 변환하는 경우에는 오류가 발생할 위험이 커집니다.

agency.txt

필드 이름 권장사항 추천
agency_id 피드에 기관이 하나만 있는 경우에도 포함되어야 합니다. routes.txtfare_attributes.txtagency_id를 포함하기 위한 권장사항 추천도 참고하세요.
agency_lang 포함되어야 합니다.
agency_phone 고객 서비스 전화가 없는 경우를 제외하고 포함되어야 합니다.
agency_email 고객 서비스 이메일이 없는 경우를 제외하고 포함되어야 합니다.
agency_fare_url 기관에서 운임을 완전히 무료로 제공하는 경우를 제외하고 포함되어야 합니다.

예:

  • 버스 서비스는 여러 소규모 버스 기관에서 운영합니다. 하지만 일정 예약 및 티켓 판매를 담당하며 사용자의 관점에서 버스 서비스를 담당하는 하나의 대형 기관이 있습니다. 해당 대형 기관이 피드 내에서 기관으로 정의되어야 합니다. 데이터가 서로 다른 작은 버스 운영자에 의해 내부적으로 분할된 경우에도 피드에 정의된 기관은 하나여야 합니다.
  • 피드 제공업체에서 티켓 판매 포털을 운영하지만, 실제로 서비스를 운영하고 사용자에 의해 책임이 있다고 알려진 다양한 기관이 있습니다. 실제로 서비스를 운영하는 기관이 피드 내에서 기관으로 정의되어야 합니다.

stops.txt

필드 이름 권장사항 추천
stop_id 다양한 물리적 위치에 있는 정류장(즉, 지정된 경로에 있는 차량이 정차할 정확한 위치가 서로 다르게 지정되어 있음. 표지판, 쉼터 또는 기타 공개 정보로 구분됨. 서로 가까이 있더라도 다른 길모퉁이에 위치해 있거나 승강장 또는 버스 정류장 등 다른 탑승 시설을 나타냄)의 stop_id는 서로 달라야 합니다.
stop_id는 내부 ID이며 승객에게 표시되지 않습니다.
데이터 반복 과정 전체에서 동일한 정류장에 대해 stop_id를 일관적으로 사용하세요 (데이터 세트 게시 및 일반 권장사항 참고).
stop_name stop_name은 정류장, 역 또는 탑승 시설에 대한 기관의 공개 이름(예: 시간표에 인쇄되어 있거나, 온라인에 게시되어 있거나, 해당 위치에 표시되어 있는 이름)과 일치해야 합니다.
게시된 정류장 이름이 없는 경우에는 피드 전반에서 일관된 정류장 이름 지정 규칙을 따르세요.
일반적으로 약어로 지칭되는 장소가 아니면 약어를 사용하지 마세요. 모든 파일에 나온 약어(#2) 섹션을 참고하세요.
모든 고객 대면 텍스트 필드에 대한 권장사항에 따라, 대소문자가 혼용되고 현지 규칙을 준수하는 정류장 이름을 제공하세요.
기본적으로 stop_name에는 '역' 또는 '정류장'과 같은 일반적인 단어 또는 중복되는 단어가 포함되면 안 됩니다(일부 예외적인 사례는 허용됨).
  • 실제로 이름의 일부인 경우(예: 유니언역, 중앙역)
  • stop_name이 너무 일반적인 경우(예: 도시 이름). '역', '터미널' 또는 다른 단어를 추가하여 의미를 명확하게 나타내세요.
stop_latstop_lon 정류장 위치는 최대한 정확해야 합니다. 정류장 위치와 실제 정차 위치를 비교할 때 오차가 4미터 이상 발생하면 안 됩니다.
정차 위치가 인도에서 승객이 탑승하는 위치와 매우 가까워야 합니다(실제 도로상의 통행 방향과 일치해야 함).
정류장 위치가 여러 데이터에서 공유되는 경우(두 기관에서 동일한 정류장/탑승 시설을 사용하는 경우)에는 두 정류장 모두에 동일한 stop_latstop_lon을 사용하여 해당 정류장이 공유되고 있음을 나타내세요.
stop_code 승객 대면 정류장 번호 또는 짧은 식별자가 있는 경우 GTFS에 stop_code가 포함되어야 합니다.
parent_stationlocation_type 다양한 역 또는 터미널에 여러 탑승 시설이 있으며, 교통수단에 따라 버스 정류장, 승강장, 부두, 탑승구 등 각기 다른 용어로 불립니다. 이러한 경우 피드 제작자는 역, 탑승 시설(하위 정류장이라고도 함), 관련성을 설명해야 합니다.
  • 역 또는 터미널은 stops.txt에서 location_type = 1을 이용해 레코드로 정의해야 합니다.
  • 각 탑승 시설은 location_type = 0을 이용해 정류장으로 정의해야 합니다 . parent_station 필드는 탑승 시설이 있는 역의 stop_id를 참조해야 합니다.
역 및 하위 정류장의 이름을 지정하는 경우 탑승자에게 널리 알려져 있는 이름으로 설정하면 탑승자가 역과 탑승 시설(버스 정류장, 승강장, 부두, 탑승구 등)을 파악하는 데 도움이 됩니다.
상위 역 이름 하위 정류장 이름
시카고 유니언역 시카고 유니언역 19번 승강장
샌프란시스코 페리 터미널 빌딩 샌프란시스코 페리 터미널 빌딩 E번 탑승구
시내 대중교통 센터 시내 대중교터 센터 B 구역

routes.txt

필드 이름 권장사항 추천
agency_id agency.txt에 정의된 경우 포함되어야 합니다.
route_short_name 간단한 서비스 지정 정보가 있는 경우 route_short_name을 포함하세요. 승객에게 널리 알려진 서비스의 이름이어야 하며 12자(영문 기준) 이하여야 합니다.
route_long_name 사양 참조에 명시된 정의: 일반적으로 route_short_name보다 자세히 설명하는 이름이며, 경로의 목적지나 정류장을 포함하기도 합니다. route_short_name 또는 route_long_name을 하나 이상 지정하세요. 가능하면 둘 다 지정하는 것이 좋습니다. 경로에 긴 이름이 없으면 route_short_name을 지정한 후 이 필드의 값으로 빈 문자열을 사용하세요.

다음은 긴 이름의 예입니다.

기본 여행 경로 또는 여정
경로 이름 양식 기관
'N'/'Judah' route_short_name/
route_long_name
Muni, 샌프란시스코
'6'/'ML King Jr Blvd' route_short_name/
route_long_name
TriMet, 오리건주 포틀랜드
'6'/'Nation - Étoile' route_short_name/
route_long_name
RATP, 프랑스 파리
'U2'/ 'Pankow – Ruhleben' route_short_name/
route_long_name
BVG, 독일 베를린
서비스 설명
'하트웰 지역 셔틀 버스'
route_long_name에는 route_short_name이 포함되면 안 됩니다.
route_long_name의 내용을 입력할 때 서비스 ID 등 전체 지정 정보를 포함하세요. 예:
서비스 ID 권장사항 추천
'MAX 경전철'
TriMet, 오리건주 포틀랜드
route_long_name에는 브랜드(MAX) 및 특정 경로 지정이 포함되어야 합니다. 'MAX 빨간색 노선'
'MAX 파란색 노선'
'Rapid Ride'
ABQ Ride, 뉴멕시코주 앨버커키
route_long_name에는 브랜드(Rapid Ride) 및 구체적인 경로 지정 정보가 포함되어야 합니다. 'Rapid Ride 빨간색 노선'
'Rapid Ride 파란색 노선'
route_id 이름이 지정된 경로 상의 모든 이동은 동일한 route_id를 참조해야 합니다.
  • 경로의 방향이 다르더라도 서로 다른 route_id 값으로 분리하면 안 됩니다.
  • 경로의 운행 기간이 다르더라도 서로 다른 route_id 값으로 분리하면 안 됩니다. 즉, '시내행(오전)' 및 '시내행(오후)' 서비스의 routes.txt에 여러 레코드를 만들지 않습니다.
경로 그룹에 이름이 다르게 지정된 분기형 경로(예: 1A 및 1B)가 포함되어 있는 경우 분기형 경로 사례의 권장사항 추천에 따라 route_short_nameroute_long_name을 정하세요.
route_colorroute_text_color 표지판, 인쇄물, 온라인 고객 정보와 일치해야 하며, 다른 곳에서 사용되지 않는 경우에는 포함하지 않습니다.

trips.txt

  • 순환 경로에 대한 특수 사례 참고: 순환 경로는 동일한 정류장에서 이동이 시작되고 끝나는 경로를 의미하며, 서로 다른 두 개의 터미널을 갖는 선형 경로와는 반대됩니다. 순환 경로는 특정 관행을 따라 설명되어야 합니다. 순환 경로 사례 참고하기
  • 올가미형 경로에 대한 특수 사례 참고: 올가미형 경로는 선형 및 고리 기하학적 구조를 합친 경로로, 차량이 일부 경로에 대해서만 순환 경로로 진행합니다. 올가미형 경로는 특정 관행을 따라 설명되어야 합니다. 올가미형 경로 사례 참고하기
필드 이름 권장사항 추천
trip_headsign trip_headsign 또는 stop_headsign 필드에 경로 이름(route_short_nameroute_long_name과 일치)을 제공하지 않습니다.
경로의 여러 이동을 구분하는 데 사용할 수 있으며 차량의 행선 표지판에 표시된 목적지, 경로 또는 기타 이동 지정 텍스트를 포함해야 합니다. 차량에 표시된 경로 정보와의 일관성을 유지하는 것이 GTFS 데이터 세트에 제공되는 행선지를 결정하는 기본이자 우선시되는 목표입니다. 이 기본 목표와 충돌하지 않는 경우에만 기타 정보를 포함해야 합니다. 이동 중에 행선지가 바뀌는 경우 trip_headsign에 우선하여 stop_times.stop_headsign을 적용하세요. 다음은 일부 사례를 위한 권장사항입니다.
example_table:
경로 설명 권장사항 추천
2A. 목적지만 목적지(예: 'Transit Center', 'Portland City Center' 또는 'Janzen Beach')를 제공하세요.
2B. 경유지가 있는 목적지 <목적지>(<경유지> 경유) '하이게이트(채링 크로스 경유)'. 차량이 이러한 경유지를 지나친 후에 승객에게 보여지는 행선 표지판에서 경유지가 삭제되는 경우 stop_times.stop_headsign을 사용하여 업데이트된 행선지를 설정합니다.
2C. 지역 정류장이 있는 지역별 장소 이름 목적지 도시 또는 자치구 내에 여러 정류장이 있는 경우 목적지 도시에 도달하면 stop_times.stop_headsign을 사용하세요.
2D. 방향만 '북쪽 방면', '도착편', '시계 방향' 또는 유사한 방향 관련 용어를 사용하여 나타냅니다.
2E. 목적지를 포함하는 방향 <목적지 이름>행 <방향>. 예를 들면 '산호세행 남쪽 방면'입니다.
2F. 목적지 및 경유지를 포함하는 방향 <목적지>행 <방향>(<경유지> 경유). 예를 들면 '하이게이트행 북쪽 방면(채링 크로스 경유)'입니다.
'행'이라는 단어로 행선지를 표시하지 않습니다.
direction_id 경로의 이동이 반대 방향으로 진행되는 경우에는 01을 사용하여 이러한 이동 그룹을 direction_id 필드로 구분합니다.
데이터 세트 전반에서 01 값을 일관되게 사용하세요. 즉, 다음과 같이 사용할 수 있습니다.
  • 빨간색 경로에서 1 = 출발편인 경우 초록색 경로에서도 1 = 출발편
  • 경로 X에서 1 = 북쪽 방면인 경우 경로 Y에서도 1 = 북쪽 방면
  • 경로 X에서 1 = 시계 방향인 경우 경로 Y에서도 1 = 시계 방향

stop_times.txt

순환 경로: 순환 경로는 특별히 stop_times를 고려해야 합니다. (순환 경로 사례 참고하기)

필드 이름 권장사항 추천
pickup_type, drop_off_type 승객 서비스를 제공하지 않는 비수익(무임) 여행의 경우 모든 stop_times 행에 대해 pickup_typedrop_off_type 값을 1로 표시해야 합니다.
수익이 창출되는 이동의 경우 승객이 승차할 수 없는 차고와 같은 기타 장소 및 운행 실적을 모니터링하는 내부 '승하차 시기 지점'이 pickup_type = 1(픽업 불가) 및 drop_off_type = 1(하차 불가)로 표시되어야 합니다.
timepoint timepoint 필드가 입력되어야 합니다. 이 필드는 운영자가 엄격하게 준수하려고 하는 stop_times(timepoint=1)를 지정합니다. 다른 정차 시간은 예상값(timepoint=0)입니다.
arrival_timedeparture_time arrival_timedeparture_time 필드는 타임포인트 간의 구속력 없는 추정 또는 보간된 시간을 포함한 시간 값을 가능할 때마다 지정해야 합니다.
stop_headsign

stop_headsign 값은 trips.txt에서 trip_headsign에 우선하여 적용됩니다. 이동 중에 행선 표지판에 표시된 텍스트가 변경되는 경우 stop_headsign 값이 제공되어야 합니다. stop_headsign 값은 후속 정류장에 대한 '하차'를 수행하지 않으므로 행선 표지판에 표시되는 정차지가 동일한 경우 값이 반복되어야 합니다. 일반적으로 행선지 값은 역에 있는 표지판과 일치해야 합니다.

아래에 나와 있는 사례에서 '남쪽 방면'은 역에 있는 표지판에 사용되지 않으므로 고객의 오해를 불러일으킬 수 있습니다.

뉴욕시에서 남쪽 방면으로 향하는 경로 2개의 경우:
stop_times.txt행: stop_headsign 값 사용:
맨해튼에 도착할 때까지 Manhattan & Brooklyn
시내에 도착할 때까지 Downtown & Brooklyn
브루클린에 도착할 때까지 Brooklyn
브루클린에 도착하면 Brooklyn (New Lots Av)
보스턴에서 남쪽 방면으로 향하고 브레인트리로 갈라지는 빨간색 노선:
stop_times.txt행: stop_headsign 값 사용:
시내에 도착할 때까지 Inbound to Braintree
시내에 도착하면 Braintree
시내 이후 Outbound to Braintree
shape_dist_traveled 경로에 순환형 또는 인라인(차량이 한 이동에서 노선의 동일한 부분을 교차하거나 운행) 경로가 있는 경우 shape_dist_traveled를 제공해야 합니다. shapes.shape_dist_traveled 권장사항을 참고하세요.

calendar.txt

필드 이름 권장사항 추천
모든 필드 calendar_dates.txt에는 일정에 대한 제한된 수의 예외만 포함되어야 합니다. 정기적으로 운행되는 서비스는 calendar.txt를 사용하여 구성해야 합니다.
calendar.service_name 필드를 포함하면 GTFS의 인간 가독성이 증가할 수 있으나 이는 사양에 적용되지 않습니다.

calendar_dates.txt

필드 이름 권장사항 추천
모든 필드 calendar_dates.txt에는 일정에 대한 제한된 수의 예외만 포함되어야 합니다. 정기적으로 운행되는 서비스는 calendar.txt를 사용하여 구성해야 합니다.
calendar.service_name 필드를 포함하면 GTFS의 인간 가독성이 증가할 수 있으나 이는 사양에 적용되지 않습니다.

fare_attributes.txt

필드 이름 권장사항 추천
모든 필드 필드가 agency.txt에 포함된 경우에는 agency_idfare_attributes.txt에 포함되어야 합니다.
요금 체계를 정확하게 모델링할 수 없는 경우에는 추가적인 혼동을 방지하기 위해 이 필드를 비워 둡니다.
요금(fare_attributes.txtfare_rules.txt)을 포함하고 가능한 한 정확하게 모델링합니다. 요금을 정확하게 모델링할 수 없는 예외 사례의 경우 고객이 요금을 덜 지불하고 승차하려는 것을 방지할 수 있도록 요금을 더 비싼 가격으로 표시해야 합니다. 대부분의 요금을 올바르게 모델링할 수 없는 경우 피드에 요금 정보를 포함하지 않습니다.

fare_rules.txt

필드 이름 권장사항 추천
모든 필드 필드가 agency.txt에 포함된 경우에는 agency_idfare_attributes.txt에 포함되어야 합니다.
요금 체계를 정확하게 모델링할 수 없는 경우에는 추가적인 혼동을 방지하기 위해 이 필드를 비워 둡니다.
요금(fare_attributes.txtfare_rules.txt)을 포함하고 가능한 한 정확하게 모델링합니다. 요금을 정확하게 모델링할 수 없는 예외 사례의 경우 고객이 요금을 덜 지불하고 승차하려는 것을 방지할 수 있도록 요금을 더 비싼 가격으로 표시해야 합니다. 대부분의 요금을 올바르게 모델링할 수 없는 경우 피드에 요금 정보를 포함하지 않습니다.

shapes.txt

필드 이름 권장사항 추천
모든 필드 공유되는 노선(즉, 경로 1과 경로 2에서 도로 또는 트랙의 동일한 부분을 운행하는 경우)의 경우에는 노선의 공유 부분이 정확히 일치하는 것이 좋습니다. 이렇게 하면 고품질의 대중교통 지도를 제작하는 데 도움이 됩니다.
노선은 차량이 이동하는 도로의 중심선을 올바른 방향으로 따라야 합니다. 지정된 차선이 없는 경우 도로의 중심선이거나 차량이 움직이는 방향으로 이동하는 도로 쪽의 중심선일 수도 있습니다.

노선은 연석 정류장, 승강장 또는 탑승 위치에 대해 '들쭉날쭉하게' 표시되어서는 안 됩니다.
shape_dist_traveled

노선에 순환 또는 인라인(차량이 한 이동에서 노선의 동일한 부분을 교차하거나 운행) 경로가 있는 경우 shapes.txtstop_times.txt를 제공해야 합니다.

인라인 경로

차량이 이동 경로의 어떤 지점에서 경로 노선을 다시 돌아가거나 교차하는 경우 shape_dist_traveledshapes.txt 라인업 지점의 어느 부분이 stop_times.txt의 레코드에 해당하는지 명확히 하는 데 중요합니다.

shape_dist_traveled 필드를 통해 기관은 stop_times.txt 파일의 정류장이 어떻게 각각의 모양에 잘 들어 맞는지 정확히 지정할 수 있습니다. shape_dist_traveled 필드에 사용되는 일반적인 값은 차량이 운행한 모양의 시작 부분부터의 거리입니다(주행 거리 판독과 유사).
  • shapes.txt에서 경로 노선은 경로가 제공되는 정류장 위치로부터 100미터 이내에 있어야 합니다.
  • shapes.txt에 관련이 없는 지점이 포함되지 않도록 노선을 간소화하세요 (즉, 직선 구간의 추가 지점을 삭제. 노선 간소화 문제에 대한 논의 참고).

feed_info.txt

feed_info.txt는 아래 나와 있는 모든 필드와 함께 포함되어야 합니다.

필드 이름 권장사항 추천
feed_start_datefeed_end_date 포함되어야 합니다.
feed_version 포함되어야 합니다.
feed_contact_emailfeed_contact_url 하나 이상 입력합니다.

frequencies.txt

필드 이름 권장사항 추천
모든 필드 frequencies.txt에서 참조하는 이동에서 실제 정차 시간은 무시되며, 정류장 간 이동 시간 간격만이 빈도 기반 이동에서 중요한 역할을 합니다. 명확성 및 인간의 가독성을 위해서는 frequencies.txt에서 참조하는 이동의 첫 번째 정차 시간을 00:00:00(첫 번째 00:00:00 arrival_time 값)으로 시작하는 것이 좋습니다.
block_id 빈도 기반 이동에 제공될 수 있습니다.

transfers.txt

transfers.transfer_typeGTFS에 정의된 4개의 값 중 하나일 수 있습니다. 이러한 transfer_type 정의는 아래 GTFS 사양에서 인용되었으며 추가 권장사항이 함께 나와 있습니다.

필드 이름 권장사항 추천
transfer_type 0 또는 (비어 있음): 경로 간에 권장되는 환승 지점입니다.

최적의 옵션(즉, 추가 편의시설이 있는 대중교통 센터 또는 인접하거나 연결된 탑승 시설/플랫폼이 있는 역)이 포함된 환승 경로가 여러 개인 경우 권장되는 환승 지점을 지정합니다.

1: 두 경로 간의 정기 환승 지점입니다. 출발 차량은 승객이 경로 간에 환승하기에 충분한 시간을 두고 도착 차량을 기다릴 것으로 예상됩니다.

이 환승 유형은 안정적인 환승을 위해 필요한 간격보다 우선합니다. 예를 들어 Google 지도에서는 안전하게 환승하기 위해 승객에게 3분이 필요하다고 가정합니다. 다른 애플리케이션에서는 다른 기본값을 가정할 수도 있습니다.

2: 연결을 위해 도착과 출발 사이에 최소 시간이 필요한 환승입니다. 환승에 필요한 시간은 min_transfer_time에서 지정합니다.

정류장 간 이동 시간을 늘리는 장애물 또는 기타 요인이 있는 경우 최소 환승 시간을 지정하세요.

3: 이 위치의 경로 간에는 환승이 불가능합니다.

물리적 장벽으로 인해 환승할 수 없는 경우 또는 건널 수 없는 지점이나 인도와의 넓은 간격으로 인해 환승하기 안전하지 않거나 어려운 경우에는 이 값을 지정하세요.

이동 간에 좌석 내(블록) 환승이 허용되는 경우 도착 이동의 마지막 정류장이 출발 이동의 첫 번째 정류장과 동일해야 합니다.

사례별로 정리된 권장사항

이 섹션에서는 파일 및 필드 전반에서 영향과 관련된 특정 사례를 다룹니다.

순환 경로

순환 경로에서는 차량의 이동이 동일한 위치(종종 대중교통 또는 환승 센터)에서 시작되고 끝납니다. 일반적으로 차량은 지속적으로 운행되며, 차량이 순환 경로를 따라 운행되는 동안 승객이 해당 차량에 계속 탑승해 있을 수 있습니다.

아래는 순환 경로입니다. 차량이 한 이동의 출발지로 돌아갑니다. 일부 순환 경로는 한 방향으로만 이동하고 일부는 양방향으로 이동합니다.
순환 경로

따라서 탑승자에게 차량이 이동하는 방향을 보여주기 위해 행선지 권장사항을 적용해야 합니다.

변경되는 이동 방향을 표시하려면 stop_times.txt 파일의 stop_headsigns를 제공하세요. stop_headsign은 정의된 정류장으로부터 출발하는 이동의 방향을 설명합니다. 이동 상의 각 정류장에 stop_headsigns를 추가하면 이동 중에 행선지 정보를 변경할 수 있습니다.

2개의 엔드포인트 간 운행하는 경로(예: 동일한 버스의 왕복 운행)에 대해 순환 이동을 stop_times.txt 파일에 정의해서는 안 됩니다. 대신 이동을 두 개의 개별 이동 경로로 나눕니다.

순환 이동 모델링의 예:

정류장마다 변경되는 행선지가 있는 순환 이동:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "B"
trip_1 06:15:00 06:15:00 stop_B 2 "C"
trip_1 06:20:00 06:20:00 stop_C 3 "D"
trip_1 06:25:00 06:25:00 stop_D 4 "E"
trip_1 06:30:00 06:30:00 stop_E 5 "A"
trip_1 06:35:00 06:35:00 stop_A 6 ""

두 개의 행선지가 있는 순환 이동:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "outbound"
trip_1 06:15:00 06:15:00 stop_B 2 "outbound"
trip_1 06:20:00 06:20:00 stop_C 3 "outbound"
trip_1 06:25:00 06:25:00 stop_D 4 "inbound"
trip_1 06:30:00 06:30:00 stop_E 5 "inbound"
trip_1 06:35:00 06:35:00 stop_F 6 "inbound"
trip_1 06:40:00 06:40:00 stop_A 7 ""
필드 이름 권장사항 추천
trips.trip_id 순환 경로에 대해 전체 왕복 이동을 단일 이동으로 모델링하세요.
stop_times.stop_id 순환 경로인 이동의 경우 stop_times.txt에 첫 번째/마지막 정류장을 두 번 포함합니다. 예를 들어 다음과 같습니다. 일부 순환 경로에는 순환 경로 전체를 이동하지 않는 첫 번째 이동과 마지막 이동이 포함될 수도 있으며, 이러한 이동도 포함해야 합니다.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id 순환 경로가 반대 방향(즉, 시계 방향 및 시계 반대 방향)으로 진행되는 경우 direction_id0 또는 1로 지정하세요.
trips.block_id 동일한 block_id로 연속 순환 이동을 나타냅니다.

올가미형 경로

올가미형 경로는 순환 경로와 방향 경로의 요소가 결합된 경로입니다.

아래: 올가미형 경로는 다음 세 가지 구간으로 구성된 B를 경유하여 A에서 A로 되돌아오는 순환 경로입니다.
  • A에서 B로 이동하는 직선 구간
  • B에서 B로 되돌아오는 순환 구간
  • B에서 A로 이동하는 직선 구간
올가미형 경로
예:
지하철 노선 (시카고)
교외에서 시내로 향하는 버스 경로 (세인트앨버트 또는 에드먼턴)
CTA 갈색 노선 (CTA 웹사이트TransitFeeds)
필드 이름 권장사항 추천
trips.trip_id '차량 왕복 이동'의 전체 범위( 그림 참조)는 A에서 B로 이동한 후 B에서 A로 되돌아오는 이동입니다. 전체 차량 왕복 이동은 다음과 같이 표현할 수 있습니다.
  • trips.txt단일 trip_id 값/레코드
  • block_id로 표시되는 지속적인 이동을 포함하는 trips.txt여러 trip_id 값/레코드
  • stop_times.stop_headsign A-B 구간 사이의 정류장은 양방향에서 거치게 됩니다. stop_headsign을 사용하면 이동 방향을 구분하는 데 도움이 됩니다. 따라서 이러한 이동의 경우 stop_headsign을 제공하는 것이 좋습니다.
    예:
    'A(B 경유)'
    'A'
    시카고 교통국의 보라색 노선
    '루프행 남쪽 방면'
    '북쪽 방면(루프 경유)'
    '런던행 북쪽 방면'
    에드먼턴 대중교통 서비스 버스 노선 (39)
    '루더포드'
    '센추리 파크'
    trip.trip_headsign 이동 행선 표지판에서는 운행 일정에 표시된 것과 같이 이동에 대한 포괄적인 설명을 제공해야 합니다. 시카고를 예로 드는 경우에는 '린던행 린던(루프 경유)', 일반적인 예를 드는 경우에는 'A행 A(B 경유)'가 될 수 있습니다.

    분기형 경로

    일부 경로에는 분기형 경로가 포함될 수 있습니다. 노선 및 정류장은 분기형 경로 간에 공유되지만, 분기형 경로마다 고유한 정류장 및 노선 구간도 존재합니다. 분기형 경로 간의 관계는 아래에 나온 추가 가이드라인을 따라 경로 이름, 행선 표지판, 이동 별칭으로 표시할 수 있습니다.

    아래: 분기형 경로의 세 가지 유형입니다. 기본 노선은 검은색이고, 하나의 갈래로 나뉜 경로는 금색입니다.
    분기형 경로의 구성
    필드 이름 권장사항 추천
    모든 필드 분기형 경로의 이름을 지정할 때는 다른 승객 정보 자료를 따르는 것이 좋습니다. 다음은 두 가지 사례에 대한 설명과 예입니다.
    일정과 거리 표지판에 별개로 이름이 지정된 두 개의 경로(예: 1A 및 1B)를 나타내는 경우 route_short_name 또는 route_long_name 필드를 사용하여 GTFS에 표시할 수 있습니다. 예를 들어 GoDurham의 대중교통 경로인 2, 2A, 2B는 대부분의 경로에서 공통된 노선을 공유하지만 일부 측면에서 서로 다릅니다.
    • 경로 2는 대부분의 시간 동안 운행되는 핵심 서비스입니다.
    • 경로 2에는 메인 스트리트의 야간, 일요일, 휴일의 편차가 포함됩니다.
    • 경로 2A 및 2B는 월요일부터 토요일까지 종일 운행됩니다.
    • 경로 2B는 공유하는 노선 경로의 편차에서 추가 정류장에 정차합니다.
    기관이 제공하는 정보가 분기형 경로를 동일한 이름의 경로로 설명하는 경우 trips.trip_headsign, stop_times.stop_headsign 또는 trips.trip_short_name 필드를 활용합니다. 예를 들어 GoTriangle의 경로 300은 하루 중 언제인가에 따라 다른 위치로 이동합니다. 가장 바쁜 통근 시간 중에는 표준 경로에 추가 구간이 추가되어 도시를 드나드는 승객을 수용할 수 있습니다.

    이 문서에 대한 정보

    목표

    GTFS 권장사항 유지 목표는 다음과 같습니다.

    • 대중교통 데이터의 상호 운용성 증대
    • 대중교통 앱의 최종 사용자 고객 환경 개선
    • 소프트웨어 개발자가 손쉽게 애플리케이션, 제품, 서비스를 배포하고 확장할 수 있도록 설정
    • 본래 목적인 이동 계획 이외에 다양한 애플리케이션 카테고리에서 GTFS 사용 촉진

    게시된 GTFS 권장사항을 제안하거나 수정하는 방법

    GTFS 애플리케이션과 관행이 발전하기 때문에 경우에 따라 이 문서가 수정되어야 할 수도 있습니다. 이 문서의 수정사항을 제안하려면 GTFS 권장사항 GitHub 저장소에서 pull 요청을 열고 변경사항을 제안하세요. 의견을 specifications@mobilitydata.org로 이메일로 보내도 됩니다.

    이 문서에 연결하기

    피드 제작자에게 GTFS 데이터의 올바른 매핑에 대한 안내를 제공하려면 여기에 연결하세요. 각 권장사항에는 앵커 링크가 있습니다. 인페이지 앵커 링크의 URL을 가져오려면 권장사항을 클릭하세요.

    GTFS를 사용하는 애플리케이션이 여기에 나와 있지 않은 GTFS 데이터 관행에 대한 요구사항이나 권장사항을 설정한 경우, 일반적인 권장사항을 보완하는 이러한 요구사항 또는 권장사항이 포함된 문서를 게시하는 것이 좋습니다.

    GTFS 권장사항 실무 그룹

    GTFS 권장사항 실무 그룹은 2016년~2017년에 Rocky Mountain Institute에서 소집했습니다. Rocky Mountain Institute는 대중교통 제공업체, GTFS를 사용하는 애플리케이션 개발자, 컨설턴트, 학술 기관으로 구성되어 GTFS 데이터에 관한 일반 권장사항 및 기대치를 정의합니다. 이 실무 그룹의 회원은 다음과 같습니다.

    현재 이 문서는 MobilityData International Organization에서 관리합니다.