Количество точек не такое уж и большое. Хорошо прорисованная речка даст гораздо больше.
Речь скорее шла не про node, а про логические точки, например 4 светофора вместо одного.
Дополню список wowik-а. Мифическая логичность и «лёгкость восприятия». Обозначайте физические барьеры — вот вам и лёгкость и логичность настоящая. Всё остальное — лень обыкновенная. И не удвоится никакая дорожная сеть (или по-вашему она удваивается, если вместо разметки поставили ограждение?). С разворотами всё нормально (адекватную поддержку озвучки таких разворотов обязаны осуществлять навигационные программы при любом раскладе, поскольку такая топология неизбежно возникает при двух проезжих частях, не так ли? А маршруты строятся прекрасно).
Для светофоров предлагал как-то отношения создавать (но это всё — блажь и никому не надо, кто бы сомневался).
Не забываем:
Зато это даёт более точное место для подсказки поворота.
На Садовом Кольце расстояние в десятки метров.
Проясните тогда пожалуйста. Дорога где 2-е и более полосы в каждую сторону разделяется двойной. Где менее - одной соответственно.
К примеру всё та же Торфяная дорога разделена одной сплошной, следовательно там по 1 полосе в каждую сторону.
Так теперь и 1+1 делить нужно?
Я не понял почему такой вывод. Да еще из моего примера.
Консенсуса нет не столько из-за отсутствия общепринятого критерия раздела на два вея, а просто отсутствия согласия по вопросу стоит ли разделять ли вообще одну проезжую часть на два вея.
В сторону нестандарта?) Он и так отсутствует. Я имел в виду это.
Впервые слышу такое, к примеру. Это где-то обсуждалось? И да, misht привел очевидный пример его несоблюдения. Откатываем там все?
OSM же не для Вас одного содержится) Есть большое число категорий пользователей, для которых разметка не является препятствием. И рисуя карту для нас одних, мы вырубаем возможности навигации для этих категорий на корню. А вот ежели мапить конкретно к физической привязке, имеем обратную ситуацию.
Да, и запреты разметки весьма недолговечны, часто до первого снега. Война правок?
Сложности мои, согласен, так что позвольте мне их принять.
Вы рассматриваете сейчас ситуацию с точки зрения размеров штрафов за потенциальные нарушения ПДД. А если посмотреть на это через призму потерянного времени при неверном построении маршрутов? И опять же, заметьте, нарушения можно избежать, смотря на дорогу. А вот как избежать тотальной ошибки в навигации - пытаюсь Вам поведать я.
Вы уже где-то сталкивались с такими страшными ошибками? Или вы их ловко избегаете всё время?
С неправильными запретами поворотов я сталкивался, исправлял. Причём это было на дорогах с разделительными полосами, 2-way. Непонимание (само по себе) и ошибки в отношениях поворотов не зависят от кол-ва линий дорог, а зависит — количество случаев необходимости применения этих отношений, что и приводит к увеличению вероятности получить вышеуказанные тотальные ошибки. Так что ваш «аргумент», вообще-то — контраргумент для вашей позиции.
А для тех, кому разметка — не указ, навигаторы побоку. Что вы о них так печётесь? Не раз уже говорено о всяких скорых помощах, полициях и прочих дорожных службах, которым до лампочки всякая навигация. Но постоянно появляются радеющие за такие категории «сферических пользователей» и «экстремальную» навигацию.
dair, на самом деле, принципы отображения “1 линия” - “2 линии” не “симметричны”. Скажем, у нас есть теги, фактически, обозначающие изолинии высот. Где должно быть выше: слева по направлению линии или справа? Разницы никакой - это лишь вопрос договорённости, принципы “симметричны”. Между отображением одной линией и двумя есть разницы: две линию дают более высокий уровень детализации. Положим, мы начинаем обрисовывать город. Сначала мы ставим landuse=residential большим пятном, которое по спутнику примерно попадает на город. Затем мы видим, что город разделён на 2 части широкой рекой. Режем landuse=residential на 2 куска. Затем режем по широким магистралям, проходящим через город. Затем уменьшаем landuse=residential, аккуратно прорисовывая landuse=industrial и т. д. Движение в таком направлении увеличивает детализацию, оно естественно и привычно. Возвращаемся к дорогам. Сначала вообще проводим прямую линию между началом дороги и её концом. Затем примерно подправляем траекторию по спутнику. Затем корректируем положение по gps-трекам, начинаем расставлять запреты поворотов, подключать примыкающие дороги и т. д. Затем видим, что потоки разделены, их свойства отличаются, прорисовываем потоки, проставляем свойства. Через какое-то время, весьма вероятно, будем прорисовывать каждую полосу и её осью, и площадной границей. Это естественное движение в направлении уточнения данных. Когда идут правки, уменьшающие детализацию, это вызывает, скажем так, недоумение. Мотивация, поэтому, по сути, заключается в желании улучшить данные, увеличить степень детализации.
literan, движет мной, наверное, то же, что и большинством других редакторов - желание улучшить базу данных OSM.
Pavel47, дороги у нас прорисованы по-разному по той же причине, по которой где-то у нас прорисован каждый кустик, а где-то вообще населённый пункт не обозначен: где-то есть редакторы, имеющие желание и возможность подробно прорисовать часть земной поверхности, где-то - нет. Если считать, что вездё всё должно быть “стандартно”, нужно вообще всё удалить, т. к. где-то есть не отмеченные населённые пункты. Не лучше ли стараться прорисовать там, где это ещё не сделано?
Отсутствие или наличие разделения потоков, вообще говоря, тоже определяется на раз: Вы же определяете, разрешены или нет обгоны, левые повороты, развороты, парковка на противоположной стороне дороги.
Сказать, что нужно гадать о том, что же имеется на местности, можно практически о любой картинке на карте: например, линия цвета trunk в стандартном рендерере может обозначать широкую ровную асфальтовую дорогу с разделёнными потоками, а может обозначать канал жижи с плавающими в нём грузовиками.
Вопрос левого поворота через стёртую разметку не относится к вопросу прорисовки одной линией или двумя: если редакторы полагают, что по центру есть сплошная разметка, то при прорисовке одной линией на узле будут стоять запреты поворотов, а если редакторы полагают, что запрещающей поворот разметки нет, то там при прорисовке двумя линиями будет стоять перемычка. Навигационные программы при любых принципах прорисовки покажут движение дальше при простановленном запрете и при любых принципах прорисовки покажут поворот при отсутствии внесённого в карту запрета.
“Тотальные ошибки навигации” скорее возникают при некорректном переносе действительности в базу данных (при этом корректно и некорректно можно перенести что в одну линию, что в две) и из-за недостатков в навигационных программах. Мне, кстати, пристыкованные к одной линии service с ошибочно непроставленными запретами поворотов попадались чаще, чем пристыкованные к двум линиям с ошибочно непрорисованной перемычкой. Тут ещё есть обширная область для дискуссии на тему того, какая методика прорисовки выдаёт реально меньше ошибок.
freeExec, при наличии физического разделителя на перекрёстке будем иметь те же 4 светофора - логические точки, так что это именно проблема именно отсутствия полной нормальной схемы прорисовки перекрёстков: по крайней мере, мы пока не умеем толком прорисовывать перекрёсток так, чтобы было понятно, где стоп-линии, где стоят светофоры и про движение в какие рёбра говорят знаки движения по полосам.
misht, не всё так однозначно и просто: движение по пятиметровой дороге отличается от движения по одиннадцатиметровой дороге даже вроде как при одинаковом числе полос. На Торфяной дороге, кстати, Вы сами ставили lanes=4 - наверное, Вы тоже разницу улавливаете.
Общее замечание по поводу тех пользователей, кто может ездить, ориентируясь исключительно по физической проходимости: для них непригодны стандартные навигационные программы, для них нужны особые алгоритмы, в частности, умеющие строить маршруты в любом направлении внутри сплошных area:highway. Без особого подхода нормально маршрут не построится что с одной линией, что с двумя.
Если где-то на карте ошибка и отсутствует запрет, то мы получаем неверный маршрут. Если где-то на карте ошибка и отсутствует разрешение, то мы получим все-равно валидный маршрут, но немного длиннее, чем если бы ошибки не было.
Причём первая ошибка вскроется в последний момент, когда выяснится, и придётся экстренно выпутываться, опять же с перепробегом. Вторая ошибка не ведёт к неожиданностям и даже может быть обнаружена при просмотре предлагаемого маршрута, если он выглядит подозрительно, как было в вашем случае.
Я опять почеркн мои слова к примеру. Вы почему-то смысл в них вкладываете избыточный.
Это пример формулировки. И как такой способ формулировкуи опровергает некая дорога 1+1?
А то, что вы многого не слышали, так это поправимо, перечитайте форум. Там было всякое. Там было ВСЁ.
Но опять скажу проблема не в недостаткн предложений когда делить, а в отсутствии консенсуса, в вопросе надо ли вообще делить.
Безусловно разница есть, но это не значит что должны появляться какие-то частные случаи. Правила должны быть едины, а то другой пользователь уловит ещё что-нибудь и начнёт опять править.
Так вариант разделять highway по физическим разделителям даёт единообразие и более менее прописан в wiki. А в нынешнем варианте уже становится не понятно толи смотреть на количество полос, толи на ширину дорог, толи на ПДД. Пока это нигде не прописано будет неразбериха.
Общая мотивация, пожалуй, понятна. Рисование отдельных полос отдельными линиями лично я одобряю. Сложность в том, что если все время использовать один тег, то постепенно уплывает его значение, в результате для разных объектов он означает совершенно разное, и суммарно тег смысла не имеет. Пример с landuse несколько не аналогичен: с одной стороны, у него и так довольно размытое определение (да и границы во многих случаях довольно условны, когда нет четких заборов), а с другой - общий смысл там не меняется при разрезании, потому как вся площадь landuse однородна и при разрезании получаются два куска с теми же свойствами. Т.е., мы просто вырезаем из него лишниий кусок с другими свойствами. Про дороги (да и про любой другой линейный объект) так сказать не получится, потому как линейность - уже сама по себе абстракция, и между двумя параллельными линиями highway нет никакого “участка с другими свойствами”. Здесь был бы ближе пример с building, если бы для указания разноэтажных частей мы вводили не building:part, а резали на два building с одинаковым адресом и прочими свойствами, кроме этажности.
С другой стороны, при такой “детализации” теми же самыми тегами мы ещё и теряем информацию. Если брать те самые проезжие части, которым до недавнего времени в большинстве случаев соответствовала одна линия highway. При неконтролируемом раздвоении мы теряем информацию о количестве проезжих частей. Если хотя бы эта утраченная информация была как-то компенсирована, к примеру, отношениями, было бы еще терпимо, но мы ее просто потеряли, и должны только догадываться, что вот эти примерно параллельные линии на небольшом расстоянии должны означать, что они образуют единый объект. Именно вот эта потеря данных меня и беспокоит.
Возможно, кому-то эта информация кажется ненужной, допускаю, что для маршрутизации оно действительно значения не имеет. Двунаправленное ребро графа или два однонаправленных - вполне возможно, что второе и удобнее. Но вот лично мне маршрутизация и навигаторы неинтересны совсем, а интересен рендеринг (как имеющийся, так и потенциальный). И если на больших зумах неизбежно постепенное переползание на area:highway, то для средних проезжая часть - вполне приличная альтернатива.
Да даже и вообще забыть о проезжих частях, не всегда возможно определить, обозначают две параллельные линии одну дорогу, или же это вообще две дороги, а между ними может быть даже дома, просто пока не нарисованы. По наличию общего названия в name в общем случае вывод сделать нельзя.
Доделывайте заброшенную схему, используйте.
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Dual_carriageways
Вас действительно так беспокоит эта «потеря данных»? Какой негодяй вам (и кому бы то ни было) мешает скрупулёзно и вдумчиво наносить на карту разделительные полосы, ограждения и другие элементы дорожной инфраструктуры, а потом с эстетическим наслаждением наблюдать результаты, прекрасно ориентируясь в количестве проезжих (а по правде — заезженных тут, на форуме) частей?
Это какой-то нездоровый способ компенсировать неполноту данных за счёт привязки к рендерингу проезжих частей, непременно выделяя их одно- или двухлинейной трассировкой. Он не даёт ничего, кроме «красивого рендеринга» и позволения не вносить полезные данные в базу, а подразумевать их.
Да, беспокоит. Если какие-то данные пропадают, а рендеринг - это, вообще говоря, не единственное их применение, это нехорошо. Менять способ представления в базе - это нормально, удалять - нет.
На высоких зумах (когда объекты уже в основном площадные) особой проблемы действительно нет. А вот для генерализации этих параллельных линий информации становится недостаточно.
Про неполноту я как-то не понял - вроде как до этого шла речь о том, что одновейность и двухвейность - это вполне равноценные модели, просто одни и те же понятия несколько по-разному в них отражаются (что-то через топологию, что-то через отношения), соответственно одна для каких-то задач удобнее другой.
Но в общем-то неважно, тег highway уже загублен - на каждой дороге он означает разное. Удалить его полностью уже не удастся, как и придать ему какой-то унифицированный смысл.
Растолковываю: неполнота данных — отсутствие обозначенных физических барьеров. Лукавый способ компенсации этого отсутствия — «красота» в виде одно- и двухлинейного «обозначения проезжих частей». Или не вы постоянно твердите, что вам неудобно определять количество проезжих частей?
Или это не ваши слова? К тому же, выделенный текст — либо ваше «искреннее заблуждение», либо откровенная ложь.
Предостаточно. Если дорога относительно узкая — эти «параллельные линии» сливаются в одну. Если дорога широкая, многополосная — там отлично виден промежуток (потому что каждое направление обозначено примерно по осям, которые будут на значительном расстоянии), в котором видна пустота или физические разделители (в виде островков зелени, как правило). Это — во-первых. А во-вторых — при чём тут генерализация? Может хватит натужно притягивать за уши всё, что в голову придёт?
LLlypuk82 если не затруднит, напишите пожалуйста тезисно, по пунктам, в каких случаях highway, в СПб и ЛО, делить на 2 вея. Либо в каких не делить.
misht, у нас на карте, на самом деле, и так везде “неразбериха”: детализация районов, отрисованных активными редакторами, разительно отличается от детализации районов, где таких участников нет. Требования “единообразия”, на мой взгляд, непродуктивно. Местность прорисовывается с такой детализацией, на какую хватает сил у редакторов.
Куда смотреть, на самом деле, понятно - надо смотреть на то, есть или нет разделение потоков.
dair, мне кажется, при увеличии детализации мы информацию не теряем. Информация о наличии физического разделителя - это точка/линия/область, отмеченная как физический разделитель. Информация о проезжей части - это area:highway. Если этих сведений не было, то они и потеряться ни при каких действиях не могут.
Если вести речь о том, относятся ли две рядом расположенных линии к одной дороге или нет, а также если говорить о генерализации данных, то тут я, на самом деле, даже в случае, очевидно, разделённых проезжих частей не могу сказать, как это точно должно выглядеть. Вопрос в постановке задачи. Чего хотим добиться, что вкладываем в генерализацию? Того, чтобы названия не подписывались на обоих линиях, а отображались где-то по середине? А если разделитель широкий, то название будет попадать на разделитель? Это, видимо, нужно как-то решать отношениями. А проезжую часть лучше, чем через area:highway, мы, вероятно, никак не обозначим. Чем плох этот тег? Он вроде ещё не “загублен” - так, может, им и пользоваться для обозначений проезжих частей?
Никто не будет этим заниматься (кроме Энтузиастов). Это не покажет ни один рендер, не использует ни один навигатор, нигде это не учитывается на сегодня.