romul_zurov, так сложилось что в нашем сознании shop это только магазин и ничто иное. У англичан, это несколько более широкое понятие.
Меняет, еще как. Я явно говорю что от тегов-матрёшек лучше избавляться, мапить столько тегов, сколько смыслов. Ещё как руководство даёт.
Я тебе говорю это массив и элементы массива. Хватит с этими строка=строка носится.
Барабанная дробь, вопрос дня:
Надеюсь с этого раза ты поймешь почему это “хоть чем-то” отличается от “a; b; c”.
PS. dair меня правильно понял.
И я кажется предупреждал на счет предположений, о том кто что умеет и не умеет.
Насколько я понял, в предлагаемом API возвращаемое значение будет строго типизированным, т.е. в одном случае это действительно строка, а в другом — массив, который, в свою очередь, будет возвращаться то ли в виде XML-деревца, то ли в виде JSON, то ли еще как-то, но не как строка, соответственно можно запрашивать его элементы отдельно поштучно. А “[3;4]” — это просто условная запись, в реальности в таком виде оно возвращаться не предполагается.
А вот эти художесва тоже планируется на уровне АПИ поддерживать?
[pool:(7ft, 8ft), snooker:(9ft, 12ft)]
Вот только и коммиты в этом случае должны валидироваться на соответствие типов. Соответственно, сервер должен иметь список возможных тегов с допустимыми типами для них. Иначе я плохо представляю, как программа-обработчик должна интерпретировать деревце совершенно произвольного вида с произвольными типами данных, полученное как результат какого-то запроса.
Pardonne-moi! А их парсить разве не надо?
Я так понимаю, d1g рассчитывает что все они описаны в вики. А если не описаны то не нужны.
Как я понимаю, да. Это тоже условная запись, на самом деле опять возвращается дерево неизвестного вида.
Ну это вроде еще не доработано, а сейчас предполагается, что тот, кто делает запросы, знает как именно выглядит это деревце и делает запросы сразу к его листьям, а не на несколько уровней выше.
Это написал romul_zurov для наглядности я думаю. В целом - достаточно будет ассоциативного массива с вложенностью, ничего хитрого.
Если захотят - будут вводить структуры set, multiset. Для отдельных ключей. Будут специализировать домены (ключи в OSM) если захотят. Абсолютно опционально. Всё как у больших дядь.
Не, ну что я могу посоветовать, пишите письма в @tagging, @osm-dev, и шлите pull-request’ы.
Но что-то мне подсказывает что эта схема не взлетит.
Что ты носишься с вики когда всё понятно из ключей тем кто хочет использовать данные?
“sport”=yes
“sport:billiard”=yes
“sport:billiard:type”=[snooker, pool]
“sport:billiard:tablesize:snooker”=[6ft, 8ft]
“sport:billiard:tablesize:pool”=[5ft, 7ft]
Те кто захотят связи определять связь в вики, определять формально в XSD между ключами
sport:billiard:type
и
sport:billiard:tablesize:snooker
sport:billiard:tablesize:pool
Пожалуйста - нет, не обязательно. Обрабатывать такие данные может быть проблемнее. “неочевидные теги в OSM” растут только отсюда.
UPD. Связь в вики просто указывается как | combination = у шаблона ключа. Без “роли”, смысла, простой ссылкой. Смысл и роль могут определить дотошные авторы самих ключей. Представь себе, их достаточно и они это делают.
Ну сейчас это отличается от того что я тебе писал только тем, что планируется, что апи умеет возвращать коллекции значений.
Но извини меня, парсер для коллекции кодированой в xml (ведь апи у нас по-прежнему возвращает xml) ничуть не проще чем парсер для значений разделенных ‘;’
Кто их будет видеть в сериализованном виде кроме базы данных и протокола?
Пользователю в JOSM будет не текстовое поле а выбор из автомолита с чекбоксами. Multiselect интерфейсы у тех ключей что этого требуют. Чекбоксы у булевых ключей, если их определят. Если кто-то захочет определить домен ключа и свой виджет ввода написать - пожалуйста.
понял, принято.
повторяюсь: иерархическая схема (один главный тэг, “вложенные” под-тэги) мне представляется неудобной в качестве единственной.
так как может быть сильно условной и неудобной для использования.
пример с мото - показателен - пункт гос. техосмотра мотоциклов оказывается “внутри” тэга shop, а место зимнего хранения мотоциклов - вообще в размытом под-тэге services (прочее, типа).
для узкого/небольшого сервиса это не проблема (хотя и неудобно), а вот увязывать всё это на большом проекте уныло будет.
в то время как (примерная) схема:
motorcycles:winter_store
motorcycles:safety_inspection
motorcycles:equip
motorcycles:repair:japan
atv:tunning
equip:atv:winter
позволяет точно описать контору и легко запросить выборку контор, продающих зимнюю экипировку для квадроциклистов или производящих тех. осмотр мотоциклов, не пересекаясь с с ненужными конторами типа официальных продавцов новой мототехники.
также без проблем подобная схема позволит запросить все конторы, имеющие отношение к мото (или квадро)
В моём понимании это нужно будет вернуть как:
{
motorcycles:
{
winter_store,
safety_inspection,
equip,
repair: [japan]
}
atv: [tunning]
equip:atv: [winter]
}
Причем от разной вложенности друг-в-друга можно менять смысл их обработки.
Код-обработчик и запрос-выборка усложнится (в иерархичном варианте), но от этого никуда не деться. Если кто-то очень хочет или не любит теги motorcycles=yes, atv=yes, то это можно определить на вики у основного ключа группы или если очень хочется то и у каждого тега-значения.
С помощью регулярных выражений, ага.
Всегда пожалуйста. спроси у этого “множества” на отсутствующее значение 13:
addr:flats=21-40
Только не говори что “13 может быть в OSM не указано”. В этом доме все квартиры указаны.
И поэтому мы должны мешать эти два подхода прямо сейчас в рамках API 0.6
Мы же такие адекватные,
Мы же используем XML для ответов,
Мы же еще к тому же кодируем значения через ;
Что? Серьезно, тебя это никогда не смущало?
Кроме того, мы так любим потребителей данных что не скажем какие именно ключи у нас многозначные, им придётся абсолютно всю БД парсить. Потому что ; можно поставить везде - легко же.