Хамство.
maxspeed:forward/backward никто не поддерживает. Будет ли его поддерживать osm2mp - большой вопрос, поскольку (как я помню) формат mp не предусматривает двух ограничений скорости на один вей.
Введем поддержку maxspeed:forward/backward ради одного ситигида?
Сам такой.
Не рисовать под “программу” - бред, поскольку рисуем в программе и для программ. Мапник, джосм, осмозис, osm2mp, гармин, НН, ситигид - это все программы. Т.е. товарищ призывает вообще не рисовать 
Рисовать под программУ и под программЫ в целом баааальшая разница
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.