Я же приду отмечу сотню и тысячи сложных тегов меню:
#ресторан
Неплохо готовит
#меню-ресторана
меню-ресторана:первое=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 рублей
]
У вас голова поедет сложности вложенности тегов если лично вам это не интересно. Пенсионерам очень важно знать где у них будут скидки, они будут мапить:
рестораны вам
скидки себе
Это уже потом статистики и разработчики программ могут выбрать что
Так а что поменяется, если рендер встретит объект с тегами shop:clothes=yes + shop:shoes=yes ? Поймите, сейчас рендеры не рисуют такие случаи не потому, что им не распарсить значения через “;”, а просто потому, что хрен знает, каким это значком нарисовать. Изменение схемы тегирования ничего не изменит в этом смысле.
Вы в пропозале привели статистику, что количество ; не велико, значит не так уж и важно как именно от них избавится, хотя бы и разной геометрией.
То есть вся деятельность по ломке старых понятий и придумыванию новых не стоит и выеденного гроша , только порождает болтовню во имя каких-то “чмстых знаний”
Только в двух тегах здесь тоже неоднозначность, потому 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 тегов). Лучше принять адекватную и непротиворечивую схему и тегировть ей двойственные объекты когда встречаются, а не выдумывать несколько геометрий.
Нужно возвращаться к простым тегам вроде atm=yes. Сделать это без коллизий в смыслах можно только тегируя смысловой префикс (sport:), либо бессмысленный исторический префикс для обратной совместимости (amenity:).
Такое может сказать только человек не видящий разницы между
2 + 2
и
“2” + “2”
между
“значние;зачение”
и
{значение; значение}
Будете мне регулярки предлагать чтобы их распарсить? История информатики и первый семестр структур данных прошел мимо вас, я понял.
d1g, следующее ваше предположение по отношению к окружающим, об уровне образования, уровне владения регулярными выражениями и необходимости их использования, обернется баном. dkiselev
Я так стар, что я историю если и не творил, то наблюдал и участвовал, а не изучал на первом курсе.
Ваши картинки различаются разделителями.
Новая схема может быть сколь угодно правильной и замечательной, но если он неоправданно сложнее, чем старая и ее нельзя объяснить пользователям, то она бесполезна.
Главный вопрос: Какие задачи можно решить, которые нельзя решить на старой схеме?
Указать несколько значений у смыслового ключа чтобы не нужно было парсить ключ или значение абсолютно всем пользователям, а не только тем которым нужны конкретные значения.
Те, кто парсил до этого, будут парсить после этого.
Те кто не хотят парсить ничего (>80% пользователей! сюрприз!), получают возможность используя <простые смысловые ключи>=yes либо <простые смысловые ключи>=<одно конкретное значение> делать запросы к БД без перебегания к парсингу чего-либо или регулярных выражений.
Вы же упёрлись на первом пункте и считаете что преимуществ для других не существует вообще.
После того как введём вложенные массивы и множества не нужно парсить ничего не будет никому. Перевод смысла в ключ упростит задачу перехода. Раз вы такой старый, преимущества сериализации-десериализации вместо ручного парсинга ключей и значений каждым разработчиком каждый новый раз объяснять вам не буду.
Опять уходите от ответа.
Как от этого поменяется функциональность программ? Что нового увидит их пользователь?
Мы таки наконец обретем поддержку целостности границ?
Или просто получим в чем-то более стройный код, на что пользователю глубоко наплевать. Скорее наоборот, если он теги пишет ручками в JOSM /Potlach 1, то ему только хуже.
То, что вы не понимаете преимущества сериализации и отсутствие этапа парсинга для пользователей это не уход от ответа. Это ваша упёртость на обязательности парсинга для всех. Вам ответили в 50 раз, вы опять сводите всё к парсингу своему.
Опять скажу- достоинств схемы может быть далеко не достаточно, если эти достоинства ничего не дают нового. Так что сторонники могут как угодно нахваливать схему, но ничего не говорить о достоинствах ее введения взамен имеющейся.
Если я не могу ничего от введения этой схему добавить в конечный продукт, то зачел ломать уже работающее?
, только порождает болтовню во имя каких-то “чмстых знаний”