Маршруты общественного транспорта

Надо ещё где-то расписать, как эти маршруты обозначать, и больной вопрос решить, где ставить остановки трамвая – на рельсах или на месте ожидания трамвая, чтобы были остановки для каждого маршрута в нужную сторону.

Как правильно пользоваться этими ролями?:

Members

* way - (blank)
* way - forward
* way - backward
* node - stop_<number>
* node - forward_stop_<number>
* node - backward_stop_<number>
* node - stop
* node - forward_stop
* node - backward_stop
* way - тр. средство едет туда-обратно
* way - forward - едет по направлению вея
* way - backward - против
* node - stop_<number> - устаревшая форма, не использовать. менять на stop и выстраивать *stop в нужном порадке
* node - forward_stop_<number> - аналогично
* node - backward_stop_<number> - аналогично
* node - stop - на остановке останавливается по пути "туда" и "обратно"
* node - forward_stop - не правильно
* node - backward_stop - не правильно
* node - forward:stop - остановка по пути "туда"
* node - backward:stop - остановка по пути "обратно"

Ух ты. Получается, мой маршрут №108 корректен? Остановки выстроил в порядке прохождения. Конечные - просто stop.
А то были некоторые сомнения.

shadowjack упомянул в irc-канале, что рисование маршрутов - это только начальный этап.
Дальше будет планирование маршрута на общественном транспорте с учетом расписаний и возможных пересадок.

Это сообщение пишу, чтобы зафиксировать, что удалось найти по этой теме и стимулировать интерес других

Название темы: Intermodal Journey Planning, Intermodal Journey Planner

Обнаружился проект под названием SITI с открытым кодом: http://smagris3.uv.es/siti/ (на испанском)
Презентационные слайды: http://www.slideshare.net/jgui/an-open-source-multimodal-journey-planning-system-based-on-de-facto-standards

Причем этот проект использует OpenStreetMap как источник векторных данных.
Так же проект использует Google Transit Feed Specification (GTFS) для описания расписаний общественного транпорта
GTFS - это открытый формат, разработанный Google. Он используется, в частности, для того чтобы предприятия общественного транспорта могли загружать расписания в Google Transit
Подробнее о GTFS: http://code.google.com/intl/ru/transit/spec/transit_feed_specification.html
Пример данных: http://spreadsheets.google.com/pub?key=puMHBiWYEbXT0UxQGLDpuBA&gid=11
Некоторые средства для подготовки и просмотра GTFS: http://code.google.com/p/googletransitdatafeed/

Работающий прототип от проекта SITI: http://ssiti.uv.es/valencia/ Я попробовал, какой-то маршрут нарисовался с указанием точного времени посадки в транспорт
Исходники проекта SITI: https://graphserver.svn.sourceforge.net/svnroot/graphserver/branches/juangui/ написан на ruby. Есть желающие его попробовать?

Точное время посадки, это для особо одаренных европейцев :slight_smile: нам тако не надь. А вот сквозные маршруты, это здорово! Спасибо, vvoovv, за доклад из ирки. Реально интересные вещи вы там выдумываете.

Еще несколько добавлений по поводу планнера для общественного транпорта.

Указанный выше проект SITI сделан на основе проекта Graphserver, причем за год, прошедший с выхода прототипа SITI, Graphserver ушел далеко вперед.
С Graphserver можно работать на питоне, а ruby больше не поддерживает.
В Graphserver также можно загружать OSM и GTFS

Страница проекта Graphserver с примерами кода:
http://bmander.github.com/graphserver/

В листе рассылки osm-talk было обсуждение год назад:
http://lists.openstreetmap.org/pipermail/talk/2008-December/032439.html
Есть специальный лист рассылки talk-transit:
http://lists.openstreetmap.org/pipermail/talk-transit/

Группа разработчиков планнеров для общественного транпорта: http://groups.google.com/group/transit-developers
Тут выкладывают ссылки на открытые GTFS-данные: http://www.gtfs-data-exchange.com/

У кого Linux и кто интересуется данной темой, попробуйте Graphserver:
http://bmander.github.com/graphserver/

Странно, я думал что это более продвинутый вариант. В Потлатче, например, нет возможности менять порядок следования членов. Да и вообще в XML вроде как порядок следования элементов ничего не значит, если нет соответствующего тега.

Как рисовать остановки? На рельсах или по месту расположения, как автобус, справа по ходу движения?

Как перечислять остановки? На линейных маршрутах только в одну сторону или в обе? На кольцевых? На полукольцевых (когда половина маршрута линейная, а другая половина – кольцевая?

Может начать писать статью в Вики?
http://wiki.openstreetmap.org/wiki/RU:Tag:route=tram или
http://wiki.openstreetmap.org/wiki/RU:Relation:route

ЗЫ. У нас ещё сохранился кусок одноколейного пути на части одного маршрута :slight_smile:

В XML порядок тегов, конечно, значит. Атрибутов - нет. Члены отношения описываются xml-тегами. С API 0.6 гарантируется сохранение порядка членов в отношении (осмовских тегов - не гарантируется). Раз в Потлатче нельзя менять порядок членов, значит - нужно использовать Josm для этой задачи.

Я думаю, остановки ставить также, как и у автобусов - на месте ожидания и/или посадки-высадки. Перечислять - если остановки две (слева и справа от маршрута), то естественно, в обе стороны. Если одна на рельсах/дороге - наверное, один раз (я так понимаю, stop как раз для этого). Но по-моему, это немного бредово, и было бы логично перечислять все остановки в порядке следования. forward:stop использовать до конечной, backward:stop - после. Хотя эта схема мне тоже не нравится… Нужно еще как-то обозначать остановки с только посадкой и только высадкой, остановки по требованию…

Хм, а если два автобуса едут по линии форвардом в разные стороны?

Если для маршрута А линия 12345 включена с ролью forward, значит этот маршрут едет по этой линии по её (линии) направлению. Если для маршрута Б линия 12345 включена с ролью backward, значит, этот маршрут едет по этой линии против её направления.
Если линия включена в маршрут без роли, то это интерпретируется так, что маршрут проходит по ней в обе стороны.

То есть роль forward/backward для линий - это не “маршрут туда/обратно”, а “в какую сторону едет на этой линии”.
По сути, мы составляем из линий обычное кольцо без указания конечных пунктов.
А уже остановки указываются stop’ами.

Есть в этой системе логическая нестройность. forward задаёт направление относительно текущего вея, а forward:stop - относительно всего маршрута. Может случиться, что на backward находятся остановки forward:stop, что сбивает с толку.

Есть. :3
Может. Но я, например, для уменьшения путаницы сначала размещаю в релейшене кольцо из линий, а потом отдельно - натыкиваю по порядку остановок. Мухи отдельно, котлеты отдельно, все довольны.

Единственное, что неудобно - приходится рвать круги (junction = roundabout) и создавать аналогичный релейшн (type = junction, junction = roundabout, кажется, так). А он пока что пропозальный.

Получается, система неполная. Роутинг никак не узнает, какая из двух остановок соответствует нужному направлению движения, и посадит на автобус не в ту сторону.

Это да, проблема, но если мы хотим роутить только по остановкам без линий - проблемы нет.

1 Like

Почему не узнает? У него есть замкнутый кольцевой список остановок. В какую сторону меньше ехать до цели - туда и посадит.

А, и правда. Только список не кольцевой в общем случае (есть набор forward:stop и backward:stop, пересадка с одного на второй пешком и за доп. плату).

В принципе, если от каждой остановки в выбранном наборе опустить перпендикуляр на вей отношения, то можно и с путями получить?

API 0.6 может гарантировать что угодно, но мне кажется (я с хмл знаком очень поверхностно) не каждый парсер обязан вытаскивать элементы именно в таком порядке, как они записаны… Поэтому указание stop_1 … stop_N мне кажется более универсальным способом…

Разумеется. Но как раз здесь-то (если перпендикуляр упадет на вей, где автобус едет и туда, и обратно) в общем случае неясно, с какой остановки (из пары) в какую сторону можно уехать. :3

И если, например, маршрут в обе стороны - одна и та же линия (без backward/forward), то нельзя понять, остановку с какой стороны дороги нужно использовать. Из здравого смысла можно предположить, что остановки обходятся против часовой стрелки (в странах с правосторонним движением), но наверняка сказать никогда нельзя.

Порядок нод в вее задаётся именно их порядком в xml.
Вроде пока проблем не возникало