Есть пять обязательных файлов: agency.txt, routes.txt, trips.txt, stop_times.txt и stops.txt. Для псевдо-GTFS, которая предназначена только для целей вычислительной доступности, многие необязательные поля в обязательных файлах могут быть опущены, как и все необязательные файлы. Однако вы можете скопировать настоящие или создать их, так как они могут быть полезны для этой цели (например, люди будут учитывать стоимость проезда при выборе способа передвижения, поэтому вы можете использовать fares.txt).
Внимательно прочитайте спецификацию.
агентство
Если допустимо представить, что все маршруты обслуживаются одним и тем же агентством, ваш вариант может быть таким:
agency_id,agency_name,agency_url,agency_timezone,agency_lang,agency_phone
XXX,My Awesome Agency,http://example.com,,,
то есть вам нужны только первые три поля.
agency.txt предназначен для отображения:
Одно или несколько транспортных агентств, предоставляющих данные в этом фиде.
маршруты
Тебе нужно:
route_id (первичный ключ)route_short_nameroute_long_nameroute_type (должен быть в диапазоне 0–7; указывает режим)
Пример:
route_id,agency_id,route_short_name,route_long_name,route_desc,route_type,route_url,route_color
12860326,XXX,12860326,12860326,,3,,
12860386,XXX,12860386,12860386,,3,,
12867184,XXX,12867184,12867184,,3,,
Я не знаю, что делать с маршрутами, которым не назначен маршрут в данных вашего примера. Я также не знаю, что означает order. Возможно, order - это название маршрута? Пока вы можете придумать что-то похожее на идентификатор «маршрута», вы можете его использовать. Для справки, «маршрут» определяется как:
Маршрут — это группа поездок, которые отображаются для пассажиров как единый сервис.
поездки
Поездка – это последовательность из двух или более остановок в определенное время.
Тебе нужно:
trip_id (первичный ключ)route_id (внешний ключ)service_id (внешний ключ)
Пример:
route_id,service_id,trip_id,trip_headsign,direction_id,block_id,shape_id
12860326,1,1,,1,,12860326
12860326,1,2,,1,,12860326
12860386,1,1,,1,,12860386
12860386,1,2,,2,,12860386
direction_id, хотя и является необязательным, имеет тенденцию быть довольно полезным, и у меня было несколько приложений, использующих GTFS, требующих его, несмотря на его необязательный статус.
service_id сложно и работает в сочетании с календарными датами. Это позволяет GTFS легко отображать, скажем, «нормальное» обслуживание в будние дни и обслуживание в праздничные дни, когда праздники выпадают на будние дни. Для ваших целей вы, вероятно, можете просто использовать 1 для всего, но это зависит от вашего приложения и когда ваши данные AVL были собраны. Когда я работал над подобным приложением, я поддерживал в своей базе данных справочную таблицу, которая сообщала мне, является ли конкретная дата государственным праздником, и/или школьным праздником, и/или во время университетских семестров, потому что автобусные маршруты менялись в соответствии со студентами. .
shape_id является необязательным, но будет иметь решающее значение, если вы хотите нарисовать свои маршруты на картах или использовать такие инструменты, как OpenTripPlanner.
стоп_время
Время прибытия и отправления транспортного средства с отдельных остановок для каждой поездки.
Тебе понадобится:
stop_id (первичный ключ)trip_id (внешний ключ)arrival_timedeparture_timestop_sequence
Это потребует наибольшей работы при написании сценариев. Он будет на несколько порядков больше, чем все остальные файлы вместе взятые.
stop_id и trip_id счастливо относятся к уже определенным остановкам и поездкам. departure_time и arrival_time будут находиться в двух строках данных AVL, и во многих случаях фактическое определение момента прибытия службы на остановку является наиболее сложным аспектом этой задачи. Это проще с доступом к данным смарт-карт пассажиров, и когда услуга фактически останавливается, вы, вероятно, найдете пространственные кластеры записей AVL, поскольку транспортное средство не перемещалось в течение определенного периода времени. Однако, если остановка пуста и никто не хочет выходить, будет трудно определить, когда служба действительно «прибыла» на остановку, особенно потому, что поведение водителя иногда может измениться, если он не намерен делать это. остановка, когда она запланирована (например, ехать быстрее или сокращать путь, если они не видят, что кто-то ждет). В вашем случае значение speed, вероятно, будет полезным, но будьте осторожны, чтобы не спутать остановку для пассажиров с перекрестком.
stop_sequence является необязательным, но это еще один случай, когда приложения часто ожидают его существования. В любом случае, если ваш скрипт не может идентифицировать stop_sequence, то вы, вероятно, не можете правильно изобрести этот файл.
Пример:
trip_id,arrival_time,departure_time,stop_id,stop_sequence,stop_headsign,pickup_type,drop_off_type,shape_dist_traveled
1,00:05:07,00:05:54,22018,1,,1,1,0
1,00:07:16,00:08:01,22557,2,,1,1,39
1,00:10:56,00:10:56,22559,3,,1,1,76
Указание времени пребывания является необязательным, поэтому, если это слишком сложно решить, arrival_time и departure_time действительно могут быть одним и тем же моментом.
На практике pickup_type и drop_off_type очень важны, но, как правило, их невозможно определить только по данным AVL, если только ваш сборщик AVL действительно не подумал о поддержке GTFS в своем архиве... что, к сожалению, очень маловероятно. Вероятно, вам просто нужно всегда разрешать и то, и другое, если у вас нет дополнительной информации, которую вы можете вставить (например, «все поездки по маршруту 1 после остановки 4 в будние дни выпускают только пассажиров по вечерам»).
остановки
stop_id (первичный ключ)stop_namestop_lonstop_lat
Вы сказали, что у вас уже есть это, и это здорово. На самом деле проблема заключается в том, чтобы заставить это взаимодействовать с stop_times через внешний ключ stop_id. Данные AVL, с которыми я работал, к счастью, определили, когда услуги были остановлены и на какой остановке они были остановлены, используя тот же код, что и в представлении расписания GTFS.
календарь
Чтобы получить хорошие результаты с помощью таких инструментов, как OpenTripPlanner, вам, вероятно, потребуется включить файл calendar.txt. Это также помогает определить период действия вашей псевдо-GTFS, если вы используете подход моделирования определенного периода времени. Например:
service_id,monday,tuesday,wednesday,thursday,friday,saturday,sunday,start_date,end_date
1,1,1,1,1,1,0,0,20160224,20160226
2,0,0,0,0,0,1,1,20160224,20160226
3,0,0,0,0,0,1,0,20160224,20160226
Это указывает на то, что смоделированный период для этих услуг — с 24 июня 2016 г. по 26 июня 2016 г. Любой запрошенный маршрут за пределами этого диапазона имеет неопределенное время в пути. Я рекомендую вам выбрать период не более недели: больше, и приложения, потребляющие GTFS, начнут бороться с объемом данных. Реальные данные GTFS выигрывают от избыточности, которой не могут дать «псевдоданные».
формы
Не беспокойтесь о shape_dist_traveled, я просто использую для этого фиктивную информацию (монотически возрастающую): ее можно вывести из формы, если только форма не слишком обобщена.
Пример:
shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled
12860386,-22.9,-43.3,1,1
12860386,-22.0,-42.9,2,2
Примечание
Общая идея состоит в том, чтобы использовать имеющиеся данные AVL для выполнения минимальных требований к транзитному каналу, соответствующему спецификации. Вероятно, вам потребуется написать собственные сценарии для создания этих файлов, поскольку для данных AVL не существует стандарта. Вы можете создать некоторую информацию, и вам, вероятно, потребуется: большинство приложений будут вызывать исключения, когда вы попытаетесь использовать неполный канал. Действительно, по моему опыту, довольно много приложений будут иметь проблемы с фидами, которые соответствуют только минимальным требованиям, потому что программа плохая, а большинство реальных данных немного выходят за рамки минимального стандарта.
Вы, вероятно, обнаружите недостатки в данных AVL, которые затруднят их использование. Наиболее заметным примером этого являются маршруты, которые работали, но AVL не работал. В таком случае ваша псевдо-GTFS не будет точно представлять транспортную систему на практике. Их почти невозможно обнаружить.
В данном случае я не понимаю различий между вашими полями order, line и route. Вам нужно будет определить, где они лучше всего подходят; Я проигнорировал их, потому что не понимаю, что они представляют. Вам необходимо привести схему AVL в соответствие с концепциями GTFS.
Транзитные системы, как правило, очень сложны с множеством небольших исключений. Вы можете в конечном итоге исключить некоторые особо аномальные случаи.
Ваши значения широты и долготы выглядят не очень точными: если это реальные данные, вы, вероятно, не сможете использовать shapes.txt. Попробуйте запросить более точную информацию о положении автомобиля.
person
alphabetasoup
schedule
26.04.2016
