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

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

Примерно так:


#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

Насколько я помню 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
или возможность фотографироваться барышням на столе :smiley: :
sport:billiards:pool:photo_on_table:female=yes
засовывать всё это в sport=billiards через точку запятой, имхо, неправильно :roll_eyes:

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

А вот это отличный пример “плохой практики”, ибо из-за того что нам лень оформлять и принимать пропозалы, плодятся региональные теги, что проекту (а он напоминаю международный) ну никак на пользу не идёт. Вы же пытаетесь из этого сделать традицию, чего я поддерживать не собираюсь, а даже скорее буду сильно против.

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

А вот это называется ставить телегу вперёд лошади. Попытка принять схему на основании “использования де факто”, вместо “скучного” процесса написания/обсуждения/принятия пропозала, это тоже пример “плохой практики”. Надеюсь, раскрывать почему это так нет необходимости.

Я считаю, что не только пока что, но и в последующем не стоит. Ибо ради 1% заставлять остальные 99% использовать усложнённую схему не есть правильно. Кроме того, подход описанный мной, позволит убрать значительную долю критики (справедливой, стоит заметить) связанный с использованием shop:* тегов без материнского shop=*, при этом не потеряв ничего в гибкости, и даже добавив немного в лаконичности.

А вот это уже откровенно попахивает NIH синдромом. На кой чёрт заводить ботов и принуждать пользователей использовать усложнённую схему, когда для 99% случаев достаточно примитивных shop=*, которые отлично работают чуть ли не с момента основания проекта?

Это еще что. Есть особо одарённые личности считающие что править вики не нужно кроме пяти-десяти страниц самих авторов, а то и вовсе обновлять их не нужно.

Никто не пытается сделать плохой традиции, просто проползал нужно составлять на английском языке. Это кроме описания тега на странице тега. Конечно же это никогда не произойдёт если находятся умники вещающие в ключе “кто правит вики - тот идиот”.

Да, я тут подумал еще раз. Временно писать бота чтобы он внёс двойную схему точно не стоит для 99,9% объектов. Это очень много работы мне, лучше выбросить API 0.6 и импортировать данные потом полу-вручную чем две схемы одновременно видеть в OSM.

Ограничение на <одинсмысловойключ>=<однозначение> настолько идиотское что даже слов нет. В XML нет таких жёстких ограничений:

Иванов авто Ford Mustang Т.е. в OSM API 0.6 такое написать не получится даже с использованием говорливых неймспейсов (предлагаемой схемы): shop:cardealer:cars:car=Ford shop:cardealer:cars:car=Mustang

В рамках API 0.6 придётся выдумывать костыли addrN, carN:
shop:cardealer:cars:car=Ford
shop:cardealer:cars:car2=Mustang

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

Высказывание про “сразу пропустить этап XML” я теперь понимаю более-менее:

Чтобы такую простую схему в OSM ввести нужно кому-то гвоздь в лоб забить обязательно.

Обязательно находятся умники считающие 255 символов в value достаточно.
Обязательно находятся умники считающие 255 символов в key достаточно.
Обязательно находятся умники считающие только один раз встречающегося key достаточно.

Описание схемы я пока спрячу, нужно будет больше описать из чего всё происходит, почему это реально надо. Какие альтернативы есть (XML, текст с разметкой) и как сложно будет на них переходить с парадигмы 0.6 (набор key=value, с key значением которое встретится только один раз).

Вам еще не надоело? Добавьте ссылку на голосовалку в первый пост (ибо искать в тексте ее то еще действо) и успокойтесь, хотя бы до результатов голосования.

Именно из этого я и исходил когда предлагал передвинуть смысловую часть в key.

Никаких иероглифов в key не может появится если понять предлагаемые изменения, а не вспоминать о каких-то регулярках.

Новая схема не решает вопрос “сколько значений у этого ключа” из-за ограниченности API и парадигмы <строка>=<строка> в целом

Т.е. придётся парсить неймпейс sport:billiards:

Вместо этого можно было бы (с нормальным API 0.8):

sport:billiards это задокументированный на вики ключ
pool и snooker это значения на странице ключа sport:billiards:type в вики

Кто-то будет мапить только sport:billiards=yes, а любители бильярда будут смотреть страницу sport:billiards:type.

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

Не самое красивое решение, но это единственный вариант в рамках <строка>=<строка>.

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


    sport:billiards=yes
    sport:billiards:type = [pool, snooker]
    sport:billiards:table_size = [pool:7ft, pool:8ft, snooker:9ft, snooker:12ft]

либо


sport:billiards:table_size = [pool:(7ft, 8ft), snooker:(9ft, 12ft)]

или ещё как-то?