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

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

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

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

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

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

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

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

Те, кто парсил до этого, будут парсить после этого.
Те кто не хотят парсить ничего (>80% пользователей! сюрприз!), получают возможность используя <простые смысловые ключи>=yes либо <простые смысловые ключи>=<одно конкретное значение> делать запросы к БД без перебегания к парсингу чего-либо или регулярных выражений.

Вы же упёрлись на первом пункте и считаете что преимуществ для других не существует вообще.

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

Парсить не пользователи должны, а софт. Вы же предлагаете ради такой мелочи, сюрприз!, изменить структуру хранения, апи, схемы, софт, привычки…

Парсинга значений заменяем на парсинг ключей.

Опять уходите от ответа.
Как от этого поменяется функциональность программ? Что нового увидит их пользователь?

Мы таки наконец обретем поддержку целостности границ?

Или просто получим в чем-то более стройный код, на что пользователю глубоко наплевать. Скорее наоборот, если он теги пишет ручками в JOSM /Potlach 1, то ему только хуже.

И ЧТО?

И конечно же у меня есть единомышленники в этом.

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

“Преимущества для пользователей”

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

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