Набросал черновик, жду отзывов: получится у нас, не получится?
Если есть спорные после прочтения сформулируйте чтобы на них ответить можно было или отразить в предложении.
Proposed features/Запрет множественных значений в основных ключах
Набросал черновик, жду отзывов: получится у нас, не получится?
Если есть спорные после прочтения сформулируйте чтобы на них ответить можно было или отразить в предложении.
Proposed features/Запрет множественных значений в основных ключах
Это является проблемой перехода, как мы решим поступить на момент пока в osm будут amenity=* которые потом нужно будет выкинуть/запретить/не использовать.
Например 0,1% пользователей отмечают
name=Банкомат
amenity=bank;atm
К чему теперь относится name? Хоть один рендер такое решить может?
Именно поэтому тегируем по точке на тег.
amenity=bank
и отдельно
name=Банкомат
amenity=atm
предлагаемая схема пытается вывести из порочного круга
<бессмысленный тег (amenity, man_made)>=<смысловая часть>
путём переноса всё в key:
<бессмысленный тег (amenity, man_made)>:<смысловая часть>=yes
<бессмысленный тег (amenity, man_made)>:<смысловая часть>=yes
<бессмысленный тег (amenity, man_made)>:<смысловая часть>:name=Банкомат
amenity:bank=yes
amenity:atm=yes
amenity:atm:name=Банкомат
В новой схеме “основными” будут два (три, миллон) тегов-групп
Хотите банкоматы? amenity:atm=yes
Хотите только банки? amenity:bank=yes
Парадигма банк amenity=bank или банкомат amenity=atm всех устраивает? Я явно не один в этом.
Офигеть, я понял грандиозную задумку. Она в том, чтобы вместо «ключ=значение» сделать просто «тег». С переходной заглушкой в виде «тег=yes». Эдакий параллельный осм.
От говорливости в тегах key можно будет избавится путём ввода новой абстракции для тегов. Это очень сложное изменение в рамках 0.6 (deployed 17-21 April 2009) такого не будет никогда вам.
<смысловая коробка>
amenity:bank=yes
</смысловая коробка>
<смысловая коробка>
amenity:atm=yes
amenity:atm:name=Банкомат
</смысловая коробка>
Можно будет сократить до
<смысловая коробка>
bank=yes
</смысловая коробка>
<смысловая коробка>
atm=yes
name=Банкомат
</смысловая коробка>
bank=yes, atm=yes это строгие типы, задокументированные на вики, те самые “основные теги” которые вы ждёте.
Они никогда не случатся просто так.
Не совсем заглушка.
generator:source=gas
generator:method=combustion
generator:output:cold_water=yes
generator:output:electricity=225 kW
<семантическая коробка, типизированная>
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.
Эти усилия можно объединить в единый репозиторий запросов.
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 остался без ответа.