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

Насколько я помню API не позволяет такое:
shop=clothes
shop:secondary=toys
shop:secondary=kids
shop:secondary=electronics

В противном случае если бы API позволял мы бы пользовались таким:
shop=clothes
shop=toys
shop=kids

А не пытались нагородить всё в value у бедных key.

Ни один вариант с несколькими значениями в value не подойдёт.

У вас прямо сейчас ни один рендер не сможет показать иконку кроссовок для shop=clothes;shoes, даже если он для shop=shoes умеет это делать.

в целом согласен с d1g.
текущая схема для обозначения, например, бильярда позволяет сделать так:
sport=billiards
sport=pool
sport=snooker
sport=snooker;pool
и всё это нужно учитывать при создании гипотетической карты бильярдных.
через пол-года энтузиаст русской пирамиды навтыкает sport=pyramid (а чем это хуже sport=snooker, к примеру) - и на карте их не появится.
при схеме:
sport:billiards=yes
sport:billiards:pool=yes
sport:billiards:snooker=yes
добавление sport:billiards:pyramid=yes появится автоматически как “бильярд вообще”, после добавления тэга/значка в рендер карты - как именно пирамида.
плюс без проблем можно добавлять размер столов, например:
sport:billiards:pyramid:12ft=yes
sport:billiards:pyramid:10ft=yes
или возможность фотографироваться барышням на столе :smiley: :
sport:billiards:pool:photo_on_table:female=yes
засовывать всё это в sport=billiards через точку запятой, имхо, неправильно :roll_eyes:

Я что-то пропустил или вы уже оформили свои предложения на вики, обсудили плюсы и минусы с сообществом в одном месте (а не N постов в рассылке, пара страниц на региональном форуме и пара дюжин в личных сообщениях), после чего провели голосование и успешно приняли схему? Неудивительно, что на ваше “мне так видится” следует закономерная реакция.

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

Изменения API безусловно продвигать нужно, только мы сейчас обсуждаем изменения в схемах.

А вот это называется ставить телегу вперёд лошади. Попытка принять схему на основании “использования де факто”, вместо “скучного” процесса написания/обсуждения/принятия пропозала, это тоже пример “плохой практики”. Надеюсь, раскрывать почему это так нет необходимости.

Я считаю, что не только пока что, но и в последующем не стоит. Ибо ради 1% заставлять остальные 99% использовать усложнённую схему не есть правильно. Кроме того, подход описанный мной, позволит убрать значительную долю критики (справедливой, стоит заметить) связанный с использованием shop:* тегов без материнского shop=*, при этом не потеряв ничего в гибкости, и даже добавив немного в лаконичности.

А вот это уже откровенно попахивает NIH синдромом. На кой чёрт заводить ботов и принуждать пользователей использовать усложнённую схему, когда для 99% случаев достаточно примитивных shop=*, которые отлично работают чуть ли не с момента основания проекта?

Это еще что. Есть особо одарённые личности считающие что править вики не нужно кроме пяти-десяти страниц самих авторов, а то и вовсе обновлять их не нужно.

Никто не пытается сделать плохой традиции, просто проползал нужно составлять на английском языке. Это кроме описания тега на странице тега. Конечно же это никогда не произойдёт если находятся умники вещающие в ключе “кто правит вики - тот идиот”.

Да, я тут подумал еще раз. Временно писать бота чтобы он внёс двойную схему точно не стоит для 99,9% объектов. Это очень много работы мне, лучше выбросить API 0.6 и импортировать данные потом полу-вручную чем две схемы одновременно видеть в OSM.

Ограничение на <одинсмысловойключ>=<однозначение> настолько идиотское что даже слов нет. В XML нет таких жёстких ограничений:

Иванов авто Ford Mustang Т.е. в OSM API 0.6 такое написать не получится даже с использованием говорливых неймспейсов (предлагаемой схемы): shop:cardealer:cars:car=Ford shop:cardealer:cars:car=Mustang

В рамках API 0.6 придётся выдумывать костыли addrN, carN:
shop:cardealer:cars:car=Ford
shop:cardealer:cars:car2=Mustang

Статистика верна, но она вас вводит в заблуждение. Почитайте про костыли “одна точка - на один смысловой тег”.

Высказывание про “сразу пропустить этап XML” я теперь понимаю более-менее:

Чтобы такую простую схему в OSM ввести нужно кому-то гвоздь в лоб забить обязательно.

Обязательно находятся умники считающие 255 символов в value достаточно.
Обязательно находятся умники считающие 255 символов в key достаточно.
Обязательно находятся умники считающие только один раз встречающегося key достаточно.

Описание схемы я пока спрячу, нужно будет больше описать из чего всё происходит, почему это реально надо. Какие альтернативы есть (XML, текст с разметкой) и как сложно будет на них переходить с парадигмы 0.6 (набор key=value, с key значением которое встретится только один раз).

Вам еще не надоело? Добавьте ссылку на голосовалку в первый пост (ибо искать в тексте ее то еще действо) и успокойтесь, хотя бы до результатов голосования.

Именно из этого я и исходил когда предлагал передвинуть смысловую часть в key.

Никаких иероглифов в key не может появится если понять предлагаемые изменения, а не вспоминать о каких-то регулярках.

Новая схема не решает вопрос “сколько значений у этого ключа” из-за ограниченности API и парадигмы <строка>=<строка> в целом

Т.е. придётся парсить неймпейс sport:billiards:

Вместо этого можно было бы (с нормальным API 0.8):

sport:billiards это задокументированный на вики ключ
pool и snooker это значения на странице ключа sport:billiards:type в вики

Кто-то будет мапить только sport:billiards=yes, а любители бильярда будут смотреть страницу sport:billiards:type.

Да, это тоже было сделано намеренно чтобы упростить рендерам “бильярда в целом” и специального рендера бильярдных.

Не самое красивое решение, но это единственный вариант в рамках <строка>=<строка>.

симпатичный вариант.
а дальнейшее уточнение как предполагается делать? ну, к примеру, уже упомянутый размер столов?


    sport:billiards=yes
    sport:billiards:type = [pool, snooker]
    sport:billiards:table_size = [pool:7ft, pool:8ft, snooker:9ft, snooker:12ft]

либо


sport:billiards:table_size = [pool:(7ft, 8ft), snooker:(9ft, 12ft)]

или ещё как-то?

Ваш второй вариант это вложенные семантические коробки о которых я говорил.

Такой подход требует ответственности и документирования значений на вики, иначе вы никогда не узнаете что значат символы “7ft” “8ft”? Это длинна стола? Это длинна кия? (только не смейтесь, будут неочевидные схемы, например в промышленности и power=*).

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

Справедливости ради, ваше поведение в вики достаточно одиозно, отсюда и реакция. Масса людей спокойно правит вики не вызывая тонны флуда.

Теперь по теме: ещё раз, я всеми руками за развитие API, за более полное использование возможностей XML. (как частный случай эти самые пресловутые списки) Но не надо смешивать всё в кучу. Давайте в данной тематике всё-таки обсуждать эволюцию схемы shop (amenity и товарищи подтягиваются затем автоматом) в рамках имеющего недостатки, но существующего уже сегодня и успешно работающего API 0.6. Желаемые фичи же будущих версий API, лучше обсуждать на соответствующих страницах вики, либо в отдельно созданных темах форума.

Итак, если мы говорим об эволюции в рамках текущего API (а не о миграции на некую гипотетическую будущую версию), то мне абсолютна непонятна мотивация (если исключать упомянутый ранее NIH синдром) вашего желания полностью изничтожить тег shop=*. Как я уже сказал, на мой взгляд схема shop=cofee, shop:tea=yes по всем параметрам (в рамках API 0.6) лучше чем shop=yes, shop:cofee=main, shop:tea=yes и shop:cofee=main, shop:tea=yes.

Так что, повторю свою личную рекомендацию ещё раз: вместо разведения тонны бесполезных обсуждений, займитесь делом и оформите нормальный пропозал shop:* для API 0.6. После чего в отдельных документах оформляйте своё виденье следующих версий API, а так же миграцию существующих тегов на новые фичи. Но первое дело нужно делать первым, а не ставить телегу вперёд лошади.

За сим, до появления оформленного пропозала, продолжать дискуссию не вижу смысла.

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

Я бы за. Но:

  1. даже если мы доработаем противоречия мы не избавимся от необходимости парсинга key
  2. даже если мы доработаем чтобы не нужно было парсить ничего (это невозможно в парадигме <строка> = <строка>), то будут две схемы над которыми нужно будет ломать голову:

Лично я сдаюсь как можно согласовать новые структуры данных (вложенные массивы, упорядоченные массивы) и текущие ограничения 0.6:

  1. <тупая строка> = <тупая строка>
  2. <левая часть от равно, тупая строка> может повторятся только один раз

Пример со сломанным в рамках OSM, XML я приводил. Заниматься совместимостью XML с ограничениями 0.6 я не потяну. Т.е. это реально большая задача, чем написать просто API 0.7 и потерпеть-импортировать старые данные (большую часть автоматом, а часть ручками-ручками)

ОСМ - база пространственных данных. Иерархии не относящиеся к пространственным данным очевидным образом плохо поддерживаются в ОСМ. Скажем отметить ресторан на карте - удобно а вот прописать детальное меню уже получается сложнее, с юлюадми дня, скидками в течение дня и т.п. По большому счёту это всё какие-то объекты живущие вне ОСМ.

Вооот, вот! Продолжайте здесь об этом.

Вы потратите 2 минуты на отметку


#shop
#ресторан
Неплохо готовит

Я же приду отмечу сотню и тысячи сложных тегов меню:


#ресторан
Неплохо готовит
#меню-ресторана
меню-ресторана:первое=yes
меню-ресторана:алкогольные напитки=yes
меню-ресторана:мороженное=yes
#shop-pricing
shop-pricing:pricing-rules = [
discount=yes
opening_hours=10:00-14:00
fixed=[100 рублей]
condition=target person is-a ru:пенсионер
description=скидка пенсионерам с 10-14 на 100 рублей
]

У вас голова поедет сложности вложенности тегов если лично вам это не интересно. Пенсионерам очень важно знать где у них будут скидки, они будут мапить:

  1. рестораны вам
  2. скидки себе

Это уже потом статистики и разработчики программ могут выбрать что


#shop
#ларёк
ларёк:мороженное=yes


#ресторан
#меню-ресторана
меню-ресторана:мороженное=yes

меню-ресторана:мороженное=yes и ларёк:мороженное=yes значит для вас “мороженное” или нет.

Если всё сваливать в кучу как продают:мороженное=yes, то вас не пустят в ресторан, потому что он только для пенсионеров в определённые часы.

В этом случае будет

shop=clothes
shop:secondary=toys;kids;electronic

Так а что поменяется, если рендер встретит объект с тегами shop:clothes=yes + shop:shoes=yes ? Поймите, сейчас рендеры не рисуют такие случаи не потому, что им не распарсить значения через “;”, а просто потому, что хрен знает, каким это значком нарисовать. Изменение схемы тегирования ничего не изменит в этом смысле.

А зачем?

  1. Можно и разными.
  2. Вы в пропозале привели статистику, что количество ; не велико, значит не так уж и важно как именно от них избавится, хотя бы и разной геометрией.

То есть вся деятельность по ломке старых понятий и придумыванию новых не стоит и выеденного гроша :slight_smile: , только порождает болтовню во имя каких-то “чмстых знаний”

Только в двух тегах здесь тоже неоднозначность, потому main/partial и вводятся еще предлагается shop=yes указывать:
shop:clothes=yes + shop:shoes=main - будет иконка кроссовок в центре, иконка одежды сбоку маленькая

или

shop=yes — будет рисовать иконку этому тегу если не понятно как два тега ниже shop:= разобрать
shop:shoes=yes — … вот эти и какие у них иконки
shop:clothes=yes

Для этого и вводятся теги-пирамидой:

shop=yes
shop:shoes=yes
shop:clothes=yes

Никакой неоднозначности в тегах выше нет.

Рендер “магазинов” будет рендерить тег shop=yes.
Рендер “магазинов обуви” будет рендерить тег shop:shoes=yes.
Рендер “магазинов одежды” будет рендерить тег shop:clothes=yes.
Сложный и умный рендер будет искать магазины со значением =main, рисовать его в центре, а остальные - по бокам этой “main” иконки.

Изменит, причем сильно, прочитайте примеры про разные бильярды до этого.

А зачем?

Если магазин алкогольный торгует еще хлебом, я не хочу два shop= выдумывать. Владелец магазина один, вход один, продавщица одна, но вы с чего-то взяли что shop= там два.

Лучше, конечно, разной геометрией чем никак (наваливать через ; значения у poi тегов). Лучше принять адекватную и непротиворечивую схему и тегировть ей двойственные объекты когда встречаются, а не выдумывать несколько геометрий.

amenity=bank
atm=yes

Был сто лет до этого. Не нужно было нормальный тег atm=yes мапить с бессмысленным префиксом amenity=.

Нужно возвращаться к простым тегам вроде atm=yes. Сделать это без коллизий в смыслах можно только тегируя смысловой префикс (sport:), либо бессмысленный исторический префикс для обратной совместимости (amenity:).

Такое может сказать только человек не видящий разницы между

2 + 2
и
“2” + “2”

между
“значние;зачение”
и
{значение; значение}

Будете мне регулярки предлагать чтобы их распарсить? История информатики и первый семестр структур данных прошел мимо вас, я понял.

d1g, следующее ваше предположение по отношению к окружающим, об уровне образования, уровне владения регулярными выражениями и необходимости их использования, обернется баном. dkiselev

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

Я так стар, что я историю если и не творил, то наблюдал и участвовал, а не изучал на первом курсе.
Ваши картинки различаются разделителями.

Новая схема может быть сколь угодно правильной и замечательной, но если он неоправданно сложнее, чем старая и ее нельзя объяснить пользователям, то она бесполезна.

Главный вопрос: Какие задачи можно решить, которые нельзя решить на старой схеме?

Целостность релейшинов границ? Нет. А что?