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

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

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

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

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

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

Те, кто парсил до этого, будут парсить после этого.
Те кто не хотят парсить ничего (>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=здесь точно банк

http://overpass-turbo.eu/s/7qH

ООООО. Регулярки. Давай, вперёд:


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

Запусти этот запрос для планеты.

Теперь я жду от тебя:

  1. временные оценки
  2. затраты памяти твоего “решения” shop~mobile_phone
  3. **затраты CPU на вычисления твоей регулярки для многомиллионных ключей базы **

Да мало ли кто чего хочет, ты хочешь ты и придумывай как фильтровать такие объекты, хочешь - регулярки пиши, да хоть AI. С чего вдруг кто-то твои проблемы будет решать, да к томуже сформулированные в столь претенциозной манере.

Можешь посмотреть в онтологии что значит претенциозность.

На регулярках - это у тебя какая-то странная фиксация, мне они для поиска по одному из значений разделенных ‘;’ в моих проектах не нужны.

Уменя, на поиск:
Затраты памяти - константа.
Время выполнения log(n)

Ну-ну, теоретизировать ты горазд. Запусти хотя-бы одну регулярку для shop=* для всей планеты. До этого - нет разговоров с тобой.

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

Прости, я не умею писать регулярки для

sport=billiards;pyramid:12ft;pyramid:10ft;snooker:9ft;snooker:12ft

У тебя видимо дар особый, и можешь написать регулярку которая найдёт снукер, а я нет, убогий, мне нужны решения какихт-то проблем.

Найти “любой снукер”. Действительно проблема для тебя. Тебе нужен целый AI для этого (ты их когда-нибудь писал или просто словом кинуть решил?).

Может раз так, то закрыть тему? Раз задача поиска консенсуса больше не стоит?

Тот текст, который был, имел, на мой взгляд, здравую основу – не лепить множественные значения в основные теги, т.е. туда, где множественность вовсе не предполагается. Потому что классификация задумывалась как однозначная.

Это могло бы найти понимание в сообществе.

Теперь же, как я понимаю, предлагается сделать глобальную(т.е. по всей планете) замену схем тегирования с xxx=yyy на xxx:yyy=yes с поддержкой множественности.
Это совсем другая тема.

По моему в условиях лицензии OSM прямо указано, что сервер предоставляет открытые данные, но не сервис обработки запросов планетарного масштаба. В overpass API тоже есть нечто схожее. Поэтому если кто-то парсит сложные value по всей планете - он делает это при импорте в свою собственную базу. Например Mapsurfer.NET и любой другой рендер.

Ближе к концу недели освежу мозг, постараюсь с новыми идеями дописать предложение и кинуть в tagging. Нет, текст я спрятал потому что пол текста могут неправильно впечатление ввести. У схемы есть преимущества, даже если данные не будут использоваться прямо сегодня.

Да, об этом в том числе и речь, это применимо для:
shop=*
amenity=*
других poi тегов

  1. замену - нет
  2. временное решение в рамках сломанной парадигмы <строка>=<строка> - да.

Т.е. затегируем так 0,1%-0,2% объектов, а если понравится (уже нравится) и инструменты будут (JOSM, конвертеры) да еще API обновится, то тогда уже будем говорить о новых структурах более умных чем <строка>=<строка>

Я с этим не согласен. Я не один в этом. “ключ только один” некоторых не устраивает совсем.

Это простые запреты использования, а не фундаментальная проблема “такую регулярку в принципе не написать” или “такая регулярка не остановится”.

Даже если так, то что?

Я бы поднял osmd1g.ru для которого нет этих запретов. Если dkiselev умеет писать регулярки за

то его словам я просто не верю без рабочего решения (примера, демонстрации). Рассчитать время работы и индексов БД еще более-худно можно. Рассчитать время выполнения даже конкретной регулярки для всех ключей в базе… Не говоря уже о постоянно меняющихся запросах пользователей. Я не знаю как так делать.

У вас много программистов пишущих и отлаживающих программы на регулярных выражениях?