ikz, ну тогда может разрешите гарминоводам резать все улицы на куски для организации их поиска? Ведь для программ же рисуем 
Под каждую навигационную программу наделаем костылей прямо в базе ОСМ и получим вместо данных - неюзабельное УГ.
Так о том и речь, что maxspeed используется не какой-то одной программой, в которой “у вея хранится только одна скорость”, а всеми навигаторами, а также конвертерами в навигационные карты, которые работают через польский формат.
Правильно сказать - пока не поддерживает. Да, конверсия - это вещь не тривиальная. OSM - это база данных со своей семантикой, правилами, своей моделью данных. А не с моделью данных Навитела/СитиГида/ПокетГиса/Гармина. Пытаться все переколбасить под одну программу, потому что в ней “так проще” - это и называется “рисовать под навигатор” (и всеми осуждается). А в другую программу легче конвертить когда наоборот. И что, ничья?
А все что кому-то нужно, будет поддержано в конверторах, не волнуйся.
На польском формате свет клином не сошелся. Вот навигатор X не использует польский формат, или использует модифицированный, с доп тегами?
Ставить во главу угла глюки программы, которую ты используешь, это плохо.
“Не рисуйте под конкретный формат!” 
А других и нет.
2all:
Т.е. кроме нерабочего maxspeed:forward/backward других предложений нет? Т.е. как всегда у нас в Расее, критики много, конструктива - ноль?
Если Вам про “что-то” неизвестно, то это не вывод, что “этого” нет.
2ikz, рисуйте, что видите, а не что хочется. Вопросы и предложения, касаемо конвертации надо задавать в соответствующих ветках. Например, зачем рисуют то, что не рендерится и вообще пока что ни где не отображается/конвертируется? Что бы это потом можно было брать и оно было. В проекте признан определённый порядок, потрудитесь его соблюдать. Лучше терпеть некоторые неудобства в в силу “не поддержки”, чем ломать реально существующие объекты для создания дальнейших неприятностей.
Почему же он не рабочий, он рабочий. Что бы твой любимый навигатор понимал этот тег - это задача в первую очередь твоя.
Так что предложение простое: допиливать свой конвертор (или теребить тех, кто им занимается).
Бгыг…
Корёжить данные базы в пользу какого-то одного формата - это по вашему конструктив? У OSM есть свой формат и там всё можно замечательно описать. А если какой-нибудь программе потребуется что-то своё - нужно пилить конвертер. Нет возможности править конвертер - сделайте препроцессор. В конце концов самый простой путь - сделайте свой тег для обозначения логической маршрутизации, добавьте соответствующие линии в спорных местах и в конвертере/препроцессоре меняйте одно на другое.
Блин, ну перечитайте первый пост. Там все описано то, что фактически на местности (ground truth), что и хочется перенести в OSM. Но перенести так, чтобы это работало, а не было прописано “для галочки”.
езжу по дороге lanes=2, где ограничения скорости в разных направлениях начинаются и заканчиваются независимо. идея рисовать ее 2мя way’ями не греет.
У меня технический вопрос - как будут реализовываться эти костыли с :backward и :forward? Ну то есть, вот, допустим, нарисовал я дорогу, проставил таким образом эти ассимметричные ограничения. Следующему редактору показалось, что направление дороги неправильное, и он поменял его (ну или JOSM изменил направление при объединении линий, а редактор не обратил внимания). Про то, что необходимо будет изменение этих тегов, мало кто вспомнит ведь.
Поправьте, если ошибаюсь: сейчас направленность линий используется разве что в реках, да и то эти данные никто не использует. До этого еще было слабенькое соглашение про рисование водоемов так, чтобы вода была с одной стороны, да и то всем было пофиг. Джосмовский валидатор раньше на это ругался, но уже некоторое время как перестал. Польский формат, основа многих конвертируемых карт, данные о направлении тоже не использует никаким образом.
Если сравнивать костыли двухвейности и костыли ассимметричных тегов, то я совсем не уверен, с какими будет меньше проблем. Двухвейность, по крайней мере, нагляднее и проще контролируется. Жаль, нет третьего варианта.
Ошибаешься, и сильно. Направленность веев используется для задания направления движения для односторонних дорог. oneway=yes означает что движение разрешено в направлении вея.
И бояться, что кто-то что-то не поддержит - глупо, лучше написать разработчикам софта. А иначе в осме не было бы ни одной новой фичи, потому что эта новая фича, мол, еще нигде не поддерживается.
Упс, забыл про дороги с односторонним движением (oneway=yes) - роутинг с ними вроде нормально обсчитывается, несмотря на ограничения Польского формата. Но всё равно не нравится мне такая искусственно вводимая ассимметричность с :backward.
Кирилл, чуть опередил, спасибо, я уже и сам понял, чего не хватает
Писать особо никуда и не надо - придёт Лёша, подумает и скажет, насколько сложно будет такое реализовать в osm2mp.
еще раз, на osm2mp и ограничениях польского формата свет клином не сошелся. Могу сказать что в конверсии в ситигид поддержу maxspeed:forward/backward в *ближайшее время *.
А сама по себе двухвейность - совсем не панацея, бывает что знаки вешают над полосами.
угу.
а я езжу по дороге, где знаки ограничения скорости в последнее время то появляются, то исчезают
сегодня стоит 50, через пару дней он пропал. еще через день его перенесли на пару км
при этом народ как 90-110 ехал, так и едет
будем делить/объединять эти дороги каждую неделю?
Прежде, чем говорить, что что-то неудобно и предлагать замены, оцените неудобства замены.
Это многократное увеличение количества веев, “лесенки” вдоль улиц, где разрешен разворот (поперечные веи через каждые два метра), вдвое больше тегов расставлять, следить за их согласованность (напомню про то, что пропозал про street еще не утвержден).
Если польский формат плох, то это его проблемы и не надо нести их в осм. А то может я тоже что-нибудь придумаю: весь мир перегнать в svg и отобразить в браузере, затем упрощать и удалять веи, пока оно не начнет браузером открываться.