Дело в том, что линии маршрутов/перегонов - это отдельная сущность, которая в OSM привязывается к линиям дорог. С одной стороны это удобно - автоматическое соответствие дорогам. Но другой стороны - очень сильная подверженность поломкам при редактировании + сложности с этим редактированием. А отдельными линиями в OSM хранить нереально, в силу отсутствия слоёв.
К тому же, в крупных городах эти маршруты меняются чуть ли не ежедневно - http://www.orgp.spb.ru/anews.html
Силами энтузазистов отследить все эти изменения и поддерживать актуальность весьма проблематично (даже специально обученные люди в ОРГП это не всегда вовремя делают).
В том же Питере, намного лучше было бы настроить автоматическую репликацию изменений маршрутов (договорившись с ОРГП на доступ к свежим выгрузкам в GTFS), но это возможно только если линии маршрутов лежат отдельно от дорог, иначе сложность вырастает многократно.
Не стоит путать корректировки движения в городе и утвержденные властью маршруты движения общественного транспорта. Вы же не собираетесь maxspeed:practical редактировать в зависимости от пробки на дороге.
Ну так я и привёл страничку официальных изменений маршрутов. ОРГП это “государственное казенное учреждение” - та самая власть и есть.
Если пробка существует более несколько дней - то можно и поменять. Тут вопрос в возможности поддержания актуальности. Если возможно будет подгружать ежедневные обновления (которые в ОРГП формируются) - то почему бы и нет.
Ну я с трудом представляю, как может быть иначе. Маршрут отношением “многие-ко-многим” привязан к дорогам. А дороги к точкам. И если делать отдельную БД, а привязку к дорогам делать по ID, там будут те же самые проблемы. Никуда от них не деться. Ну разве что сделать отдельную копию данных ОСМ или Гугл обрисовать и координаты хранить, забив на изменения дорожной сети. Но тогда всегда есть вероятность, что как на одном местном сайте было - дорога вот, а маршрут по лесам и холмам в полукилометре шурует Счас вроде исправили. И каждый маршрут будет со своими изгибами, как в той же wikiroutes. А в ОСМ все красиво - дорога, маршруты по дороге.
Идея хорошая, но… Если у них в основе БД ОСМ - без проблем. Иначе да, сложности. Хотя по координатам привязать наверное можно. С другой стороны рендеры перерисовывают маршруты общественного транспорта гораздо реже, чем они в питере меняются. Так что такая точность обновления может и не нужна.
В новостях я не увидел “Постановление № о внесении изменений в …” и т.д. за подписью министерства транспорта или что-то в этом духе. А учреждение “Организатор перевозок” это не власть, да и в тексте “прошу отменить”. То что у вас это есть - это вообще супер, я бы хотел такое, чтобы не стоять на остановке и ждать где же мой автобус.
Тут вот какая штука…
Вроде как это маршруты привязаны к дорожной сети (состоят из списка ребер, являющихся way-ами в OSM), но в то же время - при редактировании или создании маршрута саму дорожную сеть приходится часто редактировать, разбивая на отрезки меньшей длины. Что может снова влиять на другие маршруты, которые по этой же улице уже проложены.
Если мыслить методами “больших” ГИС, то более или менее устойчивая к разрушению структуры маршрута внешняя система должна просто обладать некой избыточностью и механизмами контроля целостности и самовосстановления, а также опираться не только на way-и но и на точки. Например:
При создании маршрута мы описываем его как последовательность way, если way входит в маршрут не целиком, то можно указать узел пересечения, на котором происходит поворот. Далее, автоматически в базу попадают и way и ключевые node (точки пересечения way-ев, отмеченные как особые), принадлежащие маршруту, и просто обычные node.
Если кто-то редактирует улицу для какой-то надобности (например, делит ее), механизм контроля целостности обнаруживает, что исчез один из way-ев, по которому шел маршрут. А механизм самовосстановления обнаруживает, что между двумя узловыми точками по концам целых кусков маршрута может быть проложено новое ребро (через те два новых way). Теперь остается сравнить форму этого нового ребра и вхождение в него старых точек. Если степень сходства нового ребра и старого пропавшего - высока (узлы нового укладываются с какой-то заданной вероятностью в буфер, построенный вокруг старого ребра, плюс там содержатся старые узлы) то новое ребро может быть даже автоматически признано тождественным старому. В более сложном случае, если степень совпадения ниже, чем полное, обнаруженная проблема и вариант ее решения могут быть предложены на суд живых людей.
freeExec, я описал такой принцип только как некую “программу максимум”, из которой можно позаимствовать некие элементы.
И разрезание было примером. Но ровно также этот алгоритм сработает при удалении way и рисовании нового и т.п.
И, как вы, должно быть, в курсе OSM редактируется не только в JOSM.
Понятно, что можно его редактировать и в блокноте, но это не повод усложнять настолько, что без спец стредств будет не разобраться. И потом не понято, то предлагаешь новый продукт, то ссылаешься, что есть и потлач.
ИМХО текущая схема - выбрал все веи, выстроил их непрерывно вполне себя окупает.
Я поддерживаю обсуждение хранения структуры (или вспомогательной структуры) во внешней базе/сервисе.
Ну и существование редакторов со странной поддержкой отношений сбрасывать со счетов нельзя, тем более, это реально волнует многих, судя по этой теме.
Согласитесь, за вычетом сложности реализации, контроль целостности и самовосстановление - неплохая фича?
Когда я, создав отношение для маршрута и включив все дороги, занялся остановками и начал им присваивать роль stop, то JOSM начал ругаться http://clip2net.com/s/5J6vDy http://clip2net.com/s/5J6wCm
Что я делаю не так? Версия JOSM 6115
а какую точку вы пытаетесь добавить в роли stop ?
этой ролью обозначается точка на дороге с тегами public_transport=stop_position (т.е. место на дороге где останавливается автобус)
если вы добавляете точку рядом с дорогой, где пассажиры ждут автобуса (public_transport=platform), то роль должна быть platform
если же вы рисуете по “старой” схеме, т.е. точка рядом с дорогой с тегами highway=bus_stop, то оставьте роль пустой
P.S. судя по скриншоту вы редактируете отношение, которое загружено частично (надпись “неполный”), очень рекомендую сначала загрузить полностью (правой кнопкой по отношению и выбрать пункт “Скачать участников”), иначе возможны проблемы
В эту тему всё равно никто не пишет, поэтому буду сюда постить новые рендринги.
Перевёл все 6 оставшихся трамвайных маршрутов Казани на новую схему (а лет 15 назад их было около 20).
kazan tram map 2013 by trolleway, on Flickr
Не стоит бояться цветовой схемы - это традиционные цвета Казанского трамвая, там всё так вырвиглазно.
Вчера Alexandr Zeinalov сделал правку в которой автоматически (?) проставил public_transport = platform на точки, имеющие highway=bus_stop. В том числе затерев public_transport = stop_position на 3-х точках в Зеленограде. Несмотря на то, что точки входили в линии дорог и имели роли stop в stop_area.
Корректировку мы с ним согласовали - восстановление stop_position и удаление highway=bus_stop, что я и сделал.
Однако у меня следующие вопросы к сообществу
Надо ли и куда ставить highway=bus_stop, если public_transport = platform нарисован не точкой?
Нужен ли public_transport = platform там где только выход пассажиров, а посадки нет ни на одном маршруте? Наличие роли platform_exit_only не отвечает на этот вопрос, т.к. возможна на остановках, где есть посадка на другие маршруты (хотя примера я не знаю). Если platform не нужен - куда ставим highway=bus_stop?
Корректно ли автоматически проставлять public_transport = platform на highway=bus_stop ?
Счас вроде исправили. И каждый маршрут будет со своими изгибами, как в той же wikiroutes. А в ОСМ все красиво - дорога, маршруты по дороге.
