Опять уходите от ответа.
Как от этого поменяется функциональность программ? Что нового увидит их пользователь?
Мы таки наконец обретем поддержку целостности границ?
Или просто получим в чем-то более стройный код, на что пользователю глубоко наплевать. Скорее наоборот, если он теги пишет ручками в 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, без разбора что это за тег) – это глобальная смена парадигмы, которая потребует переделки всех приложений.
тут нюанс. софт-то люди пишут. и чем ниже порог вхождения для его написания (квалификация, трудозатраты), тем больше можно ожидать проектов, использующих базу OSM (а зачем она нужна, без использования).
дальше вполне реальный пример с вопросом (отмечу, что не утверждаю, именно спрашиваю)
итак, снова про бильярд:
допустим, есть желание сделать сайт поиска бильярдных.
чтобы юзер мог выбрать:
тип бильярда (пирамида, пул, снукер, карамболь);
размеры столов;
изолированность столов (общий зал либо отдельные комнаты для каждого стола);
наличие/отсутствие бара;
меню бара (пиво, сок, чай, минералка);
время работы всего этого с нюансами (например ночью бар может и не работать);
пример не с потолка. когда я активно посещал бильярдные , мне всё это действительно интересно
вопрос в следующем - насколько при текущем АПИ всё это реально/сложно/долго делать?
теперь представим, что сайт не про бильярд, а про спортивные/игровые/развлекательные заведения вообще (опций, соответственно, прибавится). повторим вопрос.