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

d1g · 2015-02-02T13:13:33.000Z

wowik:

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

Добрый день! Начнём всё сначала в 20 раз.

Покажите мне работающие программы для


name=Банкомат
amenity=atm;bank
description=здесь точно банк

а не для


amenity=yes
amenity:atm=yes
amenity:atm:name=Банкомат
amenity:bank=yes
amenity:bank:description=здесь точно банк

dkiselev · 2015-02-02T13:44:06.000Z

d1g:

Покажите мне работающие программы для
name=Банкомат
amenity=atm;bank
description=здесь точно банк

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

d1g · 2015-02-02T13:52:55.000Z

dkiselev:

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

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


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

Хочу бильярды снукер 9 футовый.

sport:billiards=yes and sport:billiards:snooker:9ft=yes

Особо не усердствуй с регуляркой, я её сломаю “любой снукер”

“sport:billiards:snooker”=yes

В твоём языке “регулярных выражений” нет термина снукер. Ты будешь всю жизнь писать мне действительно работающий ответ.

dkiselev · 2015-02-02T13:58:36.000Z

Так, вопрос был дай мне объект по второму значению из списка. Ответ дан? Дан.

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

wowik · 2015-02-02T14:09:31.000Z

d1g:

Добрый день! Начнём всё сначала в 20 раз.

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

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

d1g · 2015-02-02T14:13:33.000Z

dkiselev:

о, что твое единственноправильное представление о мире и осм

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

То,что ты думаешь *в sport= можно вместить всё насвете - только твоя особая картина мира. С ней не согласны.

ynx:

Ха! Очередная тема как впихнуть невпихуемое.
А потом выясниться, что чай продают только до обеда, а вот кофе круглосуточно и опять думать какбы это всё замапить. %)

dkiselev:

не находит живого отклика в сердцах публики - абсолютно не мои проблемы.

Это только твоё мнение. Пропагандист тоже мне.

OverQuantum:

d1g:

<семантическая коробка>

То есть предлагается ввести группы и иерархию тэгов?
Тогда предлагаю перепрыгнуть этот этап и сразу перейти к языку разметки - описательный текст в произвольной форме в котором встроены ключевые слова.

Примерно так:
#shop,supermarket
#name: Десяточка
#operator: {ООО "АСП-ГРУПП"} /ИНН 7735108290
#opening_hours: 08:30-22:45 /c 2014-05-23
Отличные пирожные продают

{
Ранее тут был #name: Квартал
Закрыт с 2013-02-22, ООО "АСП-Групп", ИНН 7735108290, Сеть магазинов "Витория Квартал", телефон магазина с сайта "(+7 495) 535-23-58"
#email: inform@victoria-group.ru
#opening_hours: 24/7
#phone: +78002004454
#website: http://www.victoria-group.ru/shops/kvartal/addresses.php?region=msk
#disused,shop,supermarket
}
Кому надо - рендерит красивую страницу с описанием. Кому надо - парсит тэги.

Я примерно так же двигался, когда придумывал как телефонную книжку удобнее организовать. Сначала таблица, потом key=value, потом XML с иерархией полей, а теперь вот разметка текста хэш-тэгами.

maxphizik:

Я поддерживаю предложение d1g. Ещё бы в JOSM сделать удобным ввод тегов с различными неймспейсами, было бы вообще классно.

newpavlov:

Схема с shop:, лично мне, кажется более логичной и гибкой чем вариант с ;. (как и во многих других похожих ситуациях) Так что я скорее за, чем против. Однако, мне кажется что не стоит пытаться протаскивать отмену shop, ибо во-первых, 99% магазинов успешно укладываются в примитивную shop= схему, во-вторых, так удобнее программам, ибо облегчается поиск и рендеринг. Кроме того, не стоит переусложнять схему без лишней на то надобности. (например, вместо shop=yes, shop:cofee=main, shop:tea=yes или хуже того shop:cofee=main, shop:tea=yes, лучше использовать shop=cofee, shop:tea=yes, т.е. применять shop:* теги именно как расширяющие) Кроме того, считаю, что неправильно пытаться тоталитарно запрещать точку с запятой, достаточно при описании схемы “рекомендовать”, а дальше народ (в т.ч. и пользователи данных) сам решит, нужно ему это или нет.

romul_zurov:

в целом согласен с d1g.
текущая схема для обозначения, например, бильярда позволяет сделать так:
sport=billiards
sport=pool
sport=snooker
sport=snooker;pool
и всё это нужно учитывать при создании гипотетической карты бильярдных.
через пол-года энтузиаст русской пирамиды навтыкает sport=pyramid (а чем это хуже sport=snooker, к примеру) - и на карте их не появится.
при схеме:
sport:billiards=yes
sport:billiards:pool=yes
sport:billiards:snooker=yes
добавление sport:billiards:pyramid=yes появится автоматически как “бильярд вообще”, после добавления тэга/значка в рендер карты - как именно пирамида.

d1g · 2015-02-02T14:21:21.000Z

dkiselev:

Так, вопрос был дай мне объект по второму значению из списка. Ответ дан? Дан.

Ты в курсе вообще об алгоритмической сложности?
http://overpass-turbo.eu/?w=%22shop%22~%22mobile_phone%22%20global

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

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

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

dkiselev · 2015-02-02T14:21:52.000Z

d1g:

Хочу бильярды снукер 9 футовый.

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

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

dkiselev · 2015-02-02T14:29:55.000Z

d1g:

dkiselev:

Так, вопрос был дай мне объект по второму значению из списка. Ответ дан? Дан.

Ты в курсе вообще об алгоритмической сложности?
http://overpass-turbo.eu/?w=%22shop%22~%22mobile_phone%22%20global

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

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

временные оценки

затраты памяти твоего “решения” shop~mobile_phone

**затраты CPU на вычисления твоей регулярки для многомиллионных ключей базы **

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

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

d1g · 2015-02-02T14:33:07.000Z

dkiselev:

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

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

dkiselev:

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

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

dkiselev:

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

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

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

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

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

“sport:billiard:snooker”=yes

Zkir · 2015-02-02T14:47:10.000Z

Текст спрятал временно, там были небольшие недоговорённости в тексте (секцией про “поддержание двух схем” и "этапы перехода со старого shop=* на shop:value=* я не написал, а без них смысл не тот).

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

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

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

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

chnav · 2015-02-02T14:59:10.000Z

d1g:

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

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

d1g · 2015-02-02T15:02:44.000Z

Zkir:

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

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

Zkir:

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

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

Zkir:

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

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

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

Zkir:

туда, где множественность вовсе не предполагается

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

d1g · 2015-02-02T15:07:24.000Z

chnav:

По моему в условиях лицензии OSM прямо указано, что сервер предоставляет открытые данные, но не сервис обработки запросов планетарного масштаба.

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

chnav:

В overpass API тоже есть нечто схожее.

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

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

dkiselev:

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

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

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

Zkir · 2015-02-02T15:36:09.000Z

d1g:

Zkir:

туда, где множественность вовсе не предполагается

Я с этим не согласен.

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

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

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

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

dkiselev · 2015-02-02T15:43:10.000Z

d1g:

dkiselev:

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

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

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

d1g:

dkiselev:

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

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

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

d1g:

dkiselev:

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

Прости, я не умею писать регулярки для
sport=billiards;pyramid:12ft;pyramid:10ft;snooker:9ft;snooker:12ft
У тебя видимо дар особый, и можешь написать регулярку которая найдёт снукер, а я нет, убогий, мне нужны решения какихт-то проблем.

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

“sport:billiard:snooker”=yes

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

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


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

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

romul_zurov · 2015-02-02T16:16:55.000Z

Vitalts:

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

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

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

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

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

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

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

d1g · 2015-02-02T16:17:45.000Z

Zkir:

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

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

atm=yes - главный ключ.

bank=yes - главный ключ.

sport:<гребля>=yes - главный ключ
sport:<каное>=yes - главный ключ

sport=yes - главный ключ для некоторых программ
sport:<гребля>=yes - главный ключ для некоторых программ
sport:<каное>=yes - главный ключ для некоторых программ

sport=yes - главный ключ для некоторых программ
sport:<гребля>=main - main ключ, главный ключ для некоторых программ
sport:<каное>=yes - главный ключ для некоторых программ

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

d1g · 2015-02-02T16:27:32.000Z

dkiselev:

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

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

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

dkiselev:

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

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

dkiselev:

Я не использую регулярки для решения задачи поиска.

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

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

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

dkiselev · 2015-02-02T16:38:59.000Z

d1g:

dkiselev:

Я не использую регулярки для решения задачи поиска.

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

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

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

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

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