핵심 GTFS
일반 대중교통 피드 사양(GTFS)의 대중교통 서비스를 설명하기 위한 권장사항입니다. 이러한 권장사항은 GTFS 권장사항 실무 그룹 구성원의 경험과 애플리케이션별 GTFS 권장사항을 종합한 것입니다. 자세한 내용은 자주 묻는 질문(FAQ)을 참고하세요.
문서 구성
권장사항은 다음과 같은 3가지 기본 섹션으로 구성됩니다.
- 데이터 세트 게시 및 일반 권장사항: 이 권장사항은 GTFS 데이터 세트의 전체 구조 및 GTFS 데이터 세트가 게시되는 방식과 관련이 있습니다.
- 파일별로 정리된 권장사항 추천: 공식 GTFS 참조로 다시 매핑하는 작업을 손쉽게 수행할 수 있도록 GTFS의 파일 및 필드별로 추천이 정리되어 있습니다.
- 사례별로 정리된 권장사항 추천: 순환 경로와 같은 특정 사례의 경우 추천을 여러 파일과 필드에 걸쳐 적용해야 할 수 있습니다. 해당 권장사항 추천은 이 섹션에서 함께 다룹니다.
자주 묻는 질문(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 피드에서 가져와 병합한 데이터 세트를 만들 수 있습니다.
|
| 피드에서 오래된 서비스(만료된 캘린더)를 삭제하세요. |
| 서비스 수정이 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.txt 및
fare_attributes.txt에
agency_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_lat 및 stop_lon |
정류장 위치는 최대한 정확해야 합니다. 정류장 위치와 실제 정차 위치를 비교할 때 오차가 4미터 이상 발생하면 안 됩니다. | ||||||||
| 정차 위치가 인도에서 승객이 탑승하는 위치와 매우 가까워야 합니다(실제 도로상의 통행 방향과 일치해야 함). | |||||||||
정류장 위치가 여러 데이터 피드에서 공유되는 경우(두 기관에서 동일한 정류장/탑승
시설을 사용하는 경우)에는 두 정류장 모두에 동일한 stop_lat 및 stop_lon을 사용하여 해당 정류장이
공유되고 있음을 나타내세요. |
|||||||||
stop_code |
승객을 위한 경유지 번호 또는 짧은 식별자가 있는 경우
GTFS에 stop_code가 포함되어야 합니다. |
||||||||
parent_station 및 location_type |
다양한 역 또는 터미널에 여러 탑승 시설이 있으며, 교통수단에 따라
버스 정류장, 승강장, 부두, 탑승구 등 각기 다른 용어로 불립니다. 이러한 경우 피드
제작자는 역, 탑승 시설(하위 정류장이라고도 함), 관련성을
설명해야 합니다.
|
||||||||
역 및 하위 정류장의 이름을 지정하는 경우 탑승자에게 널리 알려져 있는 이름으로 설정하면
탑승자가 역과 탑승 시설(버스 정류장, 승강장, 부두, 탑승구 등)을 파악하는 데
도움이 됩니다.
|
routes.txt
| 필드 이름 | 권장사항 추천 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
agency_id |
agency.txt에 정의된 경우 포함되어야 합니다. |
||||||||||||||||||||
route_short_name |
간단한 서비스 지정 정보가 있는 경우 route_short_name을 포함하세요. 승객에게
널리 알려진 서비스의 이름이어야 하며 12자(영문 기준) 이하여야 합니다. |
||||||||||||||||||||
route_long_name |
사양 참조에 명시된 정의:
일반적으로 다음은 긴 이름의 예입니다.
|
||||||||||||||||||||
route_long_name에는 route_short_name이 포함되면 안 됩니다. |
|||||||||||||||||||||
route_long_name의 내용을 입력할 때 서비스 ID 등 전체 지정 정보를
포함하세요. 예:
|
|||||||||||||||||||||
route_id |
이름이 지정된 경로 상의 모든 이동은 동일한 route_id를 참조해야 합니다.
|
||||||||||||||||||||
경로 그룹에 이름이 다르게 지정된 분기형 경로(예: 1A 및 1B)가 포함되어 있는 경우
분기형 경로
사례의 권장사항 추천에 따라 route_short_name 및 route_long_name을
정하세요. |
|||||||||||||||||||||
route_color 및 route_text_color |
사이니지, 인쇄물, 온라인 고객 정보와 일치해야 하며, 다른 곳에서 사용되지 않는 경우에는 포함하지 않습니다. | ||||||||||||||||||||
trips.txt
- 순환 경로에 대한 특수 사례 참고: 순환 경로는 동일한 정류장에서 이동이 시작되고 끝나는 경로를 의미하며, 서로 다른 두 개의 터미널을 갖는 선형 경로와는 반대됩니다. 순환 경로는 특정 관행을 따라 설명되어야 합니다. 순환 경로 사례 참고하기
- 올가미형 경로에 대한 특수 사례 참고: 올가미형 경로는 선형 및 순환 형태를 합친 경로로, 차량이 일부 경로에 대해서만 순환 경로로 진행합니다. 올가미형 경로는 특정 관행을 따라 설명되어야 합니다. 올가미형 경로 사례 참고하기
| 필드 이름 | 권장사항 추천 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trip_headsign |
trip_headsign 또는 stop_headsign 필드에 경로 이름(route_short_name 및
route_long_name과 일치)을
제공하지 않습니다. |
||||||||||||||
경로의 여러 이동을 구분하는 데 사용할 수 있으며 차량의 행선 표지판에 표시된
목적지, 경로 또는 기타 이동 지정 텍스트를 포함해야 합니다.
차량에 표시된 경로 정보와의 일관성을 유지하는 것이 GTFS 데이터 세트에 제공되는 행선지를 결정하는
기본이자 우선시되는 목표입니다. 이 기본 목표와 충돌하지
않는 경우에만 기타 정보를 포함해야 합니다. 이동 중에 행선지가 바뀌는
경우 trip_headsign에 우선하여 stop_times.stop_headsign을 적용하세요. 다음은
일부 사례를 위한 권장사항입니다. |
|||||||||||||||
example_table:
|
|||||||||||||||
| '행'이라는 단어로 행선지를 표시하지 않습니다. | |||||||||||||||
direction_id |
경로의 이동이 반대 방향으로 진행되는 경우에는 0 및 1을 사용하여 이러한 이동 그룹을
direction_id 필드로 구분합니다. |
||||||||||||||
데이터 세트 전반에서 0 및 1 값을 일관되게 사용하세요. 즉, 다음과 같이 사용할 수 있습니다.
|
stop_times.txt
순환 경로: 순환 경로는 특별히 stop_times를 고려해야 합니다. (순환 경로 사례 참고하기)
| 필드 이름 | 권장사항 추천 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
pickup_type, drop_off_type |
승객 서비스를 제공하지 않는 비수익(무임) 이동의 경우 모든 stop_times 행에 대해
pickup_type 및 drop_off_type 값을 1로
표시해야 합니다. |
||||||||||||
수익이 창출되는 이동의 경우 승객이 승차할 수 없는 차고와 같은 기타 장소 및 운행
실적을 모니터링하는 내부 '승하차 시기 지점'이
pickup_type = 1(승차 불가) 및 drop_off_type = 1(하차 불가)로
표시되어야 합니다. |
|||||||||||||
timepoint |
timepoint 필드가 입력되어야 합니다. 이 필드는
운영자가 엄격하게 준수하려고 하는 stop_times(timepoint=1)를
지정합니다. 다른 정차 시간은
예상값(timepoint=0)입니다. |
||||||||||||
arrival_time 및 departure_time |
arrival_time 및 departure_time 필드는 타임포인트 간의
구속력 없는 추정 또는 보간된 시간을 포함한 시간 값을 가능할 때마다
지정해야 합니다. |
||||||||||||
stop_headsign |
아래에 나와 있는 사례에서 '남쪽 방면'은 역에 있는 표지판에 사용되지 않으므로 고객의 오해를 불러일으킬 수 있습니다. |
||||||||||||
|
|||||||||||||
|
|||||||||||||
| 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_id가
fare_attributes.txt에 포함되어야 합니다. |
| 요금 체계를 정확하게 모델링할 수 없는 경우에는 추가적인 혼동을 방지하기 위해 이 필드를 비워 둡니다. | |
요금(fare_attributes.txt 및 fare_rules.txt)을 포함하고 가능한 한
정확하게 모델링합니다. 요금을 정확하게 모델링할 수 없는 예외 사례의 경우
고객이 요금을 덜 지불하고 승차하려는 것을 방지할 수 있도록
요금을 더 비싼 가격으로 표시해야 합니다. 대부분의 요금을 올바르게 모델링할 수 없는 경우
피드에 요금 정보를 포함하지 않습니다. |
fare_rules.txt
| 필드 이름 | 권장사항 추천 |
|---|---|
| 모든 필드 | 필드가 agency.txt에 포함된 경우에는 agency_id가
fare_attributes.txt에 포함되어야 합니다. |
| 요금 체계를 정확하게 모델링할 수 없는 경우에는 추가적인 혼동을 방지하기 위해 이 필드를 비워 둡니다. | |
요금(fare_attributes.txt 및 fare_rules.txt)을 포함하고 가능한 한
정확하게 모델링합니다. 요금을 정확하게 모델링할 수 없는 예외 사례의 경우
고객이 요금을 덜 지불하고 승차하려는 것을 방지할 수 있도록
요금을 더 비싼 가격으로 표시해야 합니다. 대부분의 요금을 올바르게 모델링할 수 없는 경우
피드에 요금 정보를 포함하지 않습니다. |
shapes.txt
| 필드 이름 | 권장사항 추천 |
|---|---|
| 모든 필드 | 공유되는 노선(즉, 경로 1과 경로 2에서 도로 또는 트랙의 동일한 부분을 운행하는 경우)에서는 노선의 공유 부분이 정확히 일치하는 것이 좋습니다. 이렇게 하면 고품질의 대중교통 지도를 제작하는 데 도움이 됩니다. |
| 노선은 차량이 이동하는 도로의 중심선을 올바른 방향으로 따라야 합니다.
지정된 차선이 없는 경우 도로의 중심선이거나
차량이 움직이는 방향으로 이동하는 도로 쪽의 중심선일 수도 있습니다. 노선은 연석 정류장, 승강장 또는 탑승 위치를 '들쭉날쭉하게' 표시해서는 안 됩니다. |
|
shape_dist_traveled |
노선에 순환 또는 인라인(차량이 한 이동에서 노선의
동일한 부분을 교차하거나 운행) 경로가 있는 경우 
차량이 이동 경로의 어떤 지점에서 경로 노선을 다시 돌아가거나 교차하는 경우
|
shape_dist_traveled 필드를 통해 기관은 stop_times.txt 파일의 정류장이
어떻게 각각의 모양에 잘 들어 맞는지 정확히 지정할 수 있습니다. shape_dist_traveled 필드에
사용되는 일반적인 값은 차량이 운행한 모양의
시작 부분부터의 거리입니다(주행 거리
판독과 유사).
|
feed_info.txt
feed_info.txt는 아래 나와 있는 모든 필드와 함께 포함되어야 합니다.
| 필드 이름 | 권장사항 추천 |
|---|---|
feed_start_date 및 feed_end_date |
포함되어야 합니다. |
feed_version |
포함되어야 합니다. |
feed_contact_email 및 feed_contact_url |
하나 이상 입력합니다. |
frequencies.txt
| 필드 이름 | 권장사항 추천 |
|---|---|
| 모든 필드 | frequencies.txt에서 참조하는 이동에서 실제 정차 시간은 무시되며, 정류장
간 이동 시간 간격만이 빈도 기반 이동에서 중요한 역할을 합니다.
명확성 및 인간의 가독성을 위해서는 frequencies.txt에서 참조하는 이동의
첫 번째 정차 시간을 00:00:00(첫 번째 00:00:00 arrival_time 값)으로
시작하는 것이 좋습니다. |
block_id |
빈도 기반 이동에 제공될 수 있습니다. |
transfers.txt
transfers.transfer_type은 GTFS에 정의된
4개의 값 중 하나일 수 있습니다. 이러한
transfer_type 정의는 아래 GTFS 사양에서 인용되었으며
추가 권장사항이 함께 나와 있습니다.
| 필드 이름 | 권장사항 추천 |
|---|---|
transfer_type |
최적의 옵션(즉, 추가 편의시설이 있는 대중교통 센터 또는 인접하거나 연결된 탑승 시설/플랫폼이 있는 역)이 포함된 환승 경로가 여러 개인 경우 권장되는 환승 지점을 지정합니다. |
각 데이터 소비자는 자체 알고리즘을 통해 환승에 필요한 시간을
계산합니다. 이 값이 충분하지 않거나 소비자가
고려하지 않은 다른 조건이 있는 경우
|
|
정류장 간 이동 시간을 늘리는 장애물 또는 기타 요인이 있는 경우 최소 환승 시간을 지정하세요. |
|
물리적 장벽으로 인해 환승할 수 없는 경우 또는 건널 수 없는 지점이나 인도와의 넓은 간격으로 인해 환승하기 안전하지 않거나 어려운 경우에는 이 값을 지정하세요. |
|
| 이동 간에 좌석 내(블록) 환승이 허용되는 경우 도착 이동의 마지막 정류장이 출발 이동의 첫 번째 정류장과 동일해야 합니다. |
사례별로 정리된 권장사항
이 섹션에서는 파일 및 필드 전반에서 영향과 관련된 특정 사례를 다룹니다.
순환 경로
순환 경로에서는 차량의 이동이 동일한 위치(종종 대중교통 또는 환승 센터)에서 시작되고 끝납니다. 일반적으로 차량은 지속적으로 운행되며, 차량이 순환 경로를 따라 운행되는 동안 승객이 해당 차량에 계속 탑승해 있을 수 있습니다.
따라서 탑승자에게 차량이 이동하는 방향을 보여주기 위해 행선지 권장사항을 적용해야 합니다.
변경되는 이동 방향을 표시하려면 stop_times.txt 파일의 stop_headsigns를
제공하세요. stop_headsign은 정의된 경유지로부터 출발하는
이동의 방향을 설명합니다. 이동 상의 각 정류장에
stop_headsigns를 추가하면 이동 중에 행선지 정보를 변경할 수 있습니다.
두 개의 엔드포인트 간 운행하는 경로(예: 동일한 버스의 왕복 운행)에 대해서는
순환 이동을 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에 첫 번째/마지막 정류장을 두 번
포함합니다. 예를 들어 다음과 같습니다. 일부 순환 경로에는 순환 경로 전체를 이동하지 않는 첫 번째 이동과 마지막 이동이
포함될 수도 있으며, 이러한 이동도 포함해야 합니다.
|
|||||||||||||||
trips.direction_id |
순환 경로가 반대 방향(즉, 시계 방향 및 시계 반대 방향)으로 진행되는 경우
direction_id를 0 또는 1로 지정하세요. |
|||||||||||||||
trips.block_id |
동일한 block_id로 연속 순환 이동을 나타냅니다. |
올가미형 경로
올가미형 경로는 순환 경로와 방향 경로의 요소가 결합된 경로입니다.
- 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을 제공하는 것이 좋습니다.
|
||||||||||
trip.trip_headsign |
이동 행선 표지판에서는 운행 일정에 표시된 것과 같이 이동에 대한 포괄적인 설명을 제공해야 합니다. 시카고를 예로 드는 경우에는 '린던행 린던(루프 경유)', 일반적인 예를 드는 경우에는 'A행 A(B 경유)'가 될 수 있습니다. |
분기형 경로
일부 경로에는 분기형 경로가 포함될 수 있습니다. 노선 및 정류장은 분기형 경로 간에 공유되지만, 분기형 경로마다 고유한 정류장 및 노선 구간도 존재합니다. 분기형 경로 간의 관계는 아래에 나온 추가 가이드라인을 따라 경로 이름, 행선 표지판, 이동 별칭으로 표시할 수 있습니다.
| 필드 이름 | 권장사항 추천 |
|---|---|
| 모든 필드 | 분기형 경로의 이름을 지정할 때는 다른 승객 정보 자료를 따르는 것이 좋습니다. 다음은 두 가지 사례에 대한 설명과 예입니다. |
일정과 거리 표지판에 별개로 이름이 지정된 두 개의 경로(예: 1A 및
1B)를 나타내는 경우 route_short_name 또는 route_long_name 필드를 사용하여
GTFS에 표시할 수 있습니다. 예를 들어 GoDurham의 대중교통 경로인 2, 2A, 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 데이터에 관한 일반 권장사항 및 기대치를 정의합니다. 이 실무 그룹의 회원은 다음과 같습니다.
- Cambridge Systematics
- Capital Metro
- Center for Urban Transportation Research at University of South Florida
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Oregon Department of Transportation
- Swiftly
- Transit
- Trillium
- TriMet
- World Bank
현재 이 문서는 MobilityData International Organization에서 관리합니다.