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

Vitalts · 2015-02-02T12:44:21.000Z

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

wowik · 2015-02-02T13:02:01.000Z

Парсинга значений заменяем на парсинг ключей.

Опять уходите от ответа.
Как от этого поменяется функциональность программ? Что нового увидит их пользователь?

Мы таки наконец обретем поддержку целостности границ?

Или просто получим в чем-то более стройный код, на что пользователю глубоко наплевать. Скорее наоборот, если он теги пишет ручками в JOSM /Potlach 1, то ему только хуже.

d1g · 2015-02-02T13:04:03.000Z

Vitalts:

Парсить не пользователи должны, а софт.

И ЧТО?

d1g:

Те кто не хотят парсить ничего (>80% пользователей! сюрприз!), получают возможность используя <простые смысловые ключи>=yes либо <простые смысловые ключи>=<одно конкретное значение> делать запросы к БД без перебегания к парсингу чего-либо или регулярных выражений.

Vitalts:

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

И конечно же у меня есть единомышленники в этом.

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 появится автоматически как “бильярд вообще”, после добавления тэга/значка в рендер карты - как именно пирамида.

wowik:

Опять уходите от ответа.
Как от этого поменяется функциональность программ? Что нового увидит их пользователь?

То, что вы не понимаете преимущества сериализации и отсутствие этапа парсинга для пользователей это не уход от ответа. Это ваша упёртость на обязательности парсинга для всех. Вам ответили в 50 раз, вы опять сводите всё к парсингу своему.

“Преимущества для пользователей”

d1g:

Те кто не хотят парсить ничего (>80% пользователей! сюрприз!), получают возможность используя <простые смысловые ключи>=yes либо <простые смысловые ключи>=<одно конкретное значение> делать запросы к БД без перебегания к парсингу чего-либо или регулярных выражений.

wowik · 2015-02-02T13:10:01.000Z

d1g:

И конечно же у меня есть единомышленники в этом.

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

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

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

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