Это тот самый маршрут с кольцом, который ты предложил рисовать одной линией.
Если он кольцевой, то почему на сайте он нарисован как двусторонний? На сайте ошибка, выходит, потому что нет направления «обратно».
Рассматривая ÖPNV-Karte, заметил интересную вещь. Он не поддерживает роли *:stop, зато поддерживает *_stop, об этом написано и на соответствующей вики-странице: http://wiki.openstreetmap.org/wiki/%C3%96pnvkarte
Такие же роли *_stop указаны в русском (а также немецком и французском) описании отношения: http://wiki.openstreetmap.org/wiki/RU:Relation:route
А вот в английской вики роли *:stop: http://wiki.openstreetmap.org/wiki/Relation:route
Информация об использовании этих ролей (привязка к линии или направлению маршрута) тоже противоречивая — в одном месте одно, в другом другое. ÖPNV-Karte поддерживает вариант привязки к направлению маршрута.
Как разгребать весь этот бардак с этими forward и backward? 
Попытался откорректировать под ÖPNV-Karte и навигацию городские маршруты по Щёлково:
http://www.openstreetmap.org/browse/relation/962843
http://www.openstreetmap.org/browse/relation/962835
http://www.openstreetmap.org/browse/relation/962904
http://www.openstreetmap.org/browse/relation/962840
Обращаю внимание на этот маршрут:
http://www.openstreetmap.org/browse/relation/962844
Его сделать нормально не вышло, т.к. разные рейсы идут разными путями, но это один маршрут. Как тут правильнее обозначить — не представляю.
Подчеркивание (_) уже deprecated, разве нет?
вот так.
В Германии все рисуют по этой схеме, и openbusmap (ÖPNV-Karte) отлично поддерживает.
Хватит изобретать велосипед, всё-таки.
Причём тут эта схема? Не нашёл там ответа на вопрос по данному случаю, когда разные рейсы идут разными улицами. Вот расписание: http://www.mostransavto.ru/?page=rasp&code=1686&ak=40&n=2&com= (часть рейсов через Площадь, часть через Пенсионный фонд)
нарисовать разными отношениями, в теги отношения вбить description, opening_hours и что ещё придумаешь
Номер-то один, значит и маршрут один. Я ещё понимаю, если б трассы сильно различались. А так, если перевозчик продлит один рейс на одну остановку — ради этого тоже создавать ещё один маршрут, дублируя информацию?
эх. Ваша Москва, вы и мучайтесь потом.
(если продлят рейс, продлите два из существующих отношений. Если добавит ещё одну трассу — сделаете новые, благо copy-paste в плагине public_transport).
Он не кольцевой. Он линейный, но кусок его представляет из себя кольцо. И ошибка у тебя в понимании. Формальный конец этого маршрута на петле есть.
Вот так выглядит этот маршрут. Даже если рассматривать его как два направления, они будут между собой пересекаться в точке перехода кольца в линию. И никакого смысла сливать их в одну линию разделяя всё остальное нет - никто так не должен ехать, и навигатор не должен так предлагать. Не надо придумывать нелепые причины для объединения направлений в одно.
Сама по себе идея разделить маршрут на два направления неплоха. Но только при условии, что любой маршрут делится на два изолированных направления. При этом вовсе необязательно делать два релейшна и даже необязательно делать направление ролью. Можно, например, вставить в нужном месте точку-разделитель с соответствующей ролью.
Маршрут, который я нарисовал выше, не делится на изолированные направления. Однако он, тем не менее, делится на два пересекающихся направления. Если бы адепты деления были последовательны, они бы его так бы и делили.
Ну, не любой маршрут делится на два направления, конечно.
И при чём здесть «изолированные направления»? Могут быть одни и те же веи в нескольких направлениях. В схеме по этому поводу ничего не указывается.
Точка-разделитель — ещё одна сущность, назначение которой не очень понятно.
Ты нарисовал линии, теперь по каждой линии, как я понимаю, можно нарисовать отношения с упорядоченными остановками — и всё будет ок. Я не очень понимаю фразу про «адептов деления».
zverik
точка разделитель - это пример. Вообще проблема в том, что роли релейшнов пишутся одним словом. Если бы на роль можно было повесить несколько тэгов - всё бы резко упростилось, и не нужно было бы городить зоопарк. Сейчас главная проблема с маршрутами даже не в том, что остановки задаются разными ролями - это как раз нормально. Проблема в том, что смысл слов “forward” и “backward” определён нечётко и различается для остановок с путями.
Для разбиения маршрута на два нужны веские основания. Попытка навязать всем остановкам одинаковые роли - недостаточное основание.
так не надо вешать forward и backward на остановки.
а на пути — относительно направления вея, как в других применениях.
я не понимаю, зачем городить сложные схемы с тэгами вместо ролей и подобным, когда есть простые.
Понимаешь в чём проблема? Вместо того, чтобы обозначить остановки в одну и в другую сторону разными ролями, ты создаёшь лишний релейшн на каждый маршрут, плюс ещё создаёшь для некоторых маршрутов остановки по обе стороны дороги с одинаковыми ролями.
В белорусской адресации есть отношение address=house, обозначающее дом. Однако релейшн на каждый дом - слишком большой перерасход по сложности структуры и сложности дальнейшего обслуживания. Поэтому почти все дома адресуются костылём. И вообще, сложность этой схемы привела к тому, что никто её так и не использует.
В схеме Oxomoa на каждую остановку предлагается навесить relation. Это обстоятельство гарантирует, что схема эта никогда на практике работать не будет.
Мне не кажется ненормальным использование ролей релейшнов в целях указания свойств остановок в данном конкретном маршруте. Это просто, наглядно и экономно. Если возникает конфликт в использовании forward/backward - можно использовать другие слова. Для остановок только для высадки можно указывать stop:exit. Только для посадки - stop:enter. Это именно то, что нужно для навигации по маршруту, и это вполне приемлемо работает в замороченных случаях.
Но суть схемы-то не в том, что создаётся тысяча отношений. Напротив, часто одно-два отношения на маршрут — это максимум. Да, остановки можно вырисовать подробно, нарисовать stop_position, саму остановку, платформу, объединить всё это в отношение stop_area. Точно так же можно в лесу вырисовывать просеки, отмечать type=* species=*, ставить natural=tree — а можно просто обвести всё natural=wood, и будет достаточно хорошо. Отлично даже для большинства применений.
Суть схемы в том, что маршрут из бессвязного набора отрезков и точек превращается в логичную последовательность, по которой можно проследить за автобусом от начала до конца. Пропущенные отрезки пути становятся не досадным упущением, а явной ошибкой, заметной на стадии рисования. Остановки из точек «вон там я видел, как останавливается автобус» в упорядоченные узлы маршрута, где все —и пассажиры, и программы роутинга — имеют ясное понятие о том, что следует за чем, и могут проводить какие-то вычисления — например, по длительности поездки. Выдавать количество остановок, которые нужно проехать; говорить: «выйди после такого-то перекрёстка со светофором».
Мой вопрос в том, зачем вообще отмечать остановки в разные стороны разными ролями? Чем они отличаются? Там остановка и там остановка.
Ты говоришь, что forward:stop и backward:stop «просты, наглядны и экономны». Но в теме постоянно появляются вопросы, относительно чего forward и backward. На странице отношения непонятно, какие из точек к какому направлению относятся. А просто stop всяко экономнее и быстрее для понимания, чем stop с префиксами. То есть, все три прилагательных неверны, и более применимы к схеме Oxomoa.
Ты предлагаешь stop:exit. Вместе с forward:stop. Получается forward:stop:exit? Просто и наглядно indeed.
Мне тоже кажется, что forward/backward только вносят путаницу. Нужно ввести новые теги по названиям которым четко было бы понятно, что вей принадлежит маршруту “туда” и дублировать этот вей с пометкой “обратно”. А направление вея вообще не принципиально. И по поводу остановок тоже согласен.
Только вот предлагаю остановки делать частью вея, как в РБ. Или по крайней мере обязательно вставлять лишнюю ноду возле остановок.
(это пока только не до конца обдуманное предположения о привязывании остановки к вею, может в годе обдумывания родится более приемлемое решение).
А чем отличаются маршруты номер 666? Там 666 и тут 666. Почему их два? Не надо заниматься словесной демагогией. Если смысл роли определён чётко - не будет глупых вопросов.
Я зря написал предложение использовать другие слова вместо forward/backward? Все проблемы - не от использования разных ролей, а от того, что в ролях используются одни и те же слова с существенно разным смыслом.
Да, это правильная идея, и в случае с тэгами роли хорошо реализуемая. Но в текущей ситуации мы получим какую-нить какафонию типа forward:forward или backward:forward, где одно слово означает направление по маршруту, а второе - относительно направления вея. Да, можно изменить слова в одной из частей, но это всё равно будет неудобно.
Веи просто должны сортироваться по порядку, а forward/backward - отражать направление относительно вея. Есть гораздо более простое решение, чем делить на два релейшна - включить в отношение точку разрыва, скажем, с ролью split. До неё будет одна сторона маршрута, после - другая. Если вместо split стоит какой-нить official_split - значит, тут маршрут прерывается лишь формально, на деле автобус едет дальше. Использование такого объекта позволит также обойтись только ролью stop для остановок.
Хотя на самом деле есть и такое соображение, что реальное разбиение на направления движения по маршруту капитально нужно только для остановок. Ведь для пассажира роутинг идёт именно по ним.
Не согласен. В этом случае надо анализировать вей, найти, каким концом он цепляется к предыдущему мемберу, а каким - к следующему, что дополнительно усложняет анализ. Если веи хоть чуть-чуть криво отсортированы - определить направление движения будет нельзя. Плюс если ещё вей замкнут и в точке замыкания крепится как к предыдущему, так и к следующему вею, мы получим алгоритмически неразрешимый случай - неизвестно, в какую сторону ехать по кругу.
Кстати, интересная мысль: перед остановкой с ролью stop ставить мембер stop:waypoint - роутинговую ноду на линии. Алгоритм должен будет считать stop:waypoint и следующий за ним stop связанными объектами. Роутинг будет идти между stop:waypoint, а пассажиру будет показываться перемещение между stop. Мда, число костылей растёт…
ну нафига, если уже есть public_transport=stop_position?
нафига по каждому, даже самому мелкому вопросу, изобретать свой, русский путь?
и после этого жаловаться, что сплошные костыли получаются?
блин…