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