Вы просто не поняли одной простой вещи, что “building=yes” это вовсе не “здание=да”, а “здание=на знаю точно какого типа (iшкола/многоквартирный дом и т.п.) и при случае надо бы поставить правильный тип”.
В highway ровно для этих целей используют highway=road
Поэтому логично, что для указания другого свойства у этого здания используют другой тег, а не тег типа здания.
Ну и далее
здание:крыша=есть
здание:крыша=лениво уточнять тип, покатая или еще какая, сделайте это за меня, кто в курсе
Исходя их этого
здание:крыша:цвет=есть
безумие. Ибо на самом деле получаем
здание:крыша:цвет=не знаю какой
highway=road подтверждает что есть дорога
building=yes подтверждает что есть здание (здание=да)
highway=road не указывает **конкретный тип **дороги (highway=primary, highway=service, …)
building=yes не указывает **конкретный тип ** здание (жилое. производственное)
Что я не понял и как это противоречит с моим высказыванием?
Это не нормально, это заляпа , такой фиксми. То есть тут принципиально не булева переменная. Не наличие, но тип!
И верное значение ее нельзя вывести из одного только наличия building:level
API 0.8 должен в какой-то степени (указывается в параметрах запросов к API) позволять “разворачивать” вложенность структур:
К JSON-у не думаю что стоит прибегать потому что мы и так xml пользуемся (osmosis переписывать не ok) да и типизация в JSON костыльная http://json-schema.org/, а не десятилетиями рабочий xsd.
Тем кому нужен будет xsd - будут его использовать, тем кому не нужен навязывать его не будем, от XML точно отказываться не нужно. Пытаться добавлять JSON как дополнительный формат ответа от API (параллельно XML) - да.
Наличие building:roof:* по старой схеме ни о чём не говорит, новые смысловые конструкции придётся дополнительно обрабатывать с учётом сюрпризов
highway=road
building=yes который некоторые считают еще “неопределённым типом”
Ну это можно учесть до какой-то разумной степени. Это же режим совместимости с 0.6 в котором все неоднозначности не получится разрешить в принципе изза строка=строка.
Нагромождений вида building=levels,height,material,roof можно избежать написав код-обработку. Для всех данных в OSM - нет, для большинства POI ключей (sport, amenity, shop, leisure) и building-ов - скорее да чем нет.
Вы ещё ASN.1 предложите
Текст удобнее тем, что для него много средств по сравнению, синхронизации, версионности, слияния и прочего.
Да и живут текстовые форматы дольше, ИМХО, - пока на них есть документация. А бинарные - пока есть рабочий софт по их парсингу.
Такое не предлагается. Это основа онтологии и вменяемых информационных систем, кто бы и что про неё не думал.
Мы прячем старые говорливые теги в иерархии меток. Метки могут быть иерархичны (метка ##shop:tea зависит от #shop), а могут быть полностью независимы (более адекватный подход, позволяет несколько таксономий, которые если очень хочется можно потом объединить новой более общей меткой или зависимостью от другой метки)
В недоработанной онтологии OSM пользователи путают атрибут (key=value) и понятия (##метка у семантической коробки). Класса объекта в OSM нет. Нет машинно-читаемого архетипа, если вам будет проще.
Проблема в том что главная ##метка меняется:
пишете ли вы рендер (для всего мира, только для одной страны)
пишете ли вы геокодер (самая сложная задача для всего мира вообще, ответы на вопрос “как назвать этот объект?”)
что является для вас “спортом” (бокс - нет, шахматы - да, фигурное плавание - нет, компьютерные игры - нет)
интересны ли для вас только группы спортов (только бильярды)
Вопрос сложный, зависит от цели для которой вы хотите распарить объект. На понятийном уровне нужно учитывать семантические коробки (фигурные скобки у синтаксиса OverQuantum:
Т.е. чтобы распарсить такую структуру (я специально сделал #highway похожим на данные из OSM) для графа дорог логика будет очень похожа на предыдущую:
Если встречаешь у коробки #highway, то тебе эта группа тегов (коробка) как минимум интересна (валидация)
Если противоречивых тегов нет у коробки #highway ##nothighway, то можно собственно приступать к извлечению данных
2.1 можно останавливаться если встречаются метки, отличные от вашего белого списка
2.2 можно продолжать извлекать данные, на свой страх и риск (те метки могут значить “это не дорога”, а могут не значит ничего ##ufo или вам не мешать ##namedobject)
Извлекаем только те атрибуты которые нам интересны (не нужно имя для графа дорог) и умываем руки
тот же самый объект реального мира могут замапить как
##namedobject
{
#name: улица Космонавтов
#name:ru: улица Космонавтов
#name:en: Kosmonavtov street
#description: угадываю название на Английском
}
##highway
{
#surface: asphalt
#oneway: true
#lanes: 2
#maxspeed: 40
#name: улица Космонавтов
}
Геокодер может обрабатывать только коробку с ##namedobject если хочет работать быстро или “смотреть атрибуты только для него”. Тегирование под роутинг, геокодинг и рендеринг (#hex-значения, которых в реальном мире-то нет) это вообще-то, нормально. Просто делать нужно в отдельных для этого местах, чтобы людей не смущать.
“Постойте-ка в реальном мире только одно имя, мы тут сущности плодим”.
В этом вся соль и есть. Онтологии не строятся из абстрактных побуждений ##объектмира, ##боженькасотворил.
Вместо этого абсолютно все пользователи будут использовать самые-самые практичные для них онтологии:
#shop // не самая лучшая идея, я бы сразу использовал ##sells:goods и ##sells:services
#poi // плохая категория, я бы такую не стал использовать
Что делать если на вашу очень осмысленную коробку покушаются какой-то непонятной меткой? Завелось тут ##ufo понимаешь, что с ними делать теперь. Ну во-первых, спросить у автора метки ##ufo (до этого дооооооолгий и мучительный процесс принятия тегов) что он хочет с ней делать или посмотреть что он написал в её описании на вики, может быть она вам не навредит с её атрибутами.
Если не походит чья-то метка, делайте копию старой вашей коробки. Например: у вас было #highway {}, кто-то пришел и указал #highway #poi {}
Эту схему poi вы считаете непримиримой к данному объекту реального мира, у вас пасинг ломается от её специфических атрибутов схемы #poi. Эту ситуацию мы всегда видим у приверженцев тега type=. **У одних одно, у других он значит **другое.
Поэтому вы копируете старую коробку только с #highway и не мешаете людям экспериментировать с #poi. Может он у них заработает и вы к них присоединитесь. Может нет, у вас будет своя коробка (и ваш любимый хеш-тег на ней).
торгует экипировкой для мото, квадроциклистов и велосипедистов;
предоставляет услуги ремонта мотоциклов;
предоставляет услуги зимнего хранения мотоциклов, скутеров и шин;
предоставляет услуги гос. тех. осмотра мотоциклов;
как я понимаю, можно будет её описать так:
#shop
{
#motorcycles: japan / как тэг б/у поставить не придумал
#equip: motorcycles
#equip: atv
#equip: bicycles
}
#motorcycles
{
#sale: yes / value yes можно в принципе опустить
#type: enduro
#type: sport
#type: chopper
#made: suzuki
#made: honda
#equip / подразумевается yes
#winter_store
#safety_inspection
}
#equip
{
#motorcycles / подразумевается yes
#motorcycles: cross / особо отметим продажу кроссовой экипировки
#atv: winter / вот тут вопрос, только ли зимнюю экипировку продаёт магазин? нужно ли добавить просто тэг #atv, если не только?
#bicycles
#bicycles: contact_shoes
}
#safety_inspection
{
#motorcycles
}
#winter_store
{
#motorcycles
#scooters
#tires
#temperature: 17C
}
это на первый взгляд избыточно, но при составлении карты пунктов техосмотра нам достаточно запросить только глав-тэг #safety_inspection и разобрать его нутро, а не копаться в под-тэгах тэгов вида shop=motorcycles, как ныне.
при карте пунктов зимнего хранения - то же самое, достаточно глав-тэга #winter_store
карта магазинов экипировки (вело, мото, квадро, горнолыжной, снегоходной, каякерской) - опять же: #equip и не будем отвлекаться на магазины, продающие мотоциклы и пункты мото тех. осмотров.
карта “магазинов вообще” получит достаточную инфу из тэга #shop
на мой взгляд - очень приятная схема для создания софта, использующего ОСМ получается.
p.s. конечно, подобную контору необязательно описывать столь уж подробно. но, если такая возможность будет - весьма удобно.
В синтаксе OverQuantum предлагаю различать #атрибуты=значния (обычно внутри скобок) и ##понятия (главные теги в старой схеме OSM, poi-теги).
Найдутся конечно люди которые будут настаивать что #motorcycles это подсвойство магазина, но мне тоже нравятся разные понятия.
я бы назвал не одной меткой #motorcycles, а #sells:goods + #sells:goods:motorcycles
#equip#winter_store#safety_inspection я бы убрал из старого #motorcycles
#equip переименовал в #sells:goods + #sells:goods:motorcyclesequip + #sells:goods:equip
вместо #safety_inspection бы добавил ##sells:service:safety_inspection у магазина или другого объекта, я сам не пойму о какой инспекции идёт речь, для чего
#winter_store добавил бы теги #sells:goods:motorcycles + #sells:goods:scooters + #sells:goods:tires
Пример обсуждаем достаточно абстрактный, трудно сказать как лучше описать его сразу. Т.е. я хотел сказать что классы объектов вам гораздо важнее чем свойства внутри него при поиске/фильтрации/обработке.
Классами объектов в идеале нужно пользоваться так, чтобы потом на них использовать логику множеств, причем не обязательно непересекающихся. некоторые запросы будут ломаться, впрочем, как и сейчас в OSM
кстати, пример не сильно абстрактный. лично имел дело с двумя мото-конторами, одна из которых продаёт байки, экипировку и ремонтирует мото, плюс принимает байки на комиссионную продажу, вторая - продаёт мотаки, экип плюс услуги по ремонту и зимнему хранения мотоциклов.
при этом у торгового зала и ремонтной зоны разные телефоны и график работы.
при этом обе сильно отличаются от конторы-дилера, барыжащего новыми “ямахами”: мото, квадро, снегоходы, лодочные моторы.
Совсем упоролись. Json же! Несколько значений в квадратных скобках. Дикты и списки. Парсится на всех языках программирования. Определен ескейпинг. Стандартен чуть более чем полностью. Бросайте свои велосипеды. Джсон онли. Ну yaml в крайнем случае. Он лучше, но труднее валидируется и сложнее сам по себе.
А еще в постгресе знатная оптимизация и индексация джсона по полям плюс компактное хранение. Смекаете? Если внутри хранить именно так - Мегапрофит. Количество записей в бд резко сократится за счет денормализации.