Собственно, ничто не мешает выгонять ли в XML параллельно JSON, пусть юзают кому что нравится.
Кстати, для тегов с нефиксированными (или не только фиксированными) значениями можно предусмотреть value в формате регэкспа. Ну и пометки им вида «Осторожно», «Устарело, рекомендуется X» и т.п.
Хэх, да)))) Ну так вообщем и целом мне только одно пока не понятно, как удобно теги друг с другом с ассоциировать (и в БД и в интерфейсе редактора справочника).
PS формат действительно какой угодно, ибо это наверное самая простая часть справочника - экспорт
В смысле — ассоциировать? Ты хочешь сделать how to map a? :3
Ну тогда это фактически сборник пресетов, отдельный документ. В нём даётся название и описание сущности на разных языках («овраг»), ключевые слова для поиска («овраг», «яма» и т.п., не знаю, нужно ли это вообще, на сайте наверняка поиск можно будет делать по всей текстовой части (sphinx, например, он несложно конфигурируется)). И таки да, список тегов, применяющихся к сущности. Как определяющие теги (без которых овраг не будет вообще обозначен), так и дополнительные (глубина, например).
Нет я не об этом, то что ты сказал это ключевые слова.
Я о том что чуть выше обсуждали, что тега “дворовый проезд нет” как и тега “тротуар” - это пары тегов. Или что к river желательно указать ещё N тегов, также как и highway…
Соответственно, если значение задано, то его не надо показывать в диалоге для ввода. Если нет, то показываем стандартные варианты для этого тега. Если задано несколько, то даём возможность выбирать.
Описания тегов, конечно, берутся из документа с тегами. Важно понимать, что в результатах лайв-поиска (в редакторах) сверху нужно выводить именно пресеты, а не теги. То есть, по началу запроса «троп» первым делом должен идти этот пресет Тропа.
Внутри БД можно ещё сделать айдишники для тегов, чтобы в описаниях ссылаться на них, а не на название. Но вообще, название с успехом может быть айдишником. У нас есть случаи разных по смыслу тегов с одинаковым названием?
На вскидку: height, который можно трактовать и как “высота верхней точки” и как “высота объекта”.
Есть ещё service=, которые трактуются в зависимости от shop= или highway=, или railway= и т.д.
В общем, ждём сервиса и няшного сайтика. Возможно, после внедрения поддержки в редакторы тема «Как обозначать» перестанет расти с такой скоростью.
key в моём XML — это тег в терминах OSM, amenity
value — это parking
Всё это я обзываю tag, потому что вся конструкция внутри пресета (thing) обозначает, что в пресете применяется такой-то тег (один!) с такими-то значениями.
Я бы советовал в xml активнее использовать атрибуты.
Пару лет назад пытался сконструировать такую структуру, получилось примерно следующее:
<?xml version="1.0" encoding="UTF-8"?>
<OSM_tag_doc>
<key k="highway" desc="Дороги, улицы">
<val v="motorway" dst="W">Автомагистрали (обозначенные знаком 5.1 "Автомагистраль" ) — автомобильные дороги, имеющие многополосную проезжую часть с центральной разделительной полосой, и не имеющие пересечений в одном уровне с другими автомобильными и железными дорогами, трамвайными путями, велосипедными и пешеходными дорожками. По умолчанию — односторонняя дорога (т.е. каждое направление рисуется отдельно), если же оба направления нарисованы одной линией, то необходимо добавить oneway = no . Этим тегом следует обозначать только дороги класса trunk , для местных автомагистралей следует использовать primary + motorroad = yes + maxspeed =110 .</val>
<val v="motorway_link" dst="W">Соединительные дороги автомагистралей ( motorway ) с другими дорогами (возможно более низкого класса). Этим тегом обозначают небольшую дорогу, представляющую собой съезд с автомагистрали или въезд на автомагистраль. Являются частью дорожно-транспортной развязки (наклонные съезды/въезды, пандусы). Они обычно имеют такие же ограничения, что и автомагистрали (motorway). Для избежания неоднозначности, рекомендуется всегда добавлять тег oneway =* .</val>
<val v="trunk" dst="W">* автомобильные дороги входящие в Европейские маршруты автомобильные дороги входящие в Международную азиатскую сеть автомобильные дороги федерального значения, межрегиональные трассы, формирующие опорную сеть автодорог страны: дороги, по которым идёт дальний основной и грузовой межрегиональный трафик дороги, последовательно соединяющие несколько крупных городов региона дороги к международным аэропортам и крупным портам Сеть дорог класса trunk должна быть связной в пределах всей страны, следовательно: дорога класса trunk не должна прерываться внутри населённых пунктов (если это единственный транзитный маршрут) дорога класса trunk может начинаться и заканчиваться только внутри крупных населённых пунктов, соединяясь с дорогами класса не ниже primary</val>
<val v="trunk_link" dst="W">Соединительные дороги межрегиональных трасс ( trunk ) с другими дорогами (возможно более низкого класса). Этим тегом обозначают небольшую дорогу, представляющую собой съезд с автотрассы или въезд на автотрассу. Являются частью дорожно-транспортной развязки (наклонные съезды/въезды, пандусы). Они обычно имеют такие же ограничения, что и межрегиональные трассы ( trunk ). Для избежания неоднозначности, рекомендуется всегда добавлять тег oneway =* .</val>
<val v="primary" dst="W">Автомобильные дороги регионального значения, соединяющие города и/или областные центры, дороги межрегионального значения, не являющиеся trunk . В населённых пунктах — центральные магистрали городов (в небольших населённых пунктах могут отсутствовать).</val>
<val v="primary_link" dst="W">Небольшие соединительные дороги между дорогами класса primary и другими (возможно более низкого класса). Для избежания неоднозначности, рекомендуется всегда добавлять тег oneway =* .</val>
<val v="secondary" dst="W">Автомобильные дороги областного значения, соединяющие
областные центры с крупными населёнными пунктами (районными центрами), а
также крупные населённые пункты между собой. В населённых пунктах — основные магистрали районов города (в небольших
населённых пунктах могут отсутствовать).</val>
...
<val v="%String" dst="NW">Смотри Tagwatch для других используемых значений.</val>
</key>
<key k="junction" desc="Круговое движение">
<val v="roundabout" dst="WA">Круговое движение. При установке данного тега автоматически
устанавливается одностроннее движение.</val>
<val v="%String" dst="W">Смотри RU:Key:junction или Tagwatch для других используемых значений.</val>
</key>
<key k="construction" desc="Стройка">
<val v="%String" dst="W">Можно поставить любой линейный объект, к примеру construction =motorway . Использовать с highway=construction .</val>
</key>
...
<key k="shelter" desc="Приют, убежище, укрытие">
<val v="yes" dst="N">Приют, убежище, укрытие</val>
<val v="no" dst="N">Приют, убежище, укрытие</val>
</key>
</OSM_tag_doc>
При этом в файле имеются элементы первого уровны - key, обозначенные атрибутом “k”, в них вложены допустимые элементы val, имеющие атрибут “v”. Помимо этого имеются атрибуты desc - основное определение, dst - к каким объектам может относиться ([N][W][A][R]). В теле вложенного элемента имеется подробное описание.
В качестве специальных псевдозначений используются v=“%String” и v=“%Number”.
Но потом от поддержки этой структуры отказался. Для моих целенй оказалось целесообразнее использовать единственную простую таблицу (храню в excell, импортирую и экспортирую в виде текста), в которой вместе с параметрами, заимствованными из OSM хранятся также параметры необходимые для рендера.
Т.е. используется один и тот же файл как парсером, так и рендером. В настоящее время поддерживается около 800 пар key-value + несколько комбинаций разбирается вручную (в смысле программным кодом не по общему алгоритму): name*, place, place_of_worship…
А почему, собственно XML? Потому что популярен? Почему не взять YAML, он гораздо менее избыточен и удобнее в редактировании? Или вовсе JSON, он проще?
Пока не видно, чем это лучше парсинга вики, за исключением двойной работы. В формате должна быть информация, полезная именно для машин. как то:
Совместное использование тегов: например, значения service зависят от «ведущего» тега.
Например:
Название пешеходной дорожки
Подстановка по-умолчанию: oneway для motorway, layer для bridge, в более сложных случаях — какое конкретное число понимается под maxspeed=national (или как его там).
…
Совместное использование с другими объектами (junction и crossing предполагает примыкание дорог, не может стоять на пересечении реки и ЛЭП, например).
……
Также не следует забывать указывать язык: Автомагистраль…
).
Сомнительного качества предложения. Предпочтительнее более длинный вариант: nodes=true, ways=true, areas=true, relations=true, иначе помимо парсера xml придётся ещё один парсер для этой строки приделывать.
Первый шаг сделан, теги из taginfo импортированы в базу)
Кто готов быть редактором тегов? Записывайтесь сюда или на мыло, выдам доступ, как морда оживёт редакторская.
