콘텐츠로 이동

GTFSSchedule 모범 사례

이는 일반 대중교통 피드 사양(GTFS)에서 대중교통 서비스를 설명하기 위한 권장 사례입니다. 이러한 관행은 GTFS 권장사항 실무 그룹 회원의 경험과 애플리케이션별 GTFS 관행 권장사항 을 바탕으로 종합되었습니다.

추가 배경 정보는 자주 묻는 질문 (FAQ)을 참조하십시오.

문서 구조

실습은 네 가지 기본 섹션으로 구성되어 있습니다.

데이터세트 게시 및 일반 관행

  • 데이터세트는 zip 파일 이름을 포함하여 공개된 영구 URL에 게시되어야 합니다. (예: www.agency.org/gtfs/gtfs.zip). 이상적으로는 소프트웨어 애플리케이션을 사용하여 다운로드를 용이하게 하기 위해 파일에 액세스하기 위해 로그인하지 않고도 URL을 직접 다운로드할 수 있어야 합니다. GTFS 데이터세트를 공개적으로 다운로드 가능하게 만드는 것이 가장 일반적인 관행이지만, 데이터 제공업체가 라이선스 또는 기타 이유로 GTFS에 대한 액세스를 제어해야 하는 경우 API 키를 사용하여 GTFS 데이터세트에 대한 액세스를 제어하는 것이 좋습니다. 자동 다운로드가 용이해집니다.
  • GTFS 안정적인 위치의 단일 파일에 항상 대중 교통 기관(또는 기관)에 대한 최신 공식 서비스 설명이 포함되도록 데이터가 반복적으로 게시됩니다.
  • 영구 식별자(id 필드) 유지stop_id ,route_id , 그리고agency_id 가능하면 데이터 반복 전반에 걸쳐.
  • 하나GTFS 데이터 세트에는 현재 및 향후 서비스("병합된" 데이터 세트라고도 함)가 포함되어야 합니다. Google 운송 피드 도구의 병합 기능 을 사용하여 두 개의 서로 다른 데이터세트에서 병합된 데이터세트를 만들 수 있습니다GTFS 피드.
  • 언제든지 공개된GTFS 데이터 세트는 다음 7일 동안 유효해야 하며 이상적으로는 운영자가 다음을 확신하는 한Schedule 계속 운영됩니다.
  • 가능하다면,GTFS 데이터 세트는 적어도 다음 30일의 서비스를 포함해야 합니다.
  • 피드에서 이전 서비스(만료된 캘린더)를 제거합니다.
  • 서비스 수정 사항이 7일 이내에 적용되는 경우 GTFS-realtime 피드(서비스 권고 사항 또는 여행 업데이트)를 통해 이 서비스 변경 사항을 표현하세요. 대신 정적 GTFS 데이터세트를 사용합니다.
  • 웹 서버 호스팅GTFS 데이터는 파일 수정 날짜를 올바르게 보고하도록 구성되어야 합니다(섹션 14.29에서 HTTP/1.1 - 의견 요청 2616 참조).

파일별로 정리된 실습 권장 사항

이 섹션에서는 파일 및 필드별로 구성된 사례를 보여줍니다.GTFS 참조 .

모든 파일

분야 명 추천
혼합 케이스 모든 고객 대면 텍스트 문자열(정류장 이름, 경로 이름 및 헤드 사인 포함)은 소문자를 표시할 수 있는 디스플레이에서 장소 이름을 대문자로 표시하는 현지 규칙에 따라 대소문자 혼합(전체 대문자 아님)을 사용해야 합니다.
예:
브라이튼 처칠 광장
빌리에 쉬르 마른
시장 거리
약어 위치가 축약된 이름(예: "JFK 공항")으로 호출되지 않는 한 피드 전체에서 이름 및 기타 텍스트(예: St. for Street)에 약어를 사용하지 마십시오. 약어는 화면 판독기 소프트웨어 및 음성 사용자 인터페이스의 접근성에 문제가 될 수 있습니다. 소비 소프트웨어는 표시를 위해 전체 단어를 약어로 안정적으로 변환하도록 설계할 수 있지만, 약어에서 전체 단어로 변환하면 오류 위험이 더 커집니다.

agency.txt

분야 명 추천
agency_id 피드에 대행사가 하나뿐인 경우에도 포함되어야 합니다. (포함하는 권장 사항도 참조하십시오.agency_id 안에routes.txt 그리고fare_attributes.txt )
agency_phone 그러한 고객 서비스 전화가 존재하지 않는 한 포함되어야 합니다.
agency_email 그러한 고객 서비스 이메일이 존재하지 않는 한 포함되어야 합니다.
agency_fare_url 대행사가 완전히 무료인 경우가 아니면 포함되어야 합니다.

예:

  • 버스 서비스는 여러 소규모 버스 대리점에서 운영합니다. 그러나 일정 및 발권을 담당하고 버스 서비스를 담당하는 사용자의 관점에서 볼 때 하나의 큰 대행사가 있습니다. 하나의 큰 대행사는 피드 내의 대행사로 정의되어야 합니다. 데이터가 다른 소규모 버스 운영자에 의해 내부적으로 분할되더라도 피드에 정의된 기관은 하나만 있어야 합니다.

  • 피드 제공업체는 티켓팅 포털을 운영하지만 실제로 서비스를 운영하고 사용자가 책임을 지는 것으로 알려진 여러 대행사가 있습니다. 실제로 서비스를 운영하는 에이전시는 피드 내 에이전시로 정의되어야 합니다.

stops.txt

분야 명 추천
stop_name 게시된 중지 이름이 없는 경우 피드 전체에서 일관된 중지 이름 지정 규칙을 따르십시오.
기본적으로,stop_name "Station" 또는 "Stop"과 같은 일반적이거나 중복되는 단어를 포함해서는 안 되지만 일부 예외적인 경우는 허용됩니다.
  • 실제로 이름의 일부인 경우(Union Station, Central Station
  • 때stop_name 너무 일반적입니다(예: 도시 이름인 경우). "역", "터미널" 또는 다른 단어는 의미를 명확하게 합니다.
stop_lat &stop_lon 정지 위치는 가능한 한 정확해야 합니다. 중지 위치에는 다음 오류가 있어야 합니다. 더 이상은 없어 실제 정지 위치와 비교할 때 4미터 이상입니다.
정류장 위치는 승객이 탑승할 보행자 우측(즉, 도로의 올바른 쪽)에 매우 가깝게 위치해야 합니다.
정류장 위치가 별도의 데이터 피드에서 공유되는 경우(즉, 두 기관이 정확히 동일한 정류장/탑승 시설을 사용하는 경우) 동일한 정류장을 사용하여 정류장이 공유됨을 나타냅니다.stop_lat 그리고stop_lon 두 정류장 모두.
parent_station &location_type 많은 역이나 터미널에는 여러 개의 탑승 시설이 있습니다(모드에 따라 버스 베이, 플랫폼, 부두, 게이트 또는 다른 용어로 불릴 수 있음). 이러한 경우 사료 생산자는 역, 탑승 시설(어린이 정류장이라고도 함) 및 이들의 관계를 설명해야 합니다.
  • 스테이션 또는 터미널은 다음의 레코드로 정의되어야 합니다.stops.txt ~와 함께location_type = 1 .
  • 각 탑승 시설은 다음과 같은 정류장으로 정의되어야 합니다.location_type = 0 . 그만큼parent_station 필드는 참조해야 합니다.stop_id 탑승 시설이 있는 역의
역 및 어린이 정류장의 이름을 지정할 때 승객이 잘 인식하고 승객이 역 및 탑승 시설(버스 베이, 플랫폼, 부두, 게이트 등)을 식별하는 데 도움이 될 수 있는 이름을 설정합니다.
상위 스테이션 이름 차일드 스톱 이름
시카고 유니언 스테이션 시카고 유니온 스테이션 19번 플랫폼
샌프란시스코 페리 빌딩 터미널 샌프란시스코 페리 빌딩 터미널 게이트 E
다운타운 트랜짓 센터 다운타운 트랜짓 센터 베이 B

routes.txt

분야 명 추천
agency_id 피드에 대행사가 하나만 있는 경우에도 포함되어야 합니다. (포함할 권장 사항도 참조하십시오.agency_id \~에agency.txt 그리고fare_attributes.txt )
route_short_name 포함route_short_name 간단한 서비스 지정이 있는 경우. 일반적으로 알려진 서비스 승객 이름이어야 하며 12자를 넘지 않아야 합니다.
route_long_name 사양 참조의 정의: 이 이름은 일반적으로 route_short_name 그리고 종종 경로의 목적지 또는 정류장을 포함합니다. 다음 중 하나 이상 route_short_name 또는 route_long_name 지정해야 하거나 해당하는 경우 둘 다 지정해야 합니다. 경로 이름이 길지 않은 경우 지정하십시오. route_short_name 이 필드의 값으로 빈 문자열을 사용합니다.
긴 이름 유형의 예는 다음과 같습니다.
기본 이동 경로 또는 복도
경로 이름 형태 대행사
"N"/"유다" route_short_name /
route_long_name		 무니 , 샌프란시스코
"6"/"ML King Jr Blvd" route_short_name /
route_long_name		 트라이멧 , 포틀랜드, 또는.
“6”/“Nation - Étoile”route_short_name/
route_long_name		RATP, 프랑스 파리에서
“U2”-“Pankow – Ruhleben”route_short_name-
route_long_name		BVG, 독일 베를린에서
서비스 설명
“Hartwell Area Shuttle“
route_long_name 포함하지 않아야 합니다route_short_name .
채울 때 서비스 ID를 포함한 전체 지정 포함route_long_name . 예:
서비스 아이덴티티 추천 예
"MAX 경전철"
오리건주 포틀랜드의 TriMet		 그만큼 route_long_name 브랜드(MAX) 및 특정 경로 지정을 포함해야 합니다. "MAX 레드 라인" "MAX 블루 라인"
"래피드 라이드"
ABQ Ride, 뉴멕시코주 앨버커키		 그만큼 route_long_name 브랜드(Rapid Ride) 및 특정 경로 지정을 포함해야 합니다. "래피드 라이드 레드 라인"
"래피드 라이드 블루 라인"
route_id 지정된 명명된 경로의 모든 여행은 동일한 경로를 참조해야 합니다.route_id .
  • 경로의 다른 방향은 서로 다른 방향으로 분리되어서는 안 됩니다.route_id 가치.
  • 경로의 서로 다른 운영 범위는 서로 다른 경로로 분리되어서는 안 됩니다.route_id 가치. 즉, 다른 레코드를 생성하지 마십시오.routes.txt "다운타운 AM" 및 "다운타운 PM" 서비스용).
    		•
    경로 그룹에 명확하게 명명된 분기(예: 1A 및 1B)가 포함된 경우 경로의 권장 사항을 따르십시오. 가지 결정하는 경우route_short_name 그리고route_long_name .
    route_color &route_text_color 표지판과 인쇄된 온라인 고객 정보와 일치해야 합니다(따라서 다른 장소에 없는 경우 포함되지 않음).

    trips.txt

    • 루프 경로에 대한 특별한 경우 참조: 루프 경로는 두 개의 서로 다른 종점이 있는 선형 경로와 달리 동일한 정류장에서 여행이 시작되고 끝나는 경우입니다. 루프 경로는 특정 관행에 따라 설명해야 합니다. 루프 경로 사례를 참조하십시오.
    • 올가미 경로의 특별한 경우 참조: 올가미 경로는 차량이 경로의 일부만 루프를 따라 이동하는 선형 및 루프 형상의 하이브리드입니다. 올가미 경로는 특정 관행에 따라 설명해야 합니다. 올가미 경로 사례를 참조하십시오.
    분야 명 추천
    trip_headsign 경로 이름을 제공하지 마십시오(일치route_short_name 그리고route_long_name )에서trip_headsign 또는stop_headsign 필드.
    목적지, 방향 및/또는 경로의 여행을 구별하는 데 사용할 수 있는 차량 헤드 사인에 표시된 기타 여행 지정 텍스트를 포함해야 합니다. 차량에 표시된 방향 정보와의 일관성은 차량에 제공된 헤드사인을 결정하기 위한 최우선 목표입니다.GTFS 데이터 세트. 다른 정보는 이 기본 목표를 손상시키지 않는 경우에만 포함되어야 합니다. 여행 중 헤드 사인이 바뀌면 무시하십시오.trip_headsign ~와 함께stop_times.stop_headsign . 다음은 몇 가지 가능한 경우에 대한 권장 사항입니다.
    경로 설명 추천
    2A. 대상 전용 종착역을 제공합니다. 예: "환승 센터", "포틀랜드 시티 센터" 또는 "잔첸 비치">
    2B. 경유지가 있는 목적지 ~을 통해 “Charing Cross를 통한 Highgate”. 차량이 해당 웨이포인트를 통과한 후 승객에게 헤드사인 쇼에서 웨이포인트가 제거된 경우 다음을 사용하십시오. stop_times.stop_headsign 업데이트된 헤드사인을 설정합니다.>
    2C. 지역 정류장이 있는 지역 지명 목적지의 도시 또는 자치구 내부에 여러 정거장이 있는 경우 stop_times.stop_headsign 목적지 도시에 도착하면.>
    2D. 방향 전용 "Northbound", "Inbound", "Clockwise" 또는 이와 유사한 방향과 같은 용어를 사용하여 표시합니다.>
    2E. 목적지가 있는 방향 에게 예: "산호세 남쪽 방향">
    2층 목적지 및 경유지가 있는 방향 ~을 통해 에게 ("Charing Cross를 통해 북쪽으로 Highgate까지").>
    "To" 또는 "Towards"라는 단어로 헤드 사인을 시작하지 마십시오.
    direction_id 데이터 세트 전체에서 일관되게 값 0과 1을 사용합니다. 즉
    • 1 = 빨간색 경로의 아웃바운드인 경우 1 = 녹색 경로의 아웃바운드
    • 1 = 루트 X의 북쪽 방향인 경우 1 = 루트 Y의 북쪽 방향
    • 1 = 루트 X에서 시계 방향이면 1 = 루트 Y에서 시계 방향

    stop_times.txt

    루프 경로: 루프 경로에는 특별한 stop_times 고려 사항이 필요합니다. (참조: 루프 경로 사례 )

    분야 명 추천
    pickup_type &drop_off_type 승객 서비스를 제공하지 않는 비수익(데드헤드) 여행은 다음으로 표시해야 합니다.pickup_type 그리고drop_off_type 가치1 모든stop_times 행.
    수익 여행의 경우 운영 성과를 모니터링하기 위한 내부 "타이밍 포인트" 및 차고와 같이 승객이 탑승할 수 없는 기타 장소에 표시해야 합니다.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 일반적으로 headsign 값은 스테이션의 기호와도 일치해야 합니다.

    아래의 경우 "Southbound"는 역 표지판에 사용되지 않기 때문에 고객을 오도할 수 있습니다.
    NYC에서 Southbound로 가는 2개의 경우:
    을 위한stop_times.txt 행: 사용 stop_headsign 값:
    맨해튼에 도착할 때까지 맨해튼 & 브루클린
    시내에 도착할 때까지 다운타운 및 브루클린
    브루클린에 도착할 때까지 브루클린
    브루클린에 도착하면 브루클린(New Lot Av)
    보스턴에서 남쪽으로 향하는 레드 라인의 경우 Braintree 분기의 경우:
    을 위한stop_times.txt 행: 사용 stop_headsign 값:
    시내에 도착할 때까지 브레인트리로 인바운드
    다운타운에 도착하면 브레인트리
    다운타운 후 Braintree로 아웃바운드
    shape_dist_traveled shape_dist_traveled 루프 또는 인라인이 있는 경로에 대해 제공되어야 합니다(차량이 한 여행에서 동일한 정렬 부분을 가로지르거나 통과함). 참조shapes.shape_dist_traveled 추천.

    calendar.txt

    분야 명 추천
    모든 분야 포함calendar.service_name 필드는 또한 사람의 가독성을 높일 수 있습니다.GTFS , 비록 이것이 사양에서 채택되지는 않았지만.

    calendar_dates.txt

    분야 명 추천
    모든 분야 포함calendar.service_name 필드는 또한 사람의 가독성을 높일 수 있습니다.GTFS , 비록 이것이 사양에서 채택되지는 않았지만.

    fare_attributes.txt

    분야 명 추천
    agency_id 피드에 대행사가 하나만 있는 경우에도 포함되어야 합니다. (포함할 권장 사항도 참조하십시오.agency_id \~에agency.txt 그리고routes.txt )
    요금 시스템을 정확하게 모델링할 수 없는 경우 더 이상의 혼동을 피하고 공백으로 두십시오.
    요금 포함(fare_attributes.txt 그리고fare_rules.txt ) 가능한 한 정확하게 모델링합니다. 요금을 정확하게 모델링할 수 없는 극단적인 경우 요금이 저렴한 것이 아니라 더 비싼 것으로 표시되어야 고객이 부족한 요금으로 탑승을 시도하지 않습니다. 대다수의 요금을 올바르게 모델링할 수 없는 경우 피드에 요금 정보를 포함하지 마십시오.

    fare_rules.txt

    분야 명 추천
    모든 분야 요금 시스템을 정확하게 모델링할 수 없는 경우 더 이상의 혼동을 피하고 공백으로 두십시오.
    요금 포함(fare_attributes.txt 그리고fare_rules.txt ) 가능한 한 정확하게 모델링합니다. 요금을 정확하게 모델링할 수 없는 극단적인 경우 요금이 저렴한 것이 아니라 더 비싼 것으로 표시되어야 고객이 부족한 요금으로 탑승을 시도하지 않습니다. 대다수의 요금을 올바르게 모델링할 수 없는 경우 피드에 요금 정보를 포함하지 마십시오.

    shapes.txt

    분야 명 추천
    모든 분야 이상적으로는 공유되는 선형의 경우(예: 도로 또는 트랙의 동일한 세그먼트에서 경로 1과 2가 작동하는 경우) 선형의 공유 부분이 정확히 일치해야 합니다. 이는 고품질 운송 지도 제작을 용이하게 하는 데 도움이 됩니다.
    정렬은 차량이 주행하는 통행 우선권의 중심선을 따라야 합니다. 이것은 지정된 차선이 없는 경우 도로의 중심선이거나 차량이 이동하는 방향으로 이동하는 도로 측면의 중심선일 수 있습니다.

    선형은 연석 정류장, 플랫폼 또는 탑승 위치로 "삐죽삐죽"해서는 안 됩니다.
    shape_dist_traveled 두 가지 모두에 제공되어야 합니다.shapes.txt 그리고stop_times.txt 얼라인먼트에 루핑 또는 인라인이 포함된 경우(차량이 한 번의 트립으로 얼라인먼트의 동일한 부분을 가로지르거나 통과함).
    차량이 주행 중 특정 지점에서 경로 정렬을 되돌리거나 교차하는 경우, shape_dist_traveled 포인트의 일부가 어떻게shapes.txt 줄은 기록과 일치합니다.stop_times.txt .
    그만큼shape_dist_traveled 이 필드를 사용하면 기관에서 정차하는 방법을 정확히 지정할 수 있습니다.stop_times.txt 파일은 각각의 모양에 맞습니다. 에 사용할 공통 값shape_dist_traveled 필드는 차량이 이동한 모양의 시작 부분으로부터의 거리입니다(주행 거리계 판독과 같은 것을 생각하십시오).
  • 경로 정렬(shapes.txt )은(는) 여행이 제공되는 정류장 위치에서 100미터 이내에 있어야 합니다.
  • 다음과 같이 정렬을 단순화합니다.shapes.txt 관련 없는 점을 포함하지 않습니다(즉, 직선 세그먼트에서 추가 점을 제거합니다. 선 단순화 문제에 대한 논의 참조).
    		•

    frequencies.txt

    분야 명 추천
    모든 분야 에서 참조하는 이동의 실제 중지 시간은 무시됩니다.frequencies.txt ; 정류장 사이의 이동 시간 간격만 빈도 기반 이동에 중요합니다. 명확성/사람의 가독성을 위해 에 참조된 여행의 첫 번째 중지 시간을 권장합니다.frequencies.txt 00:00:00에 시작해야 합니다(첫 번째arrival_time 00:00:00의 값).
    block_id 빈도 기반 여행에 제공될 수 있습니다.

    transfers.txt

    transfers.transfer_type 은 에 정의된 4가지 값 중 하나일 수 있습니다.GTFS . 이러한 transfer_type 정의는GTFS 아래 사양 은 이탤릭체 로 추가 실습 권장 사항과 함께 제공됩니다.

    분야 명 추천
    transfer_type 0 또는 (비어 있음): 권장되는 경로 간 환승 지점입니다.
    우수한 옵션을 포함하는 환승 기회가 여러 번 있는 경우(예: 추가 편의 시설이 있는 환승 센터 또는 탑승 시설/플랫폼이 인접하거나 연결된 역) 권장 환승 지점을 지정합니다.
    1: 두 경로 사이의 정기 환승 지점입니다. 출발 차량은 승객이 경로 간 환승에 충분한 시간을 두고 도착 차량을 기다릴 것으로 예상됩니다.
    이 전송 유형은 안정적으로 전송하기 위해 필요한 간격을 무시합니다. 예를 들어 Google 지도는 승객이 안전하게 환승하는 데 3분이 걸린다고 가정합니다. 다른 응용 프로그램은 다른 기본값을 가정할 수 있습니다.
    2: 이 환승은 연결을 보장하기 위해 도착과 출발 사이에 최소한의 시간이 필요합니다. 전송에 필요한 시간은 다음과 같이 지정됩니다. min_transfer_time .
    정류장 간 이동 시간을 증가시키는 장애물이나 기타 요인이 있는 경우 최소 이동 시간을 지정하십시오.
    3: 이 위치에서는 노선 간 환승이 불가능합니다.
    물리적 장벽으로 인해 환승이 불가능한 경우 또는 횡단보도가 어렵거나 보행자 네트워크의 틈으로 인해 환승이 안전하지 않거나 복잡할 경우 이 값을 지정합니다.
    좌석 내(블록) 환승이 여행 사이에 허용되는 경우 도착하는 여행의 마지막 정류장은 출발하는 여행의 첫 번째 정류장과 같아야 합니다.

    feed_info.txt

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

    분야 명 추천
    feed_start_date &feed_end_date 포함되어야 함
    feed_version 포함되어야 함
    feed_contact_email &feed_contact_url 하나 이상 제공

    사례별로 정리된 실습 권장 사항

    이 섹션에서는 파일 및 필드 전반에 영향을 미치는 특정 사례를 다룹니다.

    루프 루트

    루프 루트에서 차량의 이동은 같은 위치(때로는 환승 센터 또는 환승 센터)에서 시작하고 끝납니다. 차량은 일반적으로 지속적으로 작동하며 차량이 루프를 계속할 때 승객이 탑승할 수 있도록 합니다.

    따라서 라이더에게 차량이 가고 있는 방향을 보여주기 위해 헤드 사인 권장 사항을 적용해야 합니다.

    이동 방향 변경을 나타내려면 stop_headsigns 를 제공하십시오.stop_times.txt 파일. stop_headsign 은 정의된 정류장에서 출발하는 이동 방향을 설명합니다. 여행의 각 정류장에 stop_headsigns 를 추가하면 여행을 따라 헤드사인 정보를 변경할 수 있습니다.

    단일 순환 여행을 정의하지 마십시오.stop_times.txt 두 끝점 사이에서 작동하는 경로에 대한 파일입니다(예: 동일한 버스가 앞뒤로 이동할 때). 대신 여행을 두 개의 별도 여행 방향으로 나눕니다.

    순환 여행 모델링의 예:

    • 각 정류장마다 헤드 사인을 변경하는 순환 여행
    trip_id 도착 시간 출발 시각 stop_id stop_sequence stop_headsign
    여행_1 06:10:00 06:10:00 stop_A 1 "비"
    여행_1 06:15:00 06:15:00 stop_B 2 "씨"
    여행_1 06:20:00 06:20:00 stop_C 삼 "디"
    여행_1 06:25:00 06:25:00 stop_D 4 "이자형"
    여행_1 06:30:00 06:30:00 stop_E 5 "ㅏ"
    여행_1 06:35:00 06:35:00 stop_A 6 ""
    • 두 개의 헤드 사인이 있는 순환 여행
    trip_id 도착 시간 출발 시각 stop_id stop_sequence stop_headsign
    여행_1 06:10:00 06:10:00 stop_A 1 "배 밖으로"
    여행_1 06:15:00 06:15:00 stop_B 2 "배 밖으로"
    여행_1 06:20:00 06:20:00 stop_C 삼 "배 밖으로"
    여행_1 06:25:00 06:25:00 stop_D 4 "인바운드"
    여행_1 06:30:00 06:30:00 stop_E 5 "인바운드"
    여행_1 06:35:00 06:35:00 stop_F 6 "인바운드"
    여행_1 06:40:00 06:40:00 stop_A 7 ""
    분야 명 추천
    trips.trip_id 단일 트립으로 루프에 대한 전체 왕복을 모델링합니다.
    stop_times.stop_id 첫 번째/마지막 정류장을 두 번 포함stop_times.txt 루프인 여행을 위해. 아래 예. 종종 루프 경로에는 전체 루프를 여행하지 않는 첫 번째 및 마지막 여행이 포함될 수 있습니다. 이러한 여행도 포함하십시오.
    trip_idstop_idstop_sequence
    9000 101 1
    9000 102 2
    9000 103 삼
    9000 101 4
    trips.direction_id 루프가 반대 방향(즉, 시계 방향 및 시계 반대 방향)으로 작동하는 경우 다음을 지정합니다.direction_id ~처럼0 또는1 .
    trips.block_id 동일한 연속 루프 트립을 나타냅니다.block_id .

    올가미 루트

    올가미 경로는 루프 경로와 방향 경로의 측면을 결합합니다.

    예:
    지하철 노선( 시카고 )
    시내 노선 버스 교외 ( 세인트 알버트 또는 에드먼턴 )
    CTA 브라운 라인( CTA 웹사이트 그리고 트랜짓피드 )
    분야 명 추천
    trips.trip_id "차량 왕복"의 전체 범위(그림 참조 ~ 위에 ) A에서 B로 그리고 다시 A로의 여행으로 구성됩니다. 전체 차량 왕복 여행은 다음과 같이 표현할 수 있습니다.
  • ㅏ__ 하나의__ trip_id 가치/기록trips.txt
  • 다수의 trip_id 값/기록trips.txt , 로 표시된 연속 이동block_id .
    		•
    stop_times.stop_headsign AB 섹션의 정류장은 양방향으로 통과합니다.stop_headsign 이동 방향을 쉽게 구분할 수 있습니다. 따라서 제공하는stop_headsign 다음 trips.example_table에 권장됩니다.
    예:
    "A에서 B로"
    "ㅏ"
    시카고 교통국의 퍼플 라인
    "남향에서 루프로"
    "루프를 통해 북쪽으로"
    "린든에서 북쪽으로"
    에드먼턴 트랜짓 서비스 버스 노선, 여기 39
    "러더포드"
    "센츄리 파크"
    trip.trip_headsign 여행 헤드 사인은 일정에 표시된 것처럼 여행에 대한 전체적인 설명이어야 합니다. "Linden to Linden via Loop"(시카고 예) 또는 "A to A via B"(일반 예)일 수 있습니다.

    지점

    일부 경로에는 분기가 포함될 수 있습니다. 정렬 및 정지는 이러한 분기 간에 공유되지만 각각은 고유한 정지 및 정렬 섹션을 제공합니다. 지점 간의 관계는 아래의 추가 지침을 사용하여 경로 이름, 헤드 사인 및 여행 약칭으로 표시할 수 있습니다.

    분야 명 추천
    모든 분야 지선 노선을 명명할 때 다른 승객 정보 자료를 따르는 것이 좋습니다. 다음은 두 가지 경우에 대한 설명과 예입니다.
    시간표와 도로 표지판이 두 개의 뚜렷하게 명명된 경로(예: 1A 및 1B)를 나타내는 경우 이를 그대로 표시합니다.GTFS , 사용하여route_short_name 및/또는route_long_name 필드. 예: GoDurham 대중 교통 루트 2, 2A, 2B 대부분의 경로에서 공통 정렬을 공유하지만 여러 측면에서 다릅니다.
    • Route 2는 대부분의 시간을 실행하는 핵심 서비스입니다.
    • 2번 국도는 메인 스트리트의 밤, 일요일, 공휴일에 편차가 있습니다.
    • 루트 2A와 2B는 월요일부터 토요일까지 낮 시간에 운행합니다.
    • Route 2B는 공유 정렬 경로의 편차에서 추가 정류장을 제공합니다.
    기관 제공 정보에 지점이 동일한 이름의 경로로 설명되어 있는 경우 다음을 활용하십시오.trips.trip_headsign ,stop_times.stop_headsign , 및/또는trips.trip_short_name 필드. 예: 고삼각형 루트 300 시간대에 따라 다른 장소로 이동합니다. 피크 통근 시간에는 도시를 드나드는 근로자를 수용하기 위해 표준 경로에 추가 다리가 추가됩니다.

    자주 묻는 질문(FAQ)

    이들은 왜GTFS 모범 사례가 중요합니까?

    목표GTFS 모범 사례는 다음과 같습니다.

    • 대중 교통 앱에서 최종 사용자 고객 경험을 개선하기 위해
    • 소프트웨어 개발자가 애플리케이션, 제품 및 서비스를 더 쉽게 배포하고 확장할 수 있도록 광범위한 데이터 상호 운용성을 지원합니다.
    • 의 사용을 촉진GTFS 다양한 애플리케이션 카테고리에서 (여행 계획에 대한 원래 초점을 넘어서)

    조정하지 않고GTFS 모범 사례, 다양한GTFS -소비하는 응용 프로그램은 조정되지 않은 방식으로 요구 사항과 기대치를 설정할 수 있으며, 이는 요구 사항 및 응용 프로그램별 데이터 세트를 다양하게 만들고 상호 운용성을 떨어뜨립니다. 모범 사례가 발표되기 전에는 올바르게 구성된 것이 무엇인지에 대해 더 큰 모호성과 불일치가 있었습니다.GTFS 데이터.

    어떻게 개발되었습니까? 누가 개발했습니까?

    이 모범 사례는 17개 조직으로 구성된 작업 그룹에서 개발했습니다.GTFS , 앱 제공업체 및 데이터 소비자, 대중교통 제공업체 및 에 광범위하게 관여하는 컨설턴트 포함GTFS . 작업 그룹은 Rocky Mountain Institute 에 의해 소집되고 촉진되었습니다.

    작업 그룹 구성원은 각 모범 사례에 대해 투표했습니다. 대부분의 모범 사례는 만장일치로 승인되었습니다. 소수의 경우 모범 사례가 대부분의 조직에서 승인되었습니다.

    왜 그냥 바꾸지GTFS 참조?

    좋은 질문! 사양, 데이터 사용량 및 요구 사항을 검사하는 프로세스는 실제로 사양에 대한 일부 변경을 촉발했습니다( GitHub의 닫힌 풀 요청 참조). 사양 참조 수정 사항은 모범 사례보다 더 높은 수준의 조사 및 의견을 반영해야 합니다. 그러나 모범 사례 권장 사항의 명확한 집합에 동의해야 했습니다.

    작업 그룹은 일부GTFS 모범 사례는 결국 핵심의 일부가 될 것입니다.GTFS 참조.

    하다GTFS 검증 도구는 이러한 모범 사례를 준수하는지 확인합니까?

    현재 모든 모범 사례를 준수하는지 확인하는 유효성 검사 도구는 없습니다. 다양한 유효성 검사 도구는 이러한 모범 사례 중 일부를 준수하는지 확인합니다. GTFS 검사기 도구 목록은 GTFS 검사기를 참조하세요. 이러한 권장사항을 참조하는 GTFS 검사기 도구를 작성하는 경우 specifications@mobilitydata.org로 이메일을 보내주세요.

    저는 교통 기관을 대표합니다. 소프트웨어 서비스 제공업체와 공급업체가 이러한 모범 사례를 따르도록 하려면 어떤 단계를 수행해야 합니까?

    공급업체 또는 소프트웨어 서비스 제공업체에 이 모범 사례를 참조하도록 하십시오. 다음을 참조하는 것이 좋습니다.GTFS 모범 사례 URL 및 조달의 핵심 사양 참조GTFS - 소프트웨어를 생산하고 있습니다.

    눈치채면 어떻게 해야 하나요GTFS 데이터 피드가 이러한 모범 사례를 준수하지 않습니까?

    제안된 feed_contact_email 또는 feed_contact_url 필드를 사용하여 피드의 연락처를 식별합니다.feed_info.txt 존재하는 경우 또는 대중 교통 기관 또는 사료 생산자 웹 사이트에서 연락처 정보를 찾습니다. 피드 생산자에게 문제를 전달할 때 특정GTFS 논의 중인 모범 사례. ( "이 문서에 연결" 참조).

    모범 사례에 대한 수정/추가를 제안하고 싶습니다. 어떻게 해야 하나요?

    specifications@mobilitydata.org로 이메일을 보내거나 GitHub GTFS Best Practices repo에서 문제 또는 풀 요청을 엽니다.

    어떻게 참여합니까?

    이메일 사양 @mobilitydata.org .

    이 문서 정보

    목표

    유지의 목적GTFS 모범 사례는 다음과 같습니다.

    • 대중 교통 데이터의 더 나은 상호 운용성 지원
    • 대중 교통 앱에서 최종 사용자 고객 경험 개선
    • 소프트웨어 개발자가 애플리케이션, 제품 및 서비스를 더 쉽게 배포하고 확장할 수 있도록 합니다.
    • 의 사용을 촉진GTFS 다양한 애플리케이션 카테고리에서 (여행 계획에 대한 원래 초점을 넘어서)

    공표된 제안 또는 수정 방법GTFS 모범 사례

    GTFS 애플리케이션과 관행은 발전하므로 이 문서는 수시로 수정되어야 할 수도 있습니다. 이 문서의 수정안을 제안하려면 GTFS Best Practices GitHub repository 에서 풀 요청을 열고 변경 사항을 옹호하세요. 의견이 있으시면 specifications@mobilitydata.org로 이메일을 보내실 수 있습니다.

    이 문서에 연결

    사료 생산자에게 올바른 형성을 위한 지침을 제공하려면 여기를 링크하십시오.GTFS 데이터. 각 개별 권장 사항에는 앵커 링크가 있습니다. 페이지 내 앵커 링크에 대한 URL을 얻으려면 권장 사항을 클릭하십시오.

    만약GTFS -소비 응용 프로그램은 요구 사항 또는 권장 사항을 만듭니다.GTFS 여기에 설명되지 않은 데이터 관행이 있는 경우 이러한 일반적인 모범 사례를 보완하기 위해 해당 요구 사항 또는 권장 사항이 포함된 문서를 게시하는 것이 좋습니다.

    GTFS 모범 사례 워킹 그룹

    그만큼GTFS 모범 사례 워킹 그룹은 2016-17년 Rocky Mountain Institute 에서 소집되었으며 대중 교통 제공자,GTFS - 일반적인 관행과 기대치를 정의하기 위해 응용 프로그램, 컨설턴트 및 학술 기관을 소비합니다.GTFS data.이 작업 그룹의 구성원은 다음과 같습니다.

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