А зачем?
То есть вся деятельность по ломке старых понятий и придумыванию новых не стоит и выеденного гроша 
, только порождает болтовню во имя каких-то “чмстых знаний”
Только в двух тегах здесь тоже неоднозначность, потому 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 раз, вы опять сводите всё к парсингу своему.
Опять скажу- достоинств схемы может быть далеко не достаточно, если эти достоинства ничего не дают нового. Так что сторонники могут как угодно нахваливать схему, но ничего не говорить о достоинствах ее введения взамен имеющейся.
Если я не могу ничего от введения этой схему добавить в конечный продукт, то зачел ломать уже работающее?
Добрый день! Начнём всё сначала в 20 раз.
Покажите мне работающие программы для
name=Банкомат
amenity=atm;bank
description=здесь точно банк
а не для
amenity=yes
amenity:atm=yes
amenity:atm:name=Банкомат
amenity:bank=yes
amenity:bank:description=здесь точно банк
ООООО. Регулярки. Давай, вперёд:
sport=billiards;pyramid:12ft;pyramid:10ft;snooker:9ft;snooker:12ft
Хочу бильярды снукер 9 футовый.
Особо не усердствуй с регуляркой, я её сломаю “любой снукер”
“sport:billiards:snooker”=yes
В твоём языке “регулярных выражений” нет термина снукер. Ты будешь всю жизнь писать мне действительно работающий ответ.
Так, вопрос был дай мне объект по второму значению из списка. Ответ дан? Дан.
То, что твое единственноправильное представление о мире и осм, не находит живого отклика в сердцах публики - абсолютно не мои проблемы.
Здравствуйте.
Опять уход в сторону.
Какую новую не решаемую в текущем ОСМ задачу обработки и хранения данных вы сможете решить новой схемой?
Не не только моё. И не единственное.
То,что ты думаешь *в sport= можно вместить всё насвете - только твоя особая картина мира. С ней не согласны.
Это только твоё мнение. Пропагандист тоже мне.
Ты в курсе вообще об алгоритмической сложности?
http://overpass-turbo.eu/?w=%22shop%22~%22mobile_phone%22%20global
Запусти этот запрос для планеты.
Теперь я жду от тебя:
Да мало ли кто чего хочет, ты хочешь ты и придумывай как фильтровать такие объекты, хочешь - регулярки пиши, да хоть AI. С чего вдруг кто-то твои проблемы будет решать, да к томуже сформулированные в столь претенциозной манере.
Можешь посмотреть в онтологии что значит претенциозность.
На регулярках - это у тебя какая-то странная фиксация, мне они для поиска по одному из значений разделенных ‘;’ в моих проектах не нужны.
Уменя, на поиск:
Затраты памяти - константа.
Время выполнения log(n)