Объяснение почему не нужно парсить ключи чтобы спросить все amenity=
Объяснение почему в рамках API 0.6 приходится парсить sport:billiards: у части key=
Объяснение почему нужно столько ключей, какие преимущества при маппинге для обычного пользователя
Предложение избавится от ключей вообще, писать текст и размечать его по желанию
В чем проблема старых key=value? Мапперы злопооутребляли частью “value”, когда этого делать не стоило. Постоянные вопросы “как обозначать X” это симптомы проблемы. Беда в онтологии и классификации тегов.
amenity=* - ничего не значит этот ключ.
man_made - всё подряд лепят в man_made, “потому что их много” и он не рендерится пока ещё
leisure/amenity - кто вообще додумался до такой классификации. Ну да ладно. Теперь это будут просто исторические префиксы.
Попытаюсь сейчас целую науку объяснить на пальцах.
Если у нас было
здание=да (building=yes)
То когда мы хотим указать свойство объекта мира (здание), мы не пытаемся его прилепить в значение старого свойства.
здание=да; 3 этажа
Мы вводим новый тег, с новым смыслом
здание=да (building=yes)
здание:колвоэтажей=3 (building:levels=3)
Если у здания есть крыша, то в терминах OSM нужен новое свойство-подтег:
здание=да
здание:колвоэтажей=3
здание:крыша=есть
Если у крыши есть цвет то его нужно указывать как свойство у крыши (которое свойство здания)
здание=да
здание:колвоэтажей=3
здание:крыша=есть
здание:крыша:цвет=есть
Если у крыши есть **определённый цвет **то его нужно указывать как свойство у цвета, которое свойство крыши, которое свойство здания:
здание=да
здание:колвоэтажей=3
здание:крыша=есть
здание:крыша:цвет=есть
здание:крыша:цвет:определённый=красный
OSM API 0.6 убог и считает что двух цветов у крыши не может быть:
здание:крыша:цвет:определённый=красный
здание:крыша:цвет:определённый=жёлтый
API нужно менять чтобы можно было указывать несколько значений:
здание:крыша:цвет:определённый=[красный, жёлтый] - массив
Пример с цветами крыш на самом деле плохой
Для рендера мы используем hex-значения цветов: http://taginfo.openstreetmap.org/keys/building%3Aroof%3Acolour#values
Тем не менее возникают ситуации когда нужно отмечать несколько значений. Хороший пример был с разновидностями бильярдов.
В новом (никем не разработанном API) это можно представить так:
sport:billiards=yes
sport:billiards:type=[“pool”, “snooker”, “pyramid**:10ft**”, “pyramid**:12ft**”]
Как вы могли заметить, значениями value здесь опять злоупотребляют, поэтому приходится вводить отдельное свойство для размера стола:
sport:billiards:table_size = [pool:(7ft, 8ft), snooker:(9ft, 12ft)]
Сложность онтологий растёт колоссально быстро. Тем сумашедшим котортые пытаются обработать её самым формальным языком на земле (регулярными выражениями, автоматами) я предлагаю остудить пыл и признать фиаско до того как потратят всю свою жизнь на составление онтологии мира (мега-регулярки, которая “теперь точно и безошибочно обработает этот ключ”, ещё одного геокодера, ещё одного рендера).
Отказ от слишком жёстких и на деле не работающих тегов совсем
Более адекватный подход был предложен с использованием свободного для написания **простого текста **и свободного для разметки смысловыми конструкциями:
фигурные скобки - ограничитель смысла (в программировании это неймспейс)
хеш-тег - это старые теги магазинов которые мы импортируем из старой базы. shop=tea станет #shop:tea, shop=yes станет #shop
элементы разметки для разметки свойств хеш-тегов - пока неясно какой стандарт или подход выбрать лучше в рамках OSM
Чего будет не хватать при таком подходе?
Можно ли написать препроцессор который будет все запросы старых API (0.6, overpass) транслировать в поиск хеш-тегов и обработку разметки? С чем можно столкнуться?