Нам нужны вообще ; в значениях для России? Запретим их?

dkiselev · 2015-02-02T17:44:28.000Z

romul_zurov, так сложилось что в нашем сознании shop это только магазин и ничто иное. У англичан, это несколько более широкое понятие.

d1g · 2015-02-02T17:50:01.000Z

dkiselev:

Твоя схема, в плане организованности маперов не меняет ровным счетом ничего.

Меняет, еще как. Я явно говорю что от тегов-матрёшек лучше избавляться, мапить столько тегов, сколько смыслов. Ещё как руководство даёт.

dkiselev:

В строке “[1,2,3,4,5]” закодировано 1 или несколько значений?

Я тебе говорю это массив и элементы массива. Хватит с этими строка=строка носится.

String[] myStringArray = {“a”,“b”,“c”};

Барабанная дробь, вопрос дня:

dkiselev:

В строке “a;b;c” закодировано 1 или несколько значений?

Надеюсь с этого раза ты поймешь почему это “хоть чем-то” отличается от “a; b; c”.

PS. dair меня правильно понял.

И я кажется предупреждал на счет предположений, о том кто что умеет и не умеет.

dair · 2015-02-02T17:50:03.000Z

dkiselev:

Я по-прежнему, не могу понять, почему ref=3;4 надо парсить, а ref=[3; 4] не надо?

В строке “[1,2,3,4,5]” закодировано 1 или несколько значений? А в строке “1;2;3;4;5”?

Насколько я понял, в предлагаемом API возвращаемое значение будет строго типизированным, т.е. в одном случае это действительно строка, а в другом — массив, который, в свою очередь, будет возвращаться то ли в виде XML-деревца, то ли в виде JSON, то ли еще как-то, но не как строка, соответственно можно запрашивать его элементы отдельно поштучно. А “[3;4]” — это просто условная запись, в реальности в таком виде оно возвращаться не предполагается.

dkiselev · 2015-02-02T17:53:30.000Z

А вот эти художесва тоже планируется на уровне АПИ поддерживать?

[pool:(7ft, 8ft), snooker:(9ft, 12ft)]

dair · 2015-02-02T17:57:43.000Z

Вот только и коммиты в этом случае должны валидироваться на соответствие типов. Соответственно, сервер должен иметь список возможных тегов с допустимыми типами для них. Иначе я плохо представляю, как программа-обработчик должна интерпретировать деревце совершенно произвольного вида с произвольными типами данных, полученное как результат какого-то запроса.

wowik · 2015-02-02T17:59:07.000Z

dair:

то ли в виде XML-деревца, то ли в виде JSON

Pardonne-moi! А их парсить разве не надо?

dkiselev · 2015-02-02T17:59:48.000Z

Я так понимаю, d1g рассчитывает что все они описаны в вики. А если не описаны то не нужны.

dair · 2015-02-02T18:00:02.000Z

dkiselev:

А вот эти художесва тоже планируется на уровне АПИ поддерживать?
[pool:(7ft, 8ft), snooker:(9ft, 12ft)]

Как я понимаю, да. Это тоже условная запись, на самом деле опять возвращается дерево неизвестного вида.

dair · 2015-02-02T18:02:44.000Z

wowik:

dair:

то ли в виде XML-деревца, то ли в виде JSON

Pardonne-moi! А их парсить разве не надо?

Ну это вроде еще не доработано, а сейчас предполагается, что тот, кто делает запросы, знает как именно выглядит это деревце и делает запросы сразу к его листьям, а не на несколько уровней выше.

d1g · 2015-02-02T18:03:15.000Z

dkiselev:

А вот эти художесва тоже планируется на уровне АПИ поддерживать?
[pool:(7ft, 8ft), snooker:(9ft, 12ft)]

Это написал romul_zurov для наглядности я думаю. В целом - достаточно будет ассоциативного массива с вложенностью, ничего хитрого.

что-то:там:схорошаясхема:pool=[7ft, 8ft]
что-то:там:схорошаясхема:snooker=[9ft, 12ft]

Если захотят - будут вводить структуры set, multiset. Для отдельных ключей. Будут специализировать домены (ключи в OSM) если захотят. Абсолютно опционально. Всё как у больших дядь.

dkiselev · 2015-02-02T18:04:08.000Z

Не, ну что я могу посоветовать, пишите письма в @tagging, @osm-dev, и шлите pull-request’ы.
Но что-то мне подсказывает что эта схема не взлетит.

d1g · 2015-02-02T18:07:55.000Z

dkiselev:

Я так понимаю, d1g рассчитывает что все они описаны в вики. А если не описаны то не нужны.

Что ты носишься с вики когда всё понятно из ключей тем кто хочет использовать данные?

“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 = у шаблона ключа. Без “роли”, смысла, простой ссылкой. Смысл и роль могут определить дотошные авторы самих ключей. Представь себе, их достаточно и они это делают.

dkiselev · 2015-02-02T18:18:35.000Z

Ну сейчас это отличается от того что я тебе писал только тем, что планируется, что апи умеет возвращать коллекции значений.

Но извини меня, парсер для коллекции кодированой в xml (ведь апи у нас по-прежнему возвращает xml) ничуть не проще чем парсер для значений разделенных ‘;’

wowik · 2015-02-02T18:20:24.000Z

dkiselev:

ничуть не проще чем парсер для значений разделенных ‘;’

И я о том же

d1g · 2015-02-02T18:22:21.000Z

wowik:

Pardonne-moi! А их парсить разве не надо?

Кто их будет видеть в сериализованном виде кроме базы данных и протокола?

Пользователю в JOSM будет не текстовое поле а выбор из автомолита с чекбоксами. Multiselect интерфейсы у тех ключей что этого требуют. Чекбоксы у булевых ключей, если их определят. Если кто-то захочет определить домен ключа и свой виджет ввода написать - пожалуйста.

romul_zurov · 2015-02-02T18:22:23.000Z

dkiselev:

romul_zurov, так сложилось что в нашем сознании shop это только магазин и ничто иное. У англичан, это несколько более широкое понятие.

понял, принято.

повторяюсь: иерархическая схема (один главный тэг, “вложенные” под-тэги) мне представляется неудобной в качестве единственной.
так как может быть сильно условной и неудобной для использования.
пример с мото - показателен - пункт гос. техосмотра мотоциклов оказывается “внутри” тэга shop, а место зимнего хранения мотоциклов - вообще в размытом под-тэге services (прочее, типа).
для узкого/небольшого сервиса это не проблема (хотя и неудобно), а вот увязывать всё это на большом проекте уныло будет.

в то время как (примерная) схема:


motorcycles:winter_store
motorcycles:safety_inspection
motorcycles:equip
motorcycles:repair:japan
atv:tunning
equip:atv:winter

позволяет точно описать контору и легко запросить выборку контор, продающих зимнюю экипировку для квадроциклистов или производящих тех. осмотр мотоциклов, не пересекаясь с с ненужными конторами типа официальных продавцов новой мототехники.
также без проблем подобная схема позволит запросить все конторы, имеющие отношение к мото (или квадро)

d1g · 2015-02-02T18:30:06.000Z

romul_zurov:

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, то это можно определить на вики у основного ключа группы или если очень хочется то и у каждого тега-значения.

edward17 · 2015-02-02T18:33:06.000Z

romul_zurov:

также без проблем подобная схема позволит запросить все конторы, имеющие отношение к мото (или квадро)

С помощью регулярных выражений, ага.

d1g · 2015-02-02T18:38:17.000Z

edward17:

С помощью регулярных выражений, ага.

Всегда пожалуйста. спроси у этого “множества” на отсутствующее значение 13:

addr:flats=21-40

Только не говори что “13 может быть в OSM не указано”. В этом доме все квартиры указаны.

d1g · 2015-02-02T18:43:17.000Z

dkiselev:

Но извини меня, парсер для коллекции кодированой в xml (ведь апи у нас по-прежнему возвращает xml) ничуть не проще чем парсер для значений разделенных ';’

И поэтому мы должны мешать эти два подхода прямо сейчас в рамках API 0.6

Мы же такие адекватные,
Мы же используем XML для ответов,
Мы же еще к тому же кодируем значения через ;

Что? Серьезно, тебя это никогда не смущало?

Кроме того, мы так любим потребителей данных что не скажем какие именно ключи у нас многозначные, им придётся абсолютно всю БД парсить. Потому что ; можно поставить везде - легко же.