Имхо зимники надо как-то явно указывать, а не отслеживать время открытия/закрытия.
И они наверно должны в route=* попадать, а не в highway
route=winter_road?
Имхо зимники надо как-то явно указывать, а не отслеживать время открытия/закрытия.
И они наверно должны в route=* попадать, а не в highway
route=winter_road?
1a - возможно опечатка
А чего криминального в пунктах 1, 2, 3 и 5
highway=service - подъезд/проезд
living_street=yes - преимущество пешеходов
service=alley - уточнение типа подъезда/проезда
highway=living_street - так вроде обозначаем улицы где есть знак жилая зона.
и т.д.
В общем за исключением вариантов 6 и 1а - где противоречие? В конце концов дворовые проезды тоже бывают всякие.
dkiselev,
как я понял, KekcuHa хочет по имеющимся тегам выделить сущность “дворовый проезд”.
То есть задача не “как обозначить”, а “как понять, является ли объект дворовым проездом”
Z440 на ошибках учатся у вас все впереди
если вас на самом деле интересует, как обозначать зимовья - создайте топик и предложите обсудить этот вопрос в нем. заинтересованные поддержат
по-поводу зимников…
вас никто не обязывает “следить” за дорогой. но если вы пользуетесь картой, то скорее всего сами, увидев ситуацию по факту (дорога открыта\закрыта, проезд только камазам\всем подряд) захотите изменить теги таким образом, как это все обстоит в реале
так же поступят и другие ОСМеры
имхо, shelter - это не “избушка”, а именно навес. а-ля автобусная остановка с крышей. хотя возможно у этого тега и более широкое значение\применение
Совершенно верно. Со всеми вытекающими, в первую очередь - с запрещением транзита.
Лично я бы просто запрещал транзит по всем service.
Кроме случаев, когда других вариантов нет.
А по каким-то hw=service разрешён сквозной проезд?
А по каким-то hw=service разрешён сквозной проезд?
Вообще вроде бы да. Если память не изменяет сервисом может быть обозначено много чего, например питлэйн на гоночной трассе там сквозной проезд разрешен. Но это конечно не к нашим реалиям. Вроде если не стоит знак жилая зона то сквозной проезд разрешен?
Вообще я за обозначение вида hw=service service=дворовый_проезд, но только перевод адекватный для дворового проезда найти.
по-поводу зимников…
вас никто не обязывает “следить” за дорогой. но если вы пользуетесь картой, то скорее всего сами, увидев ситуацию по факту (дорога открыта\закрыта, проезд только камазам\всем подряд)
Следить за зимниками иногда можно не выходя из дома. Например тут: http://www.berezovo.ru/manage/site?tid=633200029 написано
На основании Распоряжения администрации Березовского района от 19 апреля 2010 года № 227-р автозимники на территории Березовского района закрыты с 19 апреля 2010 года
Вроде если не стоит знак жилая зона то сквозной проезд разрешен?
Нет.
“Прилегающая территория” - территория, непосредственно прилегающая к дороге и не предназначенная для сквозного движения транспортных средств (дворы, жилые массивы, автостоянки, АЗС, предприятия и тому подобное).
Буду знать. Тогда может и вправду считать что для всех service сквозной проезд запрещен.
Буду знать. Тогда может и вправду считать что для всех service сквозной проезд запрещен.
Через парковки транзнит вроде как не запрещен.
IMHO, при наличии living_street=yes должны подразумеваться access=destination (как раз запрет транзитного проезда) и maxspeed=20 (на всякий случай). Умеет ли osm2mp и дальнейший софт использовать access=destination?
Что-то сомнительно, что по парковкам разрешён транзит…
osm2mp на access=destination забивает, потому что в mp запрет транзита вообще не предусмотрен.
Или, если с другой стороны посмотреть, запрет проезда там приравнен к запрету транзита (как минимум для гарминов), так что может быть стоит destination считать как no.
osm2mp на access=destination забивает, потому что в mp запрет транзита вообще не предусмотрен.
Или, если с другой стороны посмотреть, запрет проезда там приравнен к запрету транзита (как минимум для гарминов), так что может быть стоит destination считать как no.
Может все-таки разрешать доставку и чрезвычайные службы?
Кстати, а не предпочтет ли навигатор барьер с подобными разрешениями газонам и пешеходным дорожкам?
BTW: Для того же навитела есть RouteParamExt=1, запрещающий транзитный траффик, вот только не знаю начал ли он (навител) его понимать.
Для того же навитела есть RouteParamExt=1, запрещающий транзитный траффик, вот только не знаю начал ли он (навител) его понимать.
Он где-нибудь описан?
Он где-нибудь описан?
Упомянут в “ChangeLog” к версии 1.0.58.0 GPSMapEdit’а:
В окне ‘Object Properties’ в закладке Routing добавлен флаг “No t&ransit traffic”, запрещающий сквозное движение по дороге. Этот флаг сохраняется только в формате NTM, а также в формате MP в нестандартном атрибуте “RouteParamExt=”.
Сомневаюсь, что где-то есть более подробная документация на расширения mp от Галичского. Но можно спросить его самого. К тому же и так понятно, как этим атрибутом пользоваться.
Доделал первую “вменяемую” итерацию XML-файла, содержащего ВСЕ пары key=val для OSM тегов, перечисленных в http://wiki.openstreetmap.org/wiki/RU:Map_Features (первая и вторая колонка таблиц), некоторые из пояснений и http://wiki.openstreetmap.org/wiki/RU:Howto_Map_A. Кроме того, добавлено полтора десятка наиболее часто встречающихся в РФ (по статистике, собранной ниже программой) тегов.
Файл может использоваться как в качестве оффлайн справочника, так и в качестве источника данных для программы, работающей с файлами OSM.
Кроме того, прилагается как раз программа, использующая этот файл - консольная утилита (WinAPI), собирающая статистику по использованию стандартных (т.е. тех, что описаны в Map_Features и, главное, - в XML-файле) и нестандартных (всех остальных) тегов.
Заодно хотелось бы получить некоторую информацию по выяснить мнение насчет целесообразности включения в файл некоторых других тегов:
ссылка на скачивание XML-файла и программы: http://slil.ru/29178731
Там же пример запуска (файл run.bat) - переделать под нужный путь и имя файла.
А это - readme.
Здесь присутствуют две сущности:
1. XML файл, содержащий список "стандартных" тегов OSM для зоны RU.
2. Программа, которая, используя этот файл, позволяет получить статистику использования в конкретном OSM файле как стандартных, так и нестандартных тегов.
1. XML файл.
Пока его формат окончательно не устаканился. Возможно, между корнем и списком допустимых тегов появится еще один уровень - для группировки тегов по назначению. Порядка 200 элементов в общем списке - не очень удобно для визуального восприятия.
В настоящее время время элементы имеют 3 уровня вложенности:
1. Корень <OSM_tag_doc>, не имеющий ни атрибутов, ни тела (текста), содержит лишь элементы единственного типа <key>.
2. Элементы типа <key>, не имеют тела, содержат атрибуты "k" (в дальнейшем называемый ключом или key) и "desc". Первые содержат одноименные атрибуты тегов (<tag>) OSM-файла, а вторые - краткое описание назначения ключей. Кроме того, они содержат один или несколько дочерних элементов <val>.
3. Элементы типа <val> (значение), имеют тело с описанием назначения и использования комбинации key=val, а также атрибуты "v", содержащий одноименный атрибут тега OSM-файла, и "dst", содержащего одну или несколько букв из набора [NWAR]. Последний атрибут указывает, к какому типу объектов может быть применена комбинация key=val: node, way, area и relation соответственно.
Отдельный элемент-ключ "fee" с двумя вложенными значениями: "yes" и "no" приведен ниже в качестве примера.
<key k="fee" desc="Уточняющий тег, означающий необходимость оплаты соответствующих услуг">
<val v="yes" dst="N">Плата за услуги</val>
<val v="no" dst="N">Бесплатно</val>
</key>
Кроме точных значений в файле применяются маски, начинающиеся с символа "%", например: "%String", "%Number", "%DayOfWeek", которые могут обозначать произвольную строку, число или день недели. Обычно эти маски используются в качестве val/значения, например:
<key k="maxspeed" desc="Ограничение максимальной скорости">
<val v="%Number" dst="W">Ограничение максимальной скорости (в км/ч).</val>
</key>
или
<key k="name" desc="Общеупотребляемое наименование объекта">
<val v="%String" dst="NWA">Общеупотребляемое наименование объекта.</val>
</key>
но иногда может встречаться и в качестве суффикса key/слюча:
<key k="wikipedia:%String" desc="Статья в Википедии на соответствующем языке">
<val v="%Url" dst="NWAR">Статья в Википедии на соответствующем языке</val>
</key>
Надеюсь, этой информации окажется достаточно, чтобы при необходимости дополнить имеющийся файл необходимыми сведениями. Это можно сделать как в обычном текстовом редакторе, так и в любом из многочисленных XML-редакторов, имеющихся в Сети.
В настоящее время файл содержит ВСЕ пары ключ=значение из всех таблиц http://wiki.openstreetmap.org/wiki/RU:Map_Features (т.е. первую и вторую столбцы таблиц), некоторые из пар, указанных в описании (т.е. в 4-м столбце), некоторые из http://wiki.openstreetmap.org/wiki/RU:Howto_Map_A, а также несколько тегов, которые употребляются настолько часто, что обойти их вниманием было просто невозможно:
- cladr:code
- cladr:name
- cladr:suffix
- cladr:note
- addr:postcode
- addr:district
- addr:region
- cadaster:code
- omkum:code
- omkum:old_name
- sorting_name
- building:levels
- fee
- restriction
- shelter
Я лично вижу минимум 3 варианта использования данного файла:
1. В качестве оффлайнового сроавочника, который, вместе с тем лучше структурирован, чем Map_Features. Смотреть глазами при помощи XML-редактора.
2. В качестве источника данных для программы, анализирующей или обрабатывающей OSM-файл.
3. Совместно с прилагаемой программой сбора статистики.
!!! Еще раз напоминаю, что, вероятно, формат файла будет несколько пересмотрен, так что при использовании данного файла в качестве источника данных для программы, следует учитывать возможность появления дополнительного уровня между <OSM_tag_doc> и <key>. !!!
2. Программа для получения статистики по используемым в OSM-файле тегам.
Пока представлена пре-альфа версия программы. Соответственно принимаются пожелания по совершенствованию и изменению.
Программа представляет собой утилиту командной строки в формате Windows Console, использующей функции WinAPI для работы с файлами и получения времени. В качестве единственного (пока) параметра, передаваемого программе, используется имя файла, который нужно проанализировать. При появлении других ключей они будут начинаться с "/". Выходной файл программы имеет предопределенное имя Tag_Stat.txt, при необходимости пакетной обработки его можно будет переименовывать сразу по завершении работы программы. Запускать в Linux/Wine не пробовал, но не вижу для этого каких-либо препятствий.
Программа не проверяет совпадение атрибута dst с фактическим, т.к. на уровне тегов невозможно отличить way от area. Возможно, различение 3-х вариантов: N, W/A и R в дальнейшем будет реализовано.
Программа не проверяет, является ли %Number в действительности числом и аналогично с другими "свободными" параметрами, считая, что если указан "%", то в дальнейшем может быть что угодно. (различие %String, %Number, %Date, %URL, ect. программой не используется)
Сначала выводится статистика по "неправильным" тегам, т.е. тем, что отсутствуют в прилагаемом XML-файле, а затем по "правильным". В дальнейшем статистику по "правильным" тегам можно будет отключить, а для "неправильных" регулировать (например, приводить только по key без val).
Сначала выводится key, строка при этом начинается с "======". Выводится количество, сколько раз встретился этот ключ, количество дочерних val для него и его название в угловых скобках. Если в качестве val допустимо произвольное значение ("%"), то вместо "======" выводится "%%%%%%".
Затем выводится список относящихся к нему значений, начинающийся с нескольких пробелов, после чего идет количество повторений, параметр dst (NWAR) и также название в угловых скобках.
Программа пока не оптимизирована по размеру, но обрабатывает всю московскую область (380 Мбайт) за 17 секунд на Athlon 4800/2 Gb и менее 50 секунд на "смешной" конфигурации Atom/1Gb.
В качестве возможных вариантов использования программы:
1. Скачать себе фрагмент osm, провести оффлайновую правку и перед закачкой обратно проверить, не появились ли "нестандартные" теги, которые обычно являются ошибками или опечатками.
2. Провести анализ интересного региона с целью выявить, что в нем нужно "приводить в соответствие".
3. Сбор статистики для разработки конвертеров и других сервисных программ OSM.
Программа использует ограниченный набор функций API, работает строго локально, не "лезет" в Интернет и не совершает других "неприятных" действий, тем не менее, ничего кроме as_is я предложить не могу - каждый волен использовать ее исключительно на свой страх и риск.
PS. Да, программа пре-альфа, так что принимаются пожелания и багрепорты.
PPS. А по поводу XML вопрос - стоит ли сделать промежуточный уровень, чтобы удобнее было просматривать его глазками (естественно, в XML-редакторе, позволяющем сворачивать и разворачивать отдельные “ветки”)?
Заодно хотелось бы получить некоторую информацию по выяснить мнение насчет целесообразности включения в файл некоторых других тегов:
Думаю, сюда надо писать.
Нужно поправить страницу “описание тегов запрета поворота” Дело в том, что знак “прямо и направо” запрещает не только поворот налево, но и разворот (в отличии от знака “прямо и налево”, который практически эквивалентен “поворот направо запрещён”), нужно отобразить на странице, что для одного знака ставятся два запрета, для другого - один.
Кмк, для “поворот налево запрещён” надо ставить тег запрета, для “прямо и направо” - два тега разрешённого движения, это и с точки зрения ГОСТа, ПДД и здравого смысла логичнее.