Так вот как раз сейчас, структура в приницпе подходит для обработки. И в как автором темы и предлагается поменять стуктуры данных, для решения какой-то конкретной задачи (чтобы было удобнее).
Не очень понял ниже приведённые пример в контексте стуктуры/хранения данных и их обработки, но попробую прокомментировать.
Конкретно тут проблема в том, что разные данные пытаюся хранить как одну сущность. А данных тут две: дорога, как нечто по чему можно ехать и дорога, как направление движения. По хорошему, это должны быть разные объекты. Тогда и отрисовано это было бы красиво и не надо было бы возиться с отношениями, для запрета поворота и тому подобных вещей. То, что в osm эти две вещи объединены в одну - очень большой недостаток.
Так это просто нет данных. Могу предположить, что такие данные просто сложно запихнуть в стуктуру osm, этим и можно объяснить их отсутствие.
Да вроде ничего не меняли. Или я упустил мысль.
Периодически, мне попадаются вещи типа как мапить магазин “Свет” (light или lights) или что-то типа поменявшегося обозначения шиномонтажа… Но я бы не сказал, что тут есть какие-то принципиальные проблемы - в любом адекватном инструментарии это замена одной строки на другую или просто поддержка и того и другого. С другой стороны, я даже в таких изменениях не вижу большого смысла, в конце коцов, есть решим, что shop=cdtn и есть магазин “Свет”, то вполне можно с этим согласиться.
Набросал черновик, жду отзывов: получится у нас, не получится?
Если есть спорные после прочтения сформулируйте чтобы на них ответить можно было или отразить в предложении.
Это является проблемой перехода, как мы решим поступить на момент пока в 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=Банкомат
Офигеть, я понял грандиозную задумку. Она в том, чтобы вместо «ключ=значение» сделать просто «тег». С переходной заглушкой в виде «тег=yes». Эдакий параллельный осм.
От говорливости в тегах key можно будет избавится путём ввода новой абстракции для тегов. Это очень сложное изменение в рамках 0.6 (deployed 17-21 April 2009) такого не будет никогда вам.
После очень сильных изменений в бекенде и во всех приложениях
<семантическая коробка, типизированная>
generator=yes - строгий тип, задокументирован на вики
source=gas
method=combustion
output:cold_water=yes - вложенность коробок-типов тоже можно учесть, их тоже можно строго типизироваться и задокументировать, никаких угадаек по Taginfo и вопросов "как обозначать X"
output:electricity=225 kW
</семантическая коробка, типизированная>
В предложении речь не только о 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 авторы строгих типизаций зависит только от них.
Пф. Указываем тег-костыль amenity=yes на время перескакивания через знак равно в key=value.
Пользователи которые считают что регулярка amenity=* хоть что-то значит, остаются в прошлом с их нерешаемыми проблемами двойственности объектов в рамках псведо-смысловых amenity= (amenity не значит ничего! сюрприз!)*.
То есть предлагается ввести группы и иерархию тэгов?
Тогда предлагаю перепрыгнуть этот этап и сразу перейти к языку разметки - описательный текст в произвольной форме в котором встроены ключевые слова.
Примерно так:
#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”. Эта возможность должна быть
быть может как “включаемые-отключаемые слои” в 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), без них никак не обозначить два объекта мира одной точкой (любой геометрией):
amenity=atm
amenity=bank + name=Сибирьнефтьденьги
Это требует очень сильных статистиков которые очень быстро будут разрабатывать алгоритмы классификации и ранжирования в OSM. Этот подход могут позволить большие компании с штатными людьми, для хоббистов и набегающих-убегающих программистов в OSM это будет тяжело вести такую постоянно эволюционируют штуку. Мы с “жесткими” тегами не очень быстро растём (в плане сложности иерархий, у нас до сих пор всё лепят под amenity=, man_made= только потому что “их миллионы, посмотри сам”.
Понял вашу затею, вы пытаетесь упростить “говорливые теги” pub=yes и “ref:ИНН”=* до отдельных символов.
Это проще, реально проще вам (тому, кто знает соответствия)
Это тяжело учить (вы точно знаете весь *компактный *синтаксис регулярок?)
Это тяжело документировать без изменений всей инфраструктуры (от Taginfo до iD, JOSM, не говоря уже о программах которые используют данные), это сверх-важно для OSM. Cсылку на описание pub=yes (или amenity:pub=yes) просто исправить переправив на amenity=pub.
Да, они исключения потому что не ищут по 11значным цифрам телефона и конкретному значению напряжения.
Нет, ИНН там просто так написано, без разметки (сейчас оно лежит в comment). pub не знаю откуда вы взяли, там магазины.
ИНН с разметкой было бы как-то так:
#ИНН: 7735108290
Кому не надо, может не учить.
Должен быть визуальный редактор, прячущий разметку в графическое оформление (примерно как HTML отображается), в котором можно выделить часть текста и сказать “А это название”, потом другой текст - “А это телефон”, а потом задать тип объекта - “Это магазин”. Ну и само должно догадываться в некоторых случаях и предлагать (+7… - это вы телефон ввели?)
Ну а кому нужна тонкая настройка - открывает обычный редактор и правит в кодах.