Двойная сплошная = Две Линии

Так о том и речь, один вей сложнее полностью отмечать чем два односторонних и AMDmi3 это видит. Вопрос: зачем использовать такой сложный подход, когда можно делать проще?

Я об этом:

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

Рис.1. Машина ближе к средине дублера, чем к средине проспекта, но восстановленные из тега width края позволяют сделать правильную привязку.

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

А, ты изначально отвечал на реплику про совсем другое.

А про ширину-то понятно, но это опять таки теоретическое светлое будущее когда 1) есть данные о ширине 2) они используются навигаторами.

Нужны реальные аргументы в пользу односторонних веев? Их есть у меня:

  1. Я про теги :forward/backward не просто так талдычу, в них делают ошибки. Это не просто подсчет буковок. Пользователям простого редактора всегда будет тяжело вводить не рисуя линии. Попробуйте месяц пользоваться только ID. Где там история тегов? Копирование тегов? Не надо это там, это опять раздует его во второй JOSM. Редактирование должно быть доступным.

  2. Подсчет правил, запретов, месиво в неймспейсах forward/backward - это все придётся делать роутерам и утилитам препроцесиинга.

Если представить что ВСЕ рёбра в графе односторонние, пусть их и в 2 раза больше, то роутинг будет работать быстрее из-за отсутствия подсчета правил и тегов запретов которых в 2-4 раза больше чем достаточно. Не знаю, поверите вы мне на слово, но я здесь не теоретик.

Я не знаю как еще объяснить.

Подход с двусторонними дорогами это указать не только саму дорогу но и создать правило для каждого направления + что можно попасть из А в Б, можно попасть из Б в А.
Подход с только односторонними дорогами это сказать что можно попасть из А в Б. Без правила (oneway=yes всегда, не нужно ничего считать).

Вот ваши бедные роутилки этим и занимаются (почитывают есть ли у дороги oneway=yes либо oneway=no). На это уходит время. Как думаете ваша роутилка умная и делает разбор графа один раз при обновлении либо страдает маразмом и считает эти никому не нужные oneway каждый раз?

Из-за “простого” на первый взгляд подхода обозначения дорог у вас действительно возникает больше запретов и на отдельно взятых дугах графа. Эти запреты не просто буковки: их в 4 раза больше значит роутилка будет медленнее работать. По секрету скажу что увеличение объема данных в 4 раза не значит увеличение обработки этой информации только лишь в 4 раза - алгоритмическая сложность в задачах с графами очень редко бывает линейной. Вы сами себе роете яму.

Зачем?

Могу сильно ошибаться, но разве там не было бы достаточно одного запрета налево с проезда Дежнёва на Юрловский проезд? (*хоть я и не приверженец повальной одновейной отрисовки :slight_smile: )

Кто знает, может в каком-нибудь «Бюро Светлого Будущего Навигации» работают над этим. :smiley: И остаётся им чутка помочь - проставить полосность/ширину.

В теории да, но тогда в верхней точке понадобится разворот, а навигаторы их часто избегают - я бы на это не надеялся.

А разве он сейчас правильно обрабатывается - поворот в один манёвр?

d1g, в качестве полемики:
Как обозначать запреты поворотов-разворотов, если перекрёсток обозначен как “квадрат”? Я не смог найти способа обозначения, а ведь хочется ещё и полосы для поворотов сделать…

Легко! Всю “серединку” перекрестка выделяем в relation, который используется в роли via. Роли from и to остаются по-прежнему - веями. Будут полосы - еще проще: на каждую полосу - свой relation с этой полосой в роли from. Осталось допилить конвертеры.

cd_spb, я не понимаю о чем вопрос, можно на картинках показать? Либо ссылка на карту?

оффтоп. Если у вас часто из-за широких дорог проблемы с привязкой GPS <-> граф возникают, возьмите по overpass дороги больше 6 полос да и обозначьте у них ширину width=2.75*<колво полос> + source:width=guess где они более-менее одной ширины. В osmand шлёте тикет проверять у дорог на экране их ширину + учитывать эту ширину в позиционировании “человечка” на карте. Когда вы ширину укажете, это будет просто Zkir уже описал что должно проверяться. Больше 10 строчек автору osmand я не дам. Всё. Никого бюро не нужно. Тем кому хочется - можно купить лазерный дальнометр и походить с ним вокруг обочин, тогда можно будет указать source:width=laserguess.

https://code.google.com/p/osmand/issues/list

Не надо никаких guess’ов. Нужно просто обозначить количество полос lanes=*.

Это не правильно. Полосы не по ГОСТ бывают и никто в этом не виноват, местность такая бывает. width это ширина дороги на всем участке. Если width не указан, то из lanes можно извлечь приближенно значение (например, 2.75м для главных дорог 2.5 для обычных дорог). Если указан width, то следует использовать его. Нам нужны физические размеры, их нужно указывать в width.

kisaa

Вот только движения в сторону улучшения уже который год не наблюдается ни у кого…

Cd_spb

Через костыли по состоянию на сегодня - например как здесь: http://openstreetmap.ru/#layer=S&map=18/55.17806/30.22898

http://openstreetmap.ru/#map=19/59.98934/30.30055
http://maps.yandex.ru/?ll=30.300271%2C59.989669&spn=0.013518%2C0.001672&z=17&l=map%2Cstv&ol=stv&oll=30.30027052%2C59.98966885&ost=dir%3A132.8524145717015%2C0~spn%3A89.99999987427145%2C50.85253226847016
Даже вариант попроще - пересечение одновейной и двухвейной.
С северо-запада знак, слева-направо - налево, налево-прямо, прямо, прямо.
С северо-востока - налево, налево-прямо, прямо.
Как обозначить?

Есть сопутствующая проблема -
При “двухвейности” длина сегмента на перекрёстке максимум 100м.Навигатор показывает полосы для поворота в тот момент, когда въезжаешь на соответствующий сегмент. Т.е. для принятия решения крайне мало времени. Знаки на местности стоят заранее, но и этого времени не всегда хватает. Пример такой неочевидности, в крайней его ситуации - при проезде с севера на КАД, движение на запад или восток, нужно заранее встать в нужную полосу или улетишь не в ту сторону.
http://openstreetmap.ru/#=&map=16/59.8077/30.3264
http://maps.yandex.ru/?ll=30.321982%2C59.804443&spn=0.054073%2C0.006724&z=15&l=map%2Cstv&ol=stv&oll=30.324315390000002%2C59.80566019&ost=dir%3A4.685899839502703%2C0~spn%3A89.99999987427145%2C50.8525321709647

Приемущество - понятно разделены ли проезжие части в реальности физическим барьером или нет, помогает ориентироваться в малознакомых городах.

Cd_spb

При чем тут “двухвейность” и то что показывают навигаторы в качестве полос… Те кто пишут программы для навигации такое впечатление что сами за рулем не ездят - и поэтому всякую хрень показывают на экране навигатора тогда когда им кажет что это надо. Но им это кажется почему то в большинстве случаев совсем не так, как это должно быть на самом деле. Или я что то пропустил и на основе карт OSM есть нормальные программы которые показывают в нужный момент направления движения по полосам? 7way дернулся в этом направлении - но что то я не вижу массового распространения их потуг. Навителу с нами делиться некошерно, Ситигид вообще на это положил… Garmin - тоже вещь в себе… Проблема есть, решение ее можно сделать без особых то усилий - просто волевым решением начать поддерживать какое то реально работающее решение - однако никому это нафиг судя по всему не надо. Да и тот же навител даже в своих официальных картах до сих пор не допилил отображение направлений движения по полосам - там куча ошибок отображения прет…

Бред же пишете. Именно потому что полосы бывают не по ГОСТу, придуманный на их основании width никак не может добавляться в базу. Использоваться налету навигаторами - ради бога, этого для описанной задачи вполне хватает.

Мало ли что вам нужно. Есть число полос, значит должно быто отмечено число полос, а не неверные данные на их основе.

Ну никак конфигурация дорог не связана с разделителями. Чтобы было понятно что проезжие части разделены физическим барьером должен быть нарисован барьер.