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

d1g · 2014-06-24T20:36:32.000Z

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

Zkir · 2014-06-24T20:54:05.000Z

AMDmi3:

Zkir:

Очень просто: таки учесть ширину дороги, например из тега width или lanes.

Опиши механизм как и на что это должно повлиять.

Я об этом:

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

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

| || *| | |

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

AMDmi3 · 2014-06-24T21:11:11.000Z

d1g:

Я от вас так и не услышал. В чем преимущество “одного вея” что ради него дополнительно теги городить, запреты ставить?

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

AMDmi3 · 2014-06-24T21:13:17.000Z

Zkir:

Я об этом:

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

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

d1g · 2014-06-24T21:17:05.000Z

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

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

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

d1g · 2014-06-24T21:40:07.000Z

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

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

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

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

Зачем?

LLlypuk82 · 2014-06-25T00:34:40.000Z

AMDmi3:

На самом деле эта проблема в равной степени касается и одновейной отрисовки: не представляю как бы обрабатывался этот поворот налево если бы дороги были отрисованы одним веем:
http://osrm.at/84t

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

Zkir:

Мапматчинг нужно делать с учетом ширины дороги.

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

AMDmi3 · 2014-06-25T00:56:02.000Z

LLlypuk82:

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

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

Cd_spb · 2014-06-25T03:32:50.000Z

AMDmi3:

Hind:

У схемы с двумя веями есть небольшой минус — большинство конвертеров (да и навигаторов) не может в запреты разворотов через вей (а не через точку).

Фееричная фраза. Не могут конвертеры, а минус почему-то схемы.

На самом деле эта проблема в равной степени касается и одновейной отрисовки: не представляю как бы обрабатывался этот поворот налево если бы дороги были отрисованы одним веем:

http://osrm.at/84t

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

Cd_spb · 2014-06-25T04:11:17.000Z

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

kisaa · 2014-06-25T04:27:22.000Z

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

d1g · 2014-06-25T04:31:42.000Z

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

AMDmi3 · 2014-06-25T05:03:19.000Z

d1g:

обозначьте у них ширину width=2.75*<колво полос> + source:width=guess

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

d1g · 2014-06-25T05:09:31.000Z

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

mixdm · 2014-06-25T05:21:19.000Z

kisaa

Осталось допилить конвертеры.

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

Cd_spb

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

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

Cd_spb · 2014-06-25T05:30:21.000Z

d1g:

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

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

dkiselev · 2014-06-25T06:01:35.000Z

d1g:

AMDmi3:

d1g:

Вы забыли про неймспейсы :forward :backward?
Вы забыли про ограничения поворотов в случае одной дороги?
Вы забыли что на каждом участке нужно обозначать действующие на него ограничения тегами?

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

highway=* на направление движения в городах более чем реальный подход. Мы уже отметили так большую часть односторонних дорог. Если придется перемапить, то только двусторонние.

Почему простота маппинга не аргумент? Речь о сегментах, запретах - их все нужно отмечать с подходом “однин путь”.

Я от вас так и не услышал. В чем преимущество “одного вея” что ради него дополнительно теги городить, запреты ставить?

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

mixdm · 2014-06-25T06:13:39.000Z

Cd_spb

При “двухвейности” длина сегмента на перекрёстке максимум 100м.Навигатор показывает полосы для поворота в тот момент, когда въезжаешь на соответствующий сегмент. Т.е. для принятия решения крайне мало времени.

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

AMDmi3 · 2014-06-25T07:22:43.000Z

d1g:

Это не правильно. Полосы не по ГОСТ бывают и никто в этом не виноват, местность такая бывает.

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

d1g:

Нам нужны физические размеры, их нужно указывать в width.

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

AMDmi3 · 2014-06-25T07:24:16.000Z

dkiselev:

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

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