тупо несколько значений в одном смысловом key=, потому что “прокатит”:
ref=3;4
Напротив:
shop:butcher:pork=* - очень организованный ключ, всякую чушь если и будут мапить, то вычистить легко даже по Taginfo, а не по твоим алгоритмам классификации которые будут решать “Мария” женское имя или мужское
ref=[3; 4] - тоже самое, ничего парсить не нужно, это массив
ref=3 - если маршрут один, то отличия можно определить по типу. Как ты собрался отличать что в строке есть несколько значений или только одно не зная весь (РЕАЛЬНЫЙ, ФИЗИЧЕСКИЙ) мир?
Согласен, это не отменяет что прямо сейчас по-нормальному ты указать не можешь два значения в <строка>=<строка>. Без парсинга в целом.
Тем что в первом тебе нужно убрать кавычки, это не тупые строки, а значения у которых поддерживают смысл, которые документируют на вики. Нижний пример это наоборот, тупая строка value в OSM, невозможен в парадигме <строка>=<строка>.
Затем что его просто расширять и разрабатывать для него. Не можешь понять какую-то “сложную” лично тебе структуру - игнорируй её.
Не заставляй всех писать “только строки” только потому что ты не умеешь писать программы работающие с другими структурами данных или не понимаешь весь смысл ключа со сложными структурами в нём.
(отвешивая челюсть) пункт прохождения гос. тех. осмотра (safety_inspection) у нас под-тэг тэга shop ? не ожидал, если честно
собственно, приведённая вики весьма показательна.
т.е. распространённые (и востребованные) в Питере конторы по зимнему хранению байков - это
shop=motorcycle
с под-тэгом services=winter_store что ли? при том, что они не магазины ну ни разу. мда, вот уж не ожидал.
т.е. дилер техники ямаха (мотоциклы, квадроциклы, снегоходы, лодочные моторы), пункт гос. тех. осмотра мотоциклов, салон мотоэкипировки, контора по ремонту байков - это всё один и тот же тэг shop ?
Насколько я понял, в предлагаемом API возвращаемое значение будет строго типизированным, т.е. в одном случае это действительно строка, а в другом — массив, который, в свою очередь, будет возвращаться то ли в виде XML-деревца, то ли в виде JSON, то ли еще как-то, но не как строка, соответственно можно запрашивать его элементы отдельно поштучно. А “[3;4]” — это просто условная запись, в реальности в таком виде оно возвращаться не предполагается.
Вот только и коммиты в этом случае должны валидироваться на соответствие типов. Соответственно, сервер должен иметь список возможных тегов с допустимыми типами для них. Иначе я плохо представляю, как программа-обработчик должна интерпретировать деревце совершенно произвольного вида с произвольными типами данных, полученное как результат какого-то запроса.
Ну это вроде еще не доработано, а сейчас предполагается, что тот, кто делает запросы, знает как именно выглядит это деревце и делает запросы сразу к его листьям, а не на несколько уровней выше.
Это написал romul_zurov для наглядности я думаю. В целом - достаточно будет ассоциативного массива с вложенностью, ничего хитрого.
Если захотят - будут вводить структуры set, multiset. Для отдельных ключей. Будут специализировать домены (ключи в OSM) если захотят. Абсолютно опционально. Всё как у больших дядь.
Те кто захотят связи определять связь в вики, определять формально в XSD между ключами
sport:billiard:type
и
sport:billiard:tablesize:snooker
sport:billiard:tablesize:pool
Пожалуйста - нет, не обязательно. Обрабатывать такие данные может быть проблемнее. “неочевидные теги в OSM” растут только отсюда.
UPD. Связь в вики просто указывается как | combination = у шаблона ключа. Без “роли”, смысла, простой ссылкой. Смысл и роль могут определить дотошные авторы самих ключей. Представь себе, их достаточно и они это делают.
Ну сейчас это отличается от того что я тебе писал только тем, что планируется, что апи умеет возвращать коллекции значений.
Но извини меня, парсер для коллекции кодированой в xml (ведь апи у нас по-прежнему возвращает xml) ничуть не проще чем парсер для значений разделенных ‘;’
Кто их будет видеть в сериализованном виде кроме базы данных и протокола?
Пользователю в JOSM будет не текстовое поле а выбор из автомолита с чекбоксами. Multiselect интерфейсы у тех ключей что этого требуют. Чекбоксы у булевых ключей, если их определят. Если кто-то захочет определить домен ключа и свой виджет ввода написать - пожалуйста.
повторяюсь: иерархическая схема (один главный тэг, “вложенные” под-тэги) мне представляется неудобной в качестве единственной.
так как может быть сильно условной и неудобной для использования.
пример с мото - показателен - пункт гос. техосмотра мотоциклов оказывается “внутри” тэга shop, а место зимнего хранения мотоциклов - вообще в размытом под-тэге services (прочее, типа).
для узкого/небольшого сервиса это не проблема (хотя и неудобно), а вот увязывать всё это на большом проекте уныло будет.
позволяет точно описать контору и легко запросить выборку контор, продающих зимнюю экипировку для квадроциклистов или производящих тех. осмотр мотоциклов, не пересекаясь с с ненужными конторами типа официальных продавцов новой мототехники.
также без проблем подобная схема позволит запросить все конторы, имеющие отношение к мото (или квадро)
