2014-11-12 2 views
1

У меня когда-то был очень большой размер файла gtfs zip - действителен в течение 6 месяцев, но это неэкономично для загрузки такого большого размера данных в низкий ресурс (например, 2 гигабайт памяти и 10-гигабайтный жесткий диск) сервер EC2.делят данные по gtfs на более мелкие

Я надеюсь, что вы сможете разделить эти большие размерные gtfs на 3 небольших файла gtfs zip с 2-месячным периодом (6 мес./3 файла) с допустимыми данными, конечно, это означает, что мне нужно будет заменять данные каждые 2 месяца.

Я нашел программу питона, что достижение противоположной цели MERGE здесь https://github.com/google/transitfeed/blob/master/merge.py (это очень хороший проект питона кстати.)

я очень благодарен за любой указатель.

С уважением,

Dunn.

ответ

1

Стоит отметить, что записи в файле stop_times.txt обычно являются самыми большими всплесками памяти, когда дело доходит до загрузки канала GTFS. Поскольку большинство систем не реплицирует поездки + stop_times для дат, когда эти поездки активны, сокращение календаря обслуживания, вероятно, не спасет вас.

Тем не менее, есть некоторые инструменты для нарезки и обрезки GTFS. Проверьте инструмент OneBusAway GTFS трансформатор, например:

http://developer.onebusaway.org/modules/onebusaway-gtfs-modules/1.3.3/onebusaway-gtfs-transformer-cli.html

+0

Ваш ответ как разъяснены и решены 2 проблемы я есть. учитывая состояние данных gtfs нашего города Калгари, я выполнил как сокращение данных меньшим, избавившись от старых истекших данных И разрешило 2 идентичных результата, возвращающихся из поиска - это из-за route.txt имеет пары почти одинаковых за исключением route_id для разных периодов времени в файле calendar.txt. Извините, я не упомянул в своем первоначальном вопросе, чтобы избежать смешивания и путаницы, но вот полное объяснение https://groups.google.com/forum/#!topic/onebusaway-developers/fsN7D4lA1bA – Dung