Может раз так, то закрыть тему? Раз задача поиска консенсуса больше не стоит?
Тот текст, который был, имел, на мой взгляд, здравую основу – не лепить множественные значения в основные теги, т.е. туда, где множественность вовсе не предполагается. Потому что классификация задумывалась как однозначная.
Это могло бы найти понимание в сообществе.
Теперь же, как я понимаю, предлагается сделать глобальную(т.е. по всей планете) замену схем тегирования с 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 (а зачем она нужна, без использования).
дальше вполне реальный пример с вопросом (отмечу, что не утверждаю, именно спрашиваю)
итак, снова про бильярд:
допустим, есть желание сделать сайт поиска бильярдных.
чтобы юзер мог выбрать:
тип бильярда (пирамида, пул, снукер, карамболь);
размеры столов;
изолированность столов (общий зал либо отдельные комнаты для каждого стола);
наличие/отсутствие бара;
меню бара (пиво, сок, чай, минералка);
время работы всего этого с нюансами (например ночью бар может и не работать);
пример не с потолка. когда я активно посещал бильярдные , мне всё это действительно интересно
вопрос в следующем - насколько при текущем АПИ всё это реально/сложно/долго делать?
теперь представим, что сайт не про бильярд, а про спортивные/игровые/развлекательные заведения вообще (опций, соответственно, прибавится). повторим вопрос.
Уважай коллективный труд. Если тысячи мапперов считают нормальным писать building:, то нужно перекроить для них чуть-чуть БД. Обновить программы конвертеры и редакторы.
Ресурсы - такие же как и раньше, то тегу на смысл объекта мира. Индексов нужно будет больше чтобы это отрабатывало за миллисекунды для планеты. Битовые операции и блум фильтры никто не отменял. Если время не критично 10мегабайт нулей битсетов можно сжать в килобайт.
Это не моя невнимательность. Это ты путаешь регулярки с GIN или какими-то индексами/деревьями. Выражай свои мысли более подробно, иначе меня это очень раздражает.
Это твоя невнимательномть. То что оверпас сейчас использует регулярки, не значит что оны нужны для поиска по значению тега, из списка с разделителем. И не значит что я их использую. Ты просил решение проблемы - я тебе дал ссылку. Никто не говорит что это единственно возможный или самый эфективный способ решения проблемы.
В IEEE напиши конечно, почему мы одни должны вкушать прелести общения.
Тоесть в 100 слуяаях из 800 те кому нравится тегировать цвет крыш не проставили общий тег?
Как что тебе с того? Это же кошмар, ведь не указаны свойства зданевости, крышеобладания, крышецветаобладания.
Указано только свойство крышезданеконкретноцветности!
В общем я присоединяюсь к вопросу wowik’а: что позволит решить схема “строка”=yes чего не позволяет решить “строка”=“строка”
Я понял тебя, никем никогда не написанный код из регулярки попытаться сделать “крибле-крабле” и получить ответ от несуществующего алгоритма, которого прямо сейчас в overpass нет. Я тебе уже говорил что твоё “решение” нерабочее.
Инвертированный индекс на отдельных лексемах смысловых слов, который ты мне теперь пытаешься предложить как “своё решение” будет ломаться на отравленных кальянах.
Ни регулярки
Ни обратный индекс по неосмысленным лексемам
Не учитывают смысл ключ=значение.
Не учитывают смысл очень:осмысленная:схема=однозначение
Ты в числах 1597-1880 тоже считаешь нормальным искать по “80”? Будешь предлагать границу слов искать как еще одно “решение”? Вместо двух тегов в OSM?
в такой схеме мне видится проблема с основным тэгом. когда он очевиден - нет проблем.
но. опять таки из жизни:
есть контора, которая:
продаёт б/у мотоциклы:
торгует мотоэкипировкой;
предоставляет услуги ремонта мотоциклов;
предоставляет услуги зимнего хранения мотоциклов;
всё это в одном месте, одна контора;
выделить что-либо главное - как?
shop = мотоциклы ?
shop = мотоэкипировка ?
service = ремонт японских мотоциклов (ремонтировать bmw они могут и не взяться) ?
service = зимнее хранение мотоциклов ?
подчеркну, выделить что-то “очевидно основное” будет затруднительно. контора и магазин, и рем-сервис и т.п.
хорошо, пусть будет некий тэг контора = что-то_связанное с мотоциклами, а тэги выше - будут уточняющими;
а если контора не только “что-то_связанное с мотоциклами”, но и “что-то_связанное со снегоходами” и “что-то_связанное с квадроциклами”?
ок, пусть будет главный тэг контора = “что-то_связанное с ТС с ДВС” (ага, конторы с авто, запчастями и мопедами туда могут легко попасть)
при запросе его из базы либо пишем простой запрос огромного масштаба и дальше его фильтруем/парсим (что нагрузочно), либо пишем хитрый связанный запрос с условиями, под-условиями и т.п (что не всегда тривиально и сильно зависит от конкретики).
схема с несколькими “главными ключами” позволяет весьма просто вытянуть из базы только нужное нам. например “ремонт мотоциклов”, “тюнинг квадроциклов” и “продажа мотоэкипировки”.
Тут основная проблема совсем не в АПИ. Нынешний АПИ все это в том или ином виде позволяет. Проблема в другом. Кто и как будет всю эту информацию собирать и актуализировать?
Нужен робот-паук, который бы обходил сайты бильярдных, собирал бы информацию с них, и складывал бы в отдельную базу. Причем в осм нужно обозначать только сами бильярдные самым примитивным образом.
Что-типа:
leisure=billiards_club
website=www.xxxx.yy
Теперь представим тоже самое, только про магазины. Можно ли в осм внести ассортименты магазинов, включая цены? Можно. Но никто в здравом уме делать этого не будет. Если нужно купить что-нибудь, отличное от товаров первой необходимости, никто магазины по уточняющим тегам искать не будет. Найдут нужное коммерческое предложение в гуглояндексе, а потом уже по адресу на карте, если нужно в найденный магазин ехать.
Вот это схема и пытается разнести, смотрите:
sport=yes
sport:billiard=yes - два тега для “обычных”, “первой необходимости тегов”
sport:billiards:type=[“pool”, “snooker”, “pyramid”] — этот тег поймут только игроки в бильярд (очень часто им не нужно показывать страницу на вики с таких подходом)
sport:billiards:table_size = [pool:(7ft, 8ft), snooker:(9ft, 12ft)] - этот тег будут заполнять только те, кто разбирается в размерах столов или **хочет этой информацией пользоваться ** (дело не в “скорость обновления” или “актуальность” данных в OSM)
Т.е. зарубили вы схему тегирования бильярдов только потому что “она не первой важности” — зачем?
по первому согласен с вами.
по второму - пусть будет возможность описывать объекты подробно и удобно (как для отмечающих, так и для использующих)
непосредственно по тэгам - не будет.
но если перед юзером будет карта Питера, где можно вывести значками магазины, торгующие мотоэкипировкой (при этом не выводить дилерские центры, барыжащие мото-техникой) - это гораздо удобнее и оперативнее, чем искать их яндексом и прочими поисковиками.
а карта будет рисоваться на основе запросов.
и да, по поводу здравого смысла и ассортимента магазинов.
полагаю, были времена, когда этажность зданий, напряжение линий электропередач и количество путей у железной дороги тоже считались излишними. однако ж
(если мне не изм. память, читал, что уже поребрик в ОСМ рисуют, с отметкой высоты )
Еще раз повторюсь. Вы ставите телегу впереди лошади. Обеспечить хранение актуализацию списка товаров и услуг, которые предоставляет некая контора, осм не может, и дело тут не в схемах.
Схема же основана на принципиальном свойстве объектов реального мира к классификации. Например, существуют типовые виды магазинов с предсказуемым ассортиментом плюс специализированные магазины, которые могут торговать каким-то узким ассортиментом. При этом для поиска через базу осм много полезнее первые.
, мне всё это действительно интересно 