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

Так вот как раз сейчас, структура в приницпе подходит для обработки. И в как автором темы и предлагается поменять стуктуры данных, для решения какой-то конкретной задачи (чтобы было удобнее).

Не очень понял ниже приведённые пример в контексте стуктуры/хранения данных и их обработки, но попробую прокомментировать.

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

Так это просто нет данных. Могу предположить, что такие данные просто сложно запихнуть в стуктуру osm, этим и можно объяснить их отсутствие.

Да вроде ничего не меняли. Или я упустил мысль.

Периодически, мне попадаются вещи типа как мапить магазин “Свет” (light или lights) или что-то типа поменявшегося обозначения шиномонтажа… Но я бы не сказал, что тут есть какие-то принципиальные проблемы - в любом адекватном инструментарии это замена одной строки на другую или просто поддержка и того и другого. С другой стороны, я даже в таких изменениях не вижу большого смысла, в конце коцов, есть решим, что shop=cdtn и есть магазин “Свет”, то вполне можно с этим согласиться.

Набросал черновик, жду отзывов: получится у нас, не получится?
Если есть спорные после прочтения сформулируйте чтобы на них ответить можно было или отразить в предложении.

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 это строгие типы, задокументированные на вики, те самые “основные теги” которые вы ждёте.

Они никогда не случатся просто так.

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

  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» или даже придумает «тег=что-то» и станет требовать поддержки в рендере :slight_smile:

В предложении речь не только о 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 не значит ничего! сюрприз!)*.

Не пользователю, а программе. пользователь вобще тегов не видит. :slight_smile:
Что-бы выбрать иконку, к примеру. Да и вообще, узнать сам факт, что это 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… - это вы телефон ввели?)
Ну а кому нужна тонкая настройка - открывает обычный редактор и правит в кодах.