И всё-таки. Какую НОВУЮ задачу позволит решить нововведение? Кроме того, чтобы сломать старое?
Как мне теперь выбрать все amenety:* одним махом?
Простота разбора значений компенсирована сложностью выборки ключей.
И всё-таки. Какую НОВУЮ задачу позволит решить нововведение? Кроме того, чтобы сломать старое?
Как мне теперь выбрать все amenety:* одним махом?
Простота разбора значений компенсирована сложностью выборки ключей.
“Преимущества для пользователей” “Преимущества для разработчика”. Я там мало написал, все преимущества могут не сразу очевидны. Zverik-а осенило, но я не уверен что он понял полностью всю задумку.
Почему нужна новая задача когда со старой задачей теги не справлялись?
name=Заправка
amenity=fuel;fast_food
Вы умеете писать рендеры которые будут выдирать правильную иконку? Или давать одну ссылку на документацию которая будет описывать только одну схему?
Зачем конечному пользователю в здравом уме знать все amenity=* теги которые мы напридумывали до этого?
Если вы давно документацию не открывали их пытались сгруппировать на 7 групп уже:
http://wiki.openstreetmap.org/wiki/Key:amenity
Пф. Указываем тег-костыль amenity=yes на время перескакивания через знак равно в key=value.
Пользователи которые считают что регулярка amenity=* хоть что-то значит, остаются в прошлом с их нерешаемыми проблемами двойственности объектов в рамках псведо-смысловых amenity= (amenity не значит ничего! сюрприз!)*.
Не пользователю, а программе. пользователь вобще тегов не видит.
Что-бы выбрать иконку, к примеру. Да и вообще, узнать сам факт, что это amenity
что это???
fast_food я знаю.
restaurant я знаю.
pub я знаю.
Объясните теперь мне что такое amenity и почему я должен его приписывать хоть где-то?
Я знаю 500 тегов amenity, теперь мне надо делать выборку объектов по всем 500 ключам вместо одного?
То есть предлагается ввести группы и иерархию тэгов?
Тогда предлагаю перепрыгнуть этот этап и сразу перейти к языку разметки - описательный текст в произвольной форме в котором встроены ключевые слова.
Примерно так:
#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 с иерархией полей, а теперь вот разметка текста хэш-тэгами.
Уже всё продумано кроме реализации плагинов JOSM и конвертеров *для временной совместимости со старыми amenity=**.
Хочет пользователь “заведения питания”, я ему буду искать “amenity:fast_food”=yes | “amenity:restaurant”=yes | “amenity:pub”=yes | …
Я этот запрос напишу один раз в жизни и выложу на гитхаб, другие программисты такие запросы по сотне и тысяче запросов составляют в день только чтобы проверить данные в OSM.
Эти усилия можно объединить в единый репозиторий запросов.
openstreetmap.ru это называет “каталог тегов” или “точки интереса POI”. Эта возможность должна быть
Тег phone=, voltage= (для power объектов) в исключениях не забудьте. А вообще исключения должны быть для всех тегов имеющих несколько числовых или уникальных символьных значений, т.е. то что пихать в tag:* вместо астериска не имеет смысла.
Всё верно, выбрать объекты-ПОИ мне надо запросить все объекты и перибирать ключи на предмет попадания в маску amenity:* вместо запроса всех объектов с ключем amenity.
Для многих программ не обязательно знать СМЫСЛ конкретного ключа, а вы напираете именно на то, что неизвестную разновидность amenity:* не придется никогда запрашивать.
Ну а придумать-то можно всё что угодно, но новых практических горизонтов оно не открывает. Какие-то программы упростятся, какие-то сильно усложнятся…
Мапперу проще жить не станет точно. Тут точка с запятой вне конкуренции. Объяснить гораздо проще.
А всё, что нельзя просто объяснить обыкновенному мапперу, нашему главному источнику данных, надо выкидывать из проекта.
Плюс еще куча исключений. Будем новичкам сразу две схемы объяснять? Или сначала точку с запятой для времени работы и телефонов, а потом amenity:*?
Говорю же нет, только один тег-костыль:
amenity=yes // либо очень любимый вам amenity=<смысловойтег13>
amenity:<смысловойтег1>=*
amenity:<смысловойтег1>:description=Его зовут 1
amenity:<смысловойтег500>=*
amenity:<смысловойтег500>:description=Его зовут 500
Как только программы научатся обрабатывать <смысловойтег1>, <смысловойтег500> тогда amenity=yes можем убить (или оставить в назидание) как бессмысленный пережиток прошлого.
Что значит amenity прямо сейчас??? Какой программе нужно выполнить запрос *amenity=**, покажите мне кусок кода этой программы, я скажу насколько она сломана и откуда растут руки у кого.
Смысловые-группы-изоляторы для тегов точно да (не в рамках API 0.6), без них никак не обозначить два объекта мира одной точкой (любой геометрией):
Это требует очень сильных статистиков которые очень быстро будут разрабатывать алгоритмы классификации и ранжирования в OSM. Этот подход могут позволить большие компании с штатными людьми, для хоббистов и набегающих-убегающих программистов в OSM это будет тяжело вести такую постоянно эволюционируют штуку. Мы с “жесткими” тегами не очень быстро растём (в плане сложности иерархий, у нас до сих пор всё лепят под amenity=, man_made= только потому что “их миллионы, посмотри сам”.
Понял вашу затею, вы пытаетесь упростить “говорливые теги” pub=yes и “ref:ИНН”=* до отдельных символов.
Да, они исключения потому что не ищут по 11значным цифрам телефона и конкретному значению напряжения.
Конвертор, рендер
а до этого надо будет отдельно заниматься поддержкой “костыля”, синхронизацией и валидацией на предмет согласованности старой схемы с новой.
Да, и мапперам будем объяснять не просто две схемы, а еще и заморочки по поддержанию их в согласованном виде
Нет, ИНН там просто так написано, без разметки (сейчас оно лежит в comment). pub не знаю откуда вы взяли, там магазины.
ИНН с разметкой было бы как-то так:
#ИНН: 7735108290
Кому не надо, может не учить.
Должен быть визуальный редактор, прячущий разметку в графическое оформление (примерно как HTML отображается), в котором можно выделить часть текста и сказать “А это название”, потом другой текст - “А это телефон”, а потом задать тип объекта - “Это магазин”. Ну и само должно догадываться в некоторых случаях и предлагать (+7… - это вы телефон ввели?)
Ну а кому нужна тонкая настройка - открывает обычный редактор и правит в кодах.
Зачем им вообще все amenity= на свете? Mapnik разве научился лавочки рисовать?
http://taginfo.openstreetmap.ru/tags/amenity=bench - и лавочки ему надо
http://taginfo.openstreetmap.ru/tags/amenity=kindergarten - и детские садики ему надо
http://taginfo.openstreetmap.ru/tags/amenity=fuel - и заправку ему надо
http://taginfo.openstreetmap.ru/tags/amenity=public_building - и бессмысленный устаревший тег ему надо
http://taginfo.openstreetmap.ru/tags/amenity=police - и полицейское непонятно что тоже надо
http://taginfo.openstreetmap.ru/tags/amenity=fountain - и фонтан, вот он, смотрите
Подождите-ка… Mapnik не рендерит фонтаны, зачем они ему нужны? Зачем он спрашивал мою postgresql глупыми запросами о amenity=public_building?
amenity=<старое значение>
man_made=<старое значение>
sport=<старое значение>
Можно восстановить из истории объекта или выявить из “неймспесовой” версии объекта. Если они там есть то скопировать первое попавшееся. Потому что костыль он и есть костыль, нельзя два смысла указать одним смысловым ключом и одной геометрией без использования отношений.
Самый тупой бот справится:
Пусть влепит amenity=<смысловой тег1> потому что он нам очень нравится и мы иконку покажем.
Еще раз: в рамках старой схемы невозможно отметить
Одной геометрией, хоть бочку сделайте. Вам придётся отношения мне предлагать как “решение”.
amenity=bank // тег-костыль
amenity:atm=yes
amenity:bank=yes
amenity:bank:description=тут точно банк
Как только введут смысловые перегородки или группы (плохое слово, не объясняет), мы сможем такое затегировать одной геометрией и без неймспейсовости в ключах. Без всяких отношений использующих одну и ту же геометрию (это очень печально что нам иногда приходится такое делать, давайте упрощать и без того сложные для новичков отношения).
<семантическая группа>
atm=yes // строгий тип, временно задокументирован на вики как ссылка-перенаправление на amenity=atm
</семантическая группа>
<семантическая группа>
bank=yes // строгий тип, временно задокументирован на вики как ссылка-перенаправление на amenity=bank
description=тут точно банк
</семантическая группа>
PS. Мой вопрос про смысл amenity остался без ответа.
Вставлю своё имхо.
Схема с shop:, лично мне, кажется более логичной и гибкой чем вариант с ;. (как и во многих других похожих ситуациях) Так что я скорее за, чем против. Однако, мне кажется что не стоит пытаться протаскивать отмену shop, ибо во-первых, 99% магазинов успешно укладываются в примитивную shop= схему, во-вторых, так удобнее программам, ибо облегчается поиск и рендеринг. Кроме того, не стоит переусложнять схему без лишней на то надобности. (например, вместо shop=yes, shop:cofee=main, shop:tea=yes или хуже того shop:cofee=main, shop:tea=yes, лучше использовать shop=cofee, shop:tea=yes, т.е. применять shop:* теги именно как расширяющие) Кроме того, считаю, что неправильно пытаться тоталитарно запрещать точку с запятой, достаточно при описании схемы “рекомендовать”, а дальше народ (в т.ч. и пользователи данных) сам решит, нужно ему это или нет.
Таким образом, на мой взгляд, поступать лучше следующим образом: оформить товарищу d1g (как самому активному адвокату этой схемы) полноценный пропозал с подробным описанием всех его идей (ну или же допилить тот старый), после чего мы обсуждаем его на форуме, полируем, далее по готовности выставляем на обсуждение с международным сообществом с последующим голосованием. По идее если составлять расширяющий пропозал, то никаких проблем с протаскиванием схемы возникнуть не должно. А тоны региональных обсуждений и междуусобчиков, развитию схем помогают мало.
Уже возникло, спор вокруг англоязычной статьи просто так не возник. Есть до такой степени упёртые люди в tagging@ что вся аргументация сводится “нет, потому что я так сказал”, “откатываю все твои правки потому что консенсуса нет”.
Не согласен.
Есть чисто русские теги. Мы отлично живем с ними и обрабатываем их и улучшаем по чайной ложке.
http://taginfo.openstreetmap.ru/keys/addr:flats - чтобы вы знали только в России мапят так детально
http://taginfo.openstreetmap.ru/search?q=tickets%3A - tickets: теги только наши придумали
Изменения в API в любом случае нужно будет продвигать. Если наши продвижения не будут согласованы и подтверждаться пятизначными циферками в Taginfo - о чём речь?
Пока что да, не стоит.
Конечно люди не будут тегировать 99% объектов. Вы что. Мы ботов напишем которые автоматом поставят явные main-теги из старых shop=*.
Если объект был однозначный и все теги его были непротиворечивые (shop=tea, name=, opening_hours=), то по новой схеме добавит новые теги бот
Если объект был изначально противоречивый (amenity=atm;bank + name=Банк), то ни один человек без знаний местности не сможет перетегировать нормально такие данные
Человек ставит shop=cofee, shop:tea=yes (только расширяющие теги)
Бот его слова дополняет: shop=cofee, shop:tea=yes, shop:cofee=main
Если бот будет работать не так: не те теги ставить — исправим бота и опишем в статье про схему как всё работает.
Пропустил важный вопрос. Приоритет нужно отдавать сложной неймспейсовой схеме (которую разрабатываем сейчас), а не старой-тупой shop=tea, sport=multi.
Старые теги можно накостылить из новой схемы - обратное абсолютно неверно и повлечёт собой противоречивые данные. Мы для этого неймспейсы и используем, чтобы противоречия разрешить, другого инструмента нет (кроме как нескольких отношений на одной геометрии).
Старые теги можно указывать ботом из тегов новой схемы. Совместимостью для “программ сегодня” должны заниматься боты. 99,9% работы должны делать боты, а не люди.
Если мы тегировали правильно, то противоречия будут только для >0,1% данных. Наверняка противоречий будет больше - как много узнаем когда будем вникать в детали написания бота.
Научим новичка “пиши sport:soccer=yes, sport:hockey”, “sport:basketball”=yes
Используй неймспейсы когда указываешь имя только у чайного магазина “shop:tea:name”=“Чайки” (JOSM ему должен показывать дерево и только name=“Чайки”). Бот на основании только этого тега может поставить заготовку shop:tea=yes (yes именно заготовка “что-то есть”, основные значения main, parital, no).
Весь этот бред с префиксами только временный, пока мы ждём новую структуру данных, чтобы потом ввести смысловые коробки и адекватные теги tea=yes (“что-то продающее чаи”), sport:hockey=yes “что-то связанное с хоккеем”.
amenity, man_made, shop не схемы не первой свежести и не полной адекватности. Вопросы о различиях и сортировки на leisure/amenity возникают постоянно у всех участников OSM. Это говорит только о несостоятельности классификации leisure/amenity.
Эту несостоятельность преподносим новичкам как какой-то священный дар. Неколебимые теги в OSM, улюлю.
Потом у нас разбухают темы “как обозначать на 300 страниц”. “Стадион это amenity или leisure?” - это же сакральные знания которые написаны в OSM wiki. staduim=yes мне написать нельзя, так не принято.
До тегов tea=yes, stadium=yes додумывались.
До проблемы двойственности объектов (“стадион” это не только развлечения leisure, но еще и инфраструктура amenity в виде трибун, ограждений) ни у кого решения не доходило кроме Российский мапперов. У нас возникают сложные теги через :, мы можем осознать двойственность объектов и придумать теги с маленькой смысловой информацией - а они нет.
До проблемы семантических коробок и изменения API для тегов никто не доходил, они даже неймспейсами разрулить ситуацию не догадались.
Если мы начинаем описывать ассортимент продуктов в магазине, то “вторичные” продукты легко вынести в отдельный тег, а shop оставить так как есть
shop=clothes
shop:secondary=toys
Если ассортимент равнозначный по важности, то оставляем
shop=clothes;shoes
Насколько я помню API не позволяет такое:
shop=clothes
shop:secondary=toys
shop:secondary=kids
shop:secondary=electronics
В противном случае если бы API позволял мы бы пользовались таким:
shop=clothes
shop=toys
shop=kids
А не пытались нагородить всё в value у бедных key.
Ни один вариант с несколькими значениями в value не подойдёт.
У вас прямо сейчас ни один рендер не сможет показать иконку кроссовок для shop=clothes;shoes, даже если он для shop=shoes умеет это делать.
в целом согласен с 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 появится автоматически как “бильярд вообще”, после добавления тэга/значка в рендер карты - как именно пирамида.
плюс без проблем можно добавлять размер столов, например:
sport:billiards:pyramid:12ft=yes
sport:billiards:pyramid:10ft=yes
или возможность фотографироваться барышням на столе :
sport:billiards:pool:photo_on_table:female=yes
засовывать всё это в sport=billiards через точку запятой, имхо, неправильно
Я что-то пропустил или вы уже оформили свои предложения на вики, обсудили плюсы и минусы с сообществом в одном месте (а не N постов в рассылке, пара страниц на региональном форуме и пара дюжин в личных сообщениях), после чего провели голосование и успешно приняли схему? Неудивительно, что на ваше “мне так видится” следует закономерная реакция.
А вот это отличный пример “плохой практики”, ибо из-за того что нам лень оформлять и принимать пропозалы, плодятся региональные теги, что проекту (а он напоминаю международный) ну никак на пользу не идёт. Вы же пытаетесь из этого сделать традицию, чего я поддерживать не собираюсь, а даже скорее буду сильно против.
Изменения API безусловно продвигать нужно, только мы сейчас обсуждаем изменения в схемах.
А вот это называется ставить телегу вперёд лошади. Попытка принять схему на основании “использования де факто”, вместо “скучного” процесса написания/обсуждения/принятия пропозала, это тоже пример “плохой практики”. Надеюсь, раскрывать почему это так нет необходимости.
Я считаю, что не только пока что, но и в последующем не стоит. Ибо ради 1% заставлять остальные 99% использовать усложнённую схему не есть правильно. Кроме того, подход описанный мной, позволит убрать значительную долю критики (справедливой, стоит заметить) связанный с использованием shop:* тегов без материнского shop=*, при этом не потеряв ничего в гибкости, и даже добавив немного в лаконичности.
А вот это уже откровенно попахивает NIH синдромом. На кой чёрт заводить ботов и принуждать пользователей использовать усложнённую схему, когда для 99% случаев достаточно примитивных shop=*, которые отлично работают чуть ли не с момента основания проекта?