Указать несколько значений у смыслового ключа чтобы не нужно было парсить ключ или значение абсолютно всем пользователям, а не только тем которым нужны конкретные значения.
Те, кто парсил до этого, будут парсить после этого.
Те кто не хотят парсить ничего (>80% пользователей! сюрприз!), получают возможность используя <простые смысловые ключи>=yes либо <простые смысловые ключи>=<одно конкретное значение> делать запросы к БД без перебегания к парсингу чего-либо или регулярных выражений.
Вы же упёрлись на первом пункте и считаете что преимуществ для других не существует вообще.
После того как введём вложенные массивы и множества не нужно парсить ничего не будет никому. Перевод смысла в ключ упростит задачу перехода. Раз вы такой старый, преимущества сериализации-десериализации вместо ручного парсинга ключей и значений каждым разработчиком каждый новый раз объяснять вам не буду.
Опять уходите от ответа.
Как от этого поменяется функциональность программ? Что нового увидит их пользователь?
Мы таки наконец обретем поддержку целостности границ?
Или просто получим в чем-то более стройный код, на что пользователю глубоко наплевать. Скорее наоборот, если он теги пишет ручками в JOSM /Potlach 1, то ему только хуже.
То, что вы не понимаете преимущества сериализации и отсутствие этапа парсинга для пользователей это не уход от ответа. Это ваша упёртость на обязательности парсинга для всех. Вам ответили в 50 раз, вы опять сводите всё к парсингу своему.
Опять скажу- достоинств схемы может быть далеко не достаточно, если эти достоинства ничего не дают нового. Так что сторонники могут как угодно нахваливать схему, но ничего не говорить о достоинствах ее введения взамен имеющейся.
Если я не могу ничего от введения этой схему добавить в конечный продукт, то зачел ломать уже работающее?
Да мало ли кто чего хочет, ты хочешь ты и придумывай как фильтровать такие объекты, хочешь - регулярки пиши, да хоть AI. С чего вдруг кто-то твои проблемы будет решать, да к томуже сформулированные в столь претенциозной манере.
Можешь посмотреть в онтологии что значит претенциозность.
Может раз так, то закрыть тему? Раз задача поиска консенсуса больше не стоит?
Тот текст, который был, имел, на мой взгляд, здравую основу – не лепить множественные значения в основные теги, т.е. туда, где множественность вовсе не предполагается. Потому что классификация задумывалась как однозначная.
Это могло бы найти понимание в сообществе.
Теперь же, как я понимаю, предлагается сделать глобальную(т.е. по всей планете) замену схем тегирования с xxx=yyy на xxx:yyy=yes с поддержкой множественности.
Это совсем другая тема.
По моему в условиях лицензии OSM прямо указано, что сервер предоставляет открытые данные, но не сервис обработки запросов планетарного масштаба. В overpass API тоже есть нечто схожее. Поэтому если кто-то парсит сложные value по всей планете - он делает это при импорте в свою собственную базу. Например Mapsurfer.NET и любой другой рендер.
Ближе к концу недели освежу мозг, постараюсь с новыми идеями дописать предложение и кинуть в tagging. Нет, текст я спрятал потому что пол текста могут неправильно впечатление ввести. У схемы есть преимущества, даже если данные не будут использоваться прямо сегодня.
Да, об этом в том числе и речь, это применимо для:
shop=*
amenity=*
других poi тегов
Т.е. затегируем так 0,1%-0,2% объектов, а если понравится (уже нравится) и инструменты будут (JOSM, конвертеры) да еще API обновится, то тогда уже будем говорить о новых структурах более умных чем <строка>=<строка>
Это простые запреты использования, а не фундаментальная проблема “такую регулярку в принципе не написать” или “такая регулярка не остановится”.
Даже если так, то что?
Я бы поднял osmd1g.ru для которого нет этих запретов. Если dkiselev умеет писать регулярки за
то его словам я просто не верю без рабочего решения (примера, демонстрации). Рассчитать время работы и индексов БД еще более-худно можно. Рассчитать время выполнения даже конкретной регулярки для всех ключей в базе… Не говоря уже о постоянно меняющихся запросах пользователей. Я не знаю как так делать.
У вас много программистов пишущих и отлаживающих программы на регулярных выражениях?
Я говорю о том, что есть две категории тегов, условно “основные” и “уточняющие”. Для основных тегов нужно выбрать ОДНО значение, которое описывает данный объект в наилучшей степени. Дорога не может быть одновременно “первичной” и жилой улицей, река не может быть одновременно ручьем, больница одновременно не может быть концертным залом, и. т.д.
В уточняющих тегах возможны списки. У дороги может быть несколько номеров (ref), у адвокатской конторы несколько телефонов, у ресторана несколько кухонь.
Это идейная основа существующей схемы. Разрешение множественности вообще везде (например поддержка этого в API, без разбора что это за тег) – это глобальная смена парадигмы, которая потребует переделки всех приложений.