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

Не совсем заглушка.

1. Прямо сейчас в OSM:

generator:source=gas
generator:method=combustion
generator:output:cold_water=yes
generator:output:electricity=225 kW

1. После очень сильных изменений в бекенде и во всех приложениях

<семантическая коробка, типизированная>
generator=yes - строгий тип, задокументирован на вики
source=gas
method=combustion
output:cold_water=yes - вложенность коробок-типов тоже можно учесть, их тоже можно строго типизироваться и задокументировать, никаких угадаек по Taginfo и вопросов "как обозначать X"
output:electricity=225 kW
</семантическая коробка, типизированная>

То что ты называешь “просто тег” это строгий тип, задокументированный на вики. Схема тегирования его свойств будет ясна автоматически как только ты открываешь http://taginfo.openstreetmap.org/tags/supermarket=yes

Преимущества строгих типов над строками через ; настоящим программистам не нужно объяснять.

Если хотим развиваться, OSM придётся сделать бочку и вкладывать смысл в key, а не key(дурацкие man_made,amenity,leisure)=value.

Но кто-нибудь туда обязательно воткнет «тег=no» или даже придумает «тег=что-то» и станет требовать поддержки в рендере

В предложении речь не только о poi-тег=yes, а о poi-тег=yes, poi-тег=main, poi-тег=partial, poi-тег=no. Это преимущество схемы, а не недостаток. Прямо сейчас вы делаете это через was:leisure…

Вместо stadium=no вы пишете was:leisure=stadium/disused:leisure=stadium/abandoned:leisure=abandoned.

Я по секрету скажу что теги
abandoned=yes
disused=yes

Должны быть основными, а не запрещёнными. Это возможно сделать только и только если у вас есть семантическая коробка или сильная неймспейсовость в key (у пар key=value):

<семантическая коробка>
stadium=yes - строго типизированный тег, задокументированный на вики
disused=yes
name=Спартак
description=уже не тот что раньше
</семантическая коробка>

disused:, abandoned: это костыли которые я всецело поддерживаю в рамках API 0.6 чтобы абсолютно все программы работали нормально.

Не придумают. yes/no/partial/main это всё-всё-всё на свете что вы можете сказать про какой-либо магазин или услугу. Про те “главные теги” (POI) которые вы хотите.

generator:output:electricity=225 kW не запрещаются, наоборот, очень поощряются на переходном этапе, значение 225 kW будет конечно разрешено потом. Куда именно засунут 225 kW авторы строгих типизаций зависит только от них.

И всё-таки. Какую НОВУЮ задачу позволит решить нововведение? Кроме того, чтобы сломать старое?

Как мне теперь выбрать все 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.

• Используют ли они фильтры JOSM при этом
• Используют ли они валидаторы
• Используют ли они запросы Overpass API

Эти усилия можно объединить в единый репозиторий запросов.
openstreetmap.ru это называет “каталог тегов” или “точки интереса POI”. Эта возможность должна быть

• напрямую в JOSM
• напрямую в overpass, а не на странице http://wiki.openstreetmap.org/wiki/Overpass_turbo/Examples
• быть может как “включаемые-отключаемые слои” в iD, прямо сейчас их придётся строить на основе пресетов в iD. К сожалению там есть пресеты не для всех практик тегирования.

Тег 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), без них никак не обозначить два объекта мира одной точкой (любой геометрией):

1. amenity=atm
2. amenity=bank + name=Сибирьнефтьденьги

Это требует очень сильных статистиков которые очень быстро будут разрабатывать алгоритмы классификации и ранжирования в OSM. Этот подход могут позволить большие компании с штатными людьми, для хоббистов и набегающих-убегающих программистов в OSM это будет тяжело вести такую постоянно эволюционируют штуку. Мы с “жесткими” тегами не очень быстро растём (в плане сложности иерархий, у нас до сих пор всё лепят под amenity=, man_made= только потому что “их миллионы, посмотри сам”.

Понял вашу затею, вы пытаетесь упростить “говорливые теги” pub=yes и “ref:ИНН”=* до отдельных символов.

1. Это проще, реально проще вам (тому, кто знает соответствия)
2. Это тяжело учить (вы точно знаете весь *компактный *синтаксис регулярок?)
3. Это тяжело документировать без изменений всей инфраструктуры (от Taginfo до iD, JOSM, не говоря уже о программах которые используют данные), это сверх-важно для OSM. Cсылку на описание pub=yes (или amenity:pub=yes) просто исправить переправив на amenity=pub.

Да, они исключения потому что не ищут по 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=<старое значение>

Можно восстановить из истории объекта или выявить из “неймспесовой” версии объекта. Если они там есть то скопировать первое попавшееся. Потому что костыль он и есть костыль, нельзя два смысла указать одним смысловым ключом и одной геометрией без использования отношений.

Самый тупой бот справится:

1. если видишь затегировано нормально через
   amenity:<смысловой тег1>=yes/partial/main
   amenity:<смысловой тег2>=yes/partial/main

Пусть влепит amenity=<смысловой тег1> потому что он нам очень нравится и мы иконку покажем.

Еще раз: в рамках старой схемы невозможно отметить

1. amenity=atm
2. amenity=bank + description=тут точно банк

Одной геометрией, хоть бочку сделайте. Вам придётся отношения мне предлагать как “решение”.

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@ что вся аргументация сводится “нет, потому что я так сказал”, “откатываю все твои правки потому что консенсуса нет”.

Не согласен.

1. Есть чисто русские теги. Мы отлично живем с ними и обрабатываем их и улучшаем по чайной ложке.
   http://taginfo.openstreetmap.ru/keys/addr:flats - чтобы вы знали только в России мапят так детально
   http://taginfo.openstreetmap.ru/search?q=tickets%3A - tickets: теги только наши придумали

2. Изменения в API в любом случае нужно будет продвигать. Если наши продвижения не будут согласованы и подтверждаться пятизначными циферками в Taginfo - о чём речь?

Пока что да, не стоит.

Конечно люди не будут тегировать 99% объектов. Вы что. Мы ботов напишем которые автоматом поставят явные main-теги из старых shop=*.

1. Если объект был однозначный и все теги его были непротиворечивые (shop=tea, name=, opening_hours=), то по новой схеме добавит новые теги бот

2. Если объект был изначально противоречивый (amenity=atm;bank + name=Банк), то ни один человек без знаний местности не сможет перетегировать нормально такие данные

3. Человек ставит shop=cofee, shop:tea=yes (только расширяющие теги)

4. Бот его слова дополняет: 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