Теги: стандартизация и исправление ошибок.

Вообще вроде бы да. Если память не изменяет сервисом может быть обозначено много чего, например питлэйн на гоночной трассе :slight_smile: там сквозной проезд разрешен. Но это конечно не к нашим реалиям. Вроде если не стоит знак жилая зона то сквозной проезд разрешен?

Вообще я за обозначение вида 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-редакторе, позволяющем сворачивать и разворачивать отдельные “ветки”)?

  • network - обычно некое множество, внутри которого ref является идентификатором
  • station - тип ж/д станции
  • transport - Vovanium предложил
  • route_ref - список маршрутов для остановки транспорта, есть в вики
  • telephone - менять на “phone”
  • addr:full - полный адрес, хорошая штука
  • maxspeed:practical - реальная обычная скорость потока, я её использую
  • cladr - по-моему, атавизм ранних версий кладробота. сносить
  • livingstreet - менять на living_street
  • left:region, right:region - рудимент, но пока лучше не трогать
  • district - скорее всего менять на addr:district
  • address:type, address:a3, address:a2, address:a6 - белорусская схема адресации. у нас она тоже некоторым понравилась - так что не трогать
  • color - цвет таблички, насколько я знаю

Думаю, сюда надо писать.
Нужно поправить страницу “описание тегов запрета поворота” Дело в том, что знак “прямо и направо” запрещает не только поворот налево, но и разворот (в отличии от знака “прямо и налево”, который практически эквивалентен “поворот направо запрещён”), нужно отобразить на странице, что для одного знака ставятся два запрета, для другого - один.
Кмк, для “поворот налево запрещён” надо ставить тег запрета, для “прямо и направо” - два тега разрешённого движения, это и с точки зрения ГОСТа, ПДД и здравого смысла логичнее.

Вы тут спорите о стандартизации тегов, а некоторые люди не заморачиваются, и рисуют совсем без тэгов:
http://www.openstreetmap.org/browse/way/60302251/history
http://www.openstreetmap.org/browse/way/59479322/history
http://www.openstreetmap.org/browse/way/51119850/history

И если смотреть через http://tools.geofabrik.de/osmi/ таких много…

Никто не хочет им объяснить, что так делать неправильно?

Иногда это такое получается, когда рисуешь много объектов, а потом теги навешиваешь скопом и какой-то из них забываешь выделить. Или я вот когда катаюсь в osm2go рисую абы как, иногда не вешаю теги, если и так понятно, что там, почти никогда не стыкую линии. Ну неудобно это стилом вырисовывать. А потом правлю в JOSM, тоже иногда не все замечаю.

Увы, при сегодняшней структуре OSM трудно понять, правильно это или неправильно. Например, можно нарисовать кучку безымянных веев, после чего объединить их в релейшн со всеми необходимыми тегами.

линия без тэгов и не в релейшене это ошибка.
А объединять в релейшен лучше не потом а в одном changeset с созданием линии.

Да, вопрос в другом: по самой линии нельзя сказать, входит она в релейшн или нет. Соответственно, невозможно и провести “локальное” детектирование ошибок.

Я думаю, это уже вопрос индивидуальных предпочтений. Кроме того, зависит от того, пользоваться онлайновыми или оффлайновыми средствами.

Вообще то и josm и браузер показывают релейшены, в которые входит данный объект.
Вот пример линии с релейшенами: http://www.openstreetmap.org/browse/way/48857546
Там внизу под списком нодов:

Участвует в:
Отношение Хабаровский край (151223)
Отношение Российская Федерация (60189)

Причем здесь josm и браузер? (на самом деле даже не браузер, а http-сервер)
И там и там результат ОБРАБОТКИ ВСЕГО файла.
Есть XML файл установленного формата (называется *.OSM). Локально же по фрагменту файла, описывающему путь, выяснить, входит ли он в какие-либо отношения, невозможно. Для этого нужно обрабатывать ВЕСЬ файл.