Какая клёвая штука, спасибо 
Вы правы, я не совсем прав. Но я старался подобрать наиболее подходящий тег. Т.к. по большому счету, зимовье это то же shelter (укрытие, убежище) только с крепкой дверью, печью и запасом дров (обычно). Кто то даже может сказать, что это одно и тоже и разница видна только мне. (тем более если можно еще указать наличие очага) Поэтому я и сомневаюсь. Для этого видимо и нужно где-то обсуждать применение подобных тегов. И рекомендации по их использованию. Главное что бы это shelter на территории тайги понималось однозначно.
По поводу зимников. Да это вариант. Но к сожалению, я не живу рядом с этим зимником. И у меня не возможности отслеживать время его открытия-закрытия. Сейчас на него уже можно поставить запрет. Но вот когда он откроется, я может быть буду в командировке без доступа к И-нету. Да и к каждому зимнику не приставишь дежурного, хотя конечно это и мысль, но боюсь не осуществимая. Кроме того, как я уже писал, в разное время там может ездить разный транспорт. Как все это учесть? (на тот зимник, что я нанес на карту поставил access=no)
Так как я новичок то еще не разобрался в механизме перехода предложенных тегов по маршруту форум-пропозал-карта. Вот и подумалось мне, что может быть в месте существования подобного списка и делать это бы было проще. (предлагать и продвигать в сторону карты) Возможно, что и ошибаюсь. Или на форуме создать одну ветку для всех предлагаемых тегов. Поэтому по существу вопроса я и ответил, что список нужен более подробный и учитывающий российские реалии.
Так уж исторически сложилось, что территория нашей страны не ограничивается территорией Калининградской обл. (может и к сожалению, но факт). Я не писал, что замков вообще нет. (чего у нас только нет!) Но думаю что если взять всю территорию “нашей необъятной” то зимовий все таки будет больше.
Имхо зимники надо как-то явно указывать, а не отслеживать время открытия/закрытия.
И они наверно должны в 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 service=дворовый_проезд, но только перевод адекватный для дворового проезда найти.
Следить за зимниками иногда можно не выходя из дома. Например тут: http://www.berezovo.ru/manage/site?tid=633200029 написано
Нет.
Буду знать. Тогда может и вправду считать что для всех service сквозной проезд запрещен.
Через парковки транзнит вроде как не запрещен.
IMHO, при наличии living_street=yes должны подразумеваться access=destination (как раз запрет транзитного проезда) и maxspeed=20 (на всякий случай). Умеет ли osm2mp и дальнейший софт использовать access=destination?
Что-то сомнительно, что по парковкам разрешён транзит…
osm2mp на access=destination забивает, потому что в mp запрет транзита вообще не предусмотрен.
Или, если с другой стороны посмотреть, запрет проезда там приравнен к запрету транзита (как минимум для гарминов), так что может быть стоит destination считать как no.
Может все-таки разрешать доставку и чрезвычайные службы?
Кстати, а не предпочтет ли навигатор барьер с подобными разрешениями газонам и пешеходным дорожкам?
BTW: Для того же навитела есть RouteParamExt=1, запрещающий транзитный траффик, вот только не знаю начал ли он (навител) его понимать.
Он где-нибудь описан?
Упомянут в “ChangeLog” к версии 1.0.58.0 GPSMapEdit’а:
Сомневаюсь, что где-то есть более подробная документация на расширения 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-файле) и нестандартных (всех остальных) тегов.
Заодно хотелось бы получить некоторую информацию по выяснить мнение насчет целесообразности включения в файл некоторых других тегов:
- network - что это вообще такое? по http://wiki.openstreetmap.org/wiki/Key:network ничего получить не удалось
- station, transport - и чем они отличаются друг от друга (обычно встречаются вместе)?
- route_ref
- parking - не то же, что amenity=parking, здесь parking - это ключ. Что это и какие допустимы значения?
- label - более сотни значений от “0 км” до “108км”.
- comment - вообще такое есть, либо это ошибочные вариации на тему note или description?
- telephone - 315 штук только в пределах Московской области. Думаю, это нужно как-то автоматизированно менять на “phone”.
- addr:full - это вообще кому-нибудь интересно? Ведь гораздо проще собрать полный адрес из отдельных составляющих, чем правильно разобрать его на части. Так нужно ли такое дублирование?
- addr:district2 - что это такое и почему не хватает addr:district? Тем более, что встречается это практически только в “Можайский адм. район”.
- maxspeed:practical - что это и чем отличается от просто maxspeed?
- cladr - думаю, нужно так же автоматом сравнить с имеющимися cladr:code и cladr:note и либо внести в последние, либо просто выбросить.
- ski - я понимаю, - популярный спорт, но чем не устраивают стандартные теги sport?
- livingstreet - с единственным значением yes. Чем это лучше, чем living_street = yes? Может, тоже автоматически заменить.
- addr:street2 - вопрос аналогичен addr:district2
- addr:housenumber2 - ?
- paved - что это?
- left:region, right:region - я так понимаю, это атрибуты границы? вообще-то такие вещи разумнее делать ссылкой, а не дублировать десятки раз одну и ту же строку в разных местах.
- district - чем это отличается от addr:district? Почему-то встречается только в Капотне.
- lot - что это? Значение - число из первой сотни. Каждое - уникально (по крайней мере, в пределах МО).
- address:type - что это и какие может принимать значения? две трети “a6”.
- address:a3, address:a2, address:a6 - ?
- color - ?
ссылка на скачивание 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-редакторе, позволяющем сворачивать и разворачивать отдельные “ветки”)?