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

Здравствуйте.
Опять уход в сторону.

Какую новую не решаемую в текущем ОСМ задачу обработки и хранения данных вы сможете решить новой схемой?

Не не только моё. И не единственное.

То,что ты думаешь *в 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 умеет писать регулярки за

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

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

Не согласен с чем именно?

Я говорю о том, что есть две категории тегов, условно “основные” и “уточняющие”. Для основных тегов нужно выбрать ОДНО значение, которое описывает данный объект в наилучшей степени. Дорога не может быть одновременно “первичной” и жилой улицей, река не может быть одновременно ручьем, больница одновременно не может быть концертным залом, и. т.д.

В уточняющих тегах возможны списки. У дороги может быть несколько номеров (ref), у адвокатской конторы несколько телефонов, у ресторана несколько кухонь.

Это идейная основа существующей схемы. Разрешение множественности вообще везде (например поддержка этого в API, без разбора что это за тег) – это глобальная смена парадигмы, которая потребует переделки всех приложений.

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

Ой, у вас ус отклеился синтезатор речи сломался.

Не умеешь - не пиши, опять же, я то тут при чем?

Мне вот интересно просто, какие тебе понядобятся вычислительные ресурсы чтобы осмеры в массе своей начали писать:


"sport:billiard:snooker"=yes
"sport:billiard"=yes
"sport"=yes

да еще, чтобы не забывали это делать.

тут нюанс. софт-то люди пишут. и чем ниже порог вхождения для его написания (квалификация, трудозатраты), тем больше можно ожидать проектов, использующих базу OSM (а зачем она нужна, без использования).

дальше вполне реальный пример с вопросом (отмечу, что не утверждаю, именно спрашиваю)
итак, снова про бильярд:

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

  • тип бильярда (пирамида, пул, снукер, карамболь);
  • размеры столов;
  • изолированность столов (общий зал либо отдельные комнаты для каждого стола);
  • наличие/отсутствие бара;
  • меню бара (пиво, сок, чай, минералка);
  • время работы всего этого с нюансами (например ночью бар может и не работать);

пример не с потолка. когда я активно посещал бильярдные :slight_smile: , мне всё это действительно интересно :slight_smile:
вопрос в следующем - насколько при текущем АПИ всё это реально/сложно/долго делать?

теперь представим, что сайт не про бильярд, а про спортивные/игровые/развлекательные заведения вообще (опций, соответственно, прибавится). повторим вопрос.

Да, я с этим согласен. В том виде что:

romul_zurov очень здравую мысль высказал про “скорость вхождения” в систему тегов

Уважай коллективный труд. Если тысячи мапперов считают нормальным писать building:, то нужно перекроить для них чуть-чуть БД. Обновить программы конвертеры и редакторы.

Ресурсы - такие же как и раньше, то тегу на смысл объекта мира. Индексов нужно будет больше чтобы это отрабатывало за миллисекунды для планеты. Битовые операции и блум фильтры никто не отменял. Если время не критично 10мегабайт нулей битсетов можно сжать в килобайт.

Ну вот о чём ты говоришь. Кому нравится так тегировать, не будет забывать. У 812 тегов building:roof:color указано 697 building=yes. “не ходи по тротуагу на тебя слон может упасть”. Да, может. Мне то что с этого?

Зачем ты мне тогда её предлагаешь???

https://code.google.com/p/re2/, К твоему сведению ни у кого в мире в свободном доступе не удавалось запустить регулярку быстрее O(N) (длинна входной строки это минимум). Или мне стоит ссылку на этот форум в комитет IEEE передать? Как ты запускаешь регулярки за log(n)? У меня волосы дыбом стоят от твоих аргументов, объяснись пожалуйста.

Это не моя невнимательность. Это ты путаешь регулярки с GIN или какими-то индексами/деревьями. Выражай свои мысли более подробно, иначе меня это очень раздражает.

Это твоя невнимательномть. То что оверпас сейчас использует регулярки, не значит что оны нужны для поиска по значению тега, из списка с разделителем. И не значит что я их использую. Ты просил решение проблемы - я тебе дал ссылку. Никто не говорит что это единственно возможный или самый эфективный способ решения проблемы.

В IEEE напиши конечно, почему мы одни должны вкушать прелести общения.

Тоесть в 100 слуяаях из 800 те кому нравится тегировать цвет крыш не проставили общий тег?
Как что тебе с того? Это же кошмар, ведь не указаны свойства зданевости, крышеобладания, крышецветаобладания.
Указано только свойство крышезданеконкретноцветности!

В общем я присоединяюсь к вопросу wowik’а: что позволит решить схема “строка”=yes чего не позволяет решить “строка”=“строка”

Я понял тебя, никем никогда не написанный код из регулярки попытаться сделать “крибле-крабле” и получить ответ от несуществующего алгоритма, которого прямо сейчас в overpass нет. Я тебе уже говорил что твоё “решение” нерабочее.

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

Ни регулярки
Ни обратный индекс по неосмысленным лексемам

Не учитывают смысл ключ=значение.
Не учитывают смысл очень:осмысленная:схема=однозначение

Ты в числах 1597-1880 тоже считаешь нормальным искать по “80”? Будешь предлагать границу слов искать как еще одно “решение”? Вместо двух тегов в OSM?

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

  • продаёт б/у мотоциклы:
  • торгует мотоэкипировкой;
  • предоставляет услуги ремонта мотоциклов;
  • предоставляет услуги зимнего хранения мотоциклов;
    всё это в одном месте, одна контора;

выделить что-либо главное - как?
shop = мотоциклы ?
shop = мотоэкипировка ?
service = ремонт японских мотоциклов (ремонтировать bmw они могут и не взяться) ?
service = зимнее хранение мотоциклов ?

подчеркну, выделить что-то “очевидно основное” будет затруднительно. контора и магазин, и рем-сервис и т.п.

хорошо, пусть будет некий тэг контора = что-то_связанное с мотоциклами, а тэги выше - будут уточняющими;
а если контора не только “что-то_связанное с мотоциклами”, но и “что-то_связанное со снегоходами” и “что-то_связанное с квадроциклами”?

ок, пусть будет главный тэг контора = “что-то_связанное с ТС с ДВС” (ага, конторы с авто, запчастями и мопедами туда могут легко попасть)

при запросе его из базы либо пишем простой запрос огромного масштаба и дальше его фильтруем/парсим (что нагрузочно), либо пишем хитрый связанный запрос с условиями, под-условиями и т.п (что не всегда тривиально и сильно зависит от конкретики).

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

Тут основная проблема совсем не в АПИ. Нынешний АПИ все это в том или ином виде позволяет. Проблема в другом. Кто и как будет всю эту информацию собирать и актуализировать?

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

Что-типа:

leisure=billiards_club
website=www.xxxx.yy

Теперь представим тоже самое, только про магазины. Можно ли в осм внести ассортименты магазинов, включая цены? Можно. Но никто в здравом уме делать этого не будет. Если нужно купить что-нибудь, отличное от товаров первой необходимости, никто магазины по уточняющим тегам искать не будет. Найдут нужное коммерческое предложение в гуглояндексе, а потом уже по адресу на карте, если нужно в найденный магазин ехать.