Смотрите, OSM - это база данных, вопросы представления данных в ней отделены от вопросов визуализации этих данных. В данный момент идёт обсуждение собственно тега, а не его отображения.
Впрочем, я думаю, что с отображением стилем osm-carto (“mapnik”) разумно поступить так же, как и в случае boundary=national_park - сплошная заливка/штриховка на мелких масштабах и отображение только границ на крупных: тогда детали не будут теряться.
Это упомянуто на странице в вики.
Какое значение access должно подразумеваться по умолчанию? Для погразоны РФ это access=permit, для других стран может быть другое значение (я подозреваю, что у финской погранзоны access=no, т.к. она реально узкая - несколько сотен метров).
Нет смысла, разве что есть имя собственное, вроде “Демилитаризованная зона Кореи” или “Буферная зона ООН на Кипре, сектор 1” (хотя и это, наверно, должно быть в ref). Т.е. имеет смыл, если название отлично от “Пограничная зона области X госдарства Y”, т.к. это информация ясна из тегов и физического расположения.
Это упомянуто на странице в вики.
В предлагаемой схеме boundary=border_zone должен быть только на площадных объектах, т.е. на линиях, входящих в состав мультиполигона, не должно быть этого тэга.
Дублировать в какой-либо базе что-либо нельзя нигде, т.к. это приводит к сложностям в поддержании актуальности (в одном месте исправили, а в другом забыли). Данные должны только в одном месте (элементе в нашем случае), свойства остальных элементов должны выводиться благодаря их связи с исходным элементом. Т.е. информация о том, что какая-то линия является границей погранзоны, должна быть получена из того, что она входит в полигон с boundary=border_zone, а не из её собственных (дублирующих) тэгов.
Эти теги уже упомянуты на страничке proposal’а в wiki. Можно для русской версии потом добавить, что ссылка должна быть на pravo.gov.ru, как на официальный(?) портал с НПА.
Этот вопрос отрогонален собственно обсужению тега. Можно делать, можно не делать. Чисто ради википедии я бы не стал, наверно - для иллюстарции к статье больше бы наверно подошла модификация стиля на https://maps.wikimedia.org/ Впрочем, тут надо думать.
Поддержу. Авторы схем тегов при их написании и продвижении всегда полны энтузиазма и слёту замахиваются на высосанные из пальца гиперсложные задачи (которые позволит решать их пропозал), при этом напрочь забывая о том, как бы суметь решать задачи более простые и приземлённые. В итоге имеем в базе тысячи объектов, которые невозможно использовать ни для того, ни для другого - но и переделать нельзя, потому что массовые правки, направленные на “облегчение” информации, не пройдут.
Результат - за долгие годы OSM уже давно и безнадёжно запороли для решения многих задач, для которых он реально мог бы быть использован при изначально ином подходе. Наглядный пример - навертели схему для железнодорожной инфраструктуры ради грандиозной цели “чтобы на данных OSM можно было сделать симулятор реальной ЖД”, когда на каждый светофор и путевой знак надо навесить десяток-полтора тегов, да ещё и сами точки ставить по-мудрёному. А потом оказалось, что если ЖД-пути представляют из себя ломаные линии (а других в OSM не бывает), обклацанные на глаз по спутниковому снимку, то на такой геометрии никакой ЖД-симулятор нельзя соорудить в принципе.
Моя задача, если что - получить погранзону (ну и 5км зону в идеале тоже) в навигаторе и на каком-нибудь онлайн-слое для удобства прокладывания маршрута. По-моему более простую задачу сложно представить.
Решению каких задач может помешать предлагаемая простая (проще вроде некуда) схема и как её можно улучшить?
Будем рассматривать идеальный вариант, что границы внесены во всех регионах (на самом деле нет, если только Зверев опять конкурс объявит, как с погранпереходами).
В результате, на мелких масштабах будем иметь просто тупо широкую полосу вдоль всей границы. Железный Занавес. Очень нужно и информативно. А на крупных границы будет совпадать с уже имеющимися, то есть одна из границ будет перекрывать другую, в зависимости от настроек рендера. Уже реально надеюсь, что пропозал пустят по бороде, а если и примут, на главную этот хлам не добавят.
Вот опять за другие страны беспокойство. В таких случаях говорят, замахнулся на рубль, а ударил на копейку.
Тебе нет, а мне есть. Зачем на линии границы тогда нейм стоит, если и так всё понятно. Нужно не “упоминать” на странице, а чётко писать.
А это ты ловко придумал, я даже сразу и не понял. То есть линия это или полигон уже не обсуждается. Может тогда и пропозал сразу принять, единогласно, зачем продолжать обсуждение, если уже всё решено.
Я зачем примеры привожу по уже имеющейся информации? На админграницах продублировано, а удалить нельзя, вой поднимется, массовая, автоматическая правка, откат, в бан! А почему? Потому что тебе лень прописать, чётко, по военному, раз уж про границы речь идёт. Про актуальность, поддержку и т.п. это общий жупел. Для этого валидаторы есть и вахтёры. “Должны брать”. Вон, выше уже смеются, проект, мол, любительский, а значит никто здесь никому не должен. Попытались убрать дублирование из адресов, пролетели. Так что можешь не дублировать, не тратить силы, я продублирую, мне не сложно. Не запрещено, значит разрешено.
Я не про упомянуты, написал, а про обязательность.
И с чего ты решил, что в соурс должна быть ссылка, тем более на какой-то определённый сайт? Ерунду написал какую-то. Я текст с Консультанта взял, с какой радости я буду в соурс ссылку какую-то левую ставить?
Точно, лучшее решение проблемы, это посмеяться над ней. Проект любительский, поэтому к мнению профессионалов, если они вдруг по недоразумению попадают на ОСМ, если и прислушиваться, то только с целью сделать всё наоборот. Проект должен выглядеть максимально убого, чтобы ни у кого сомнений не возникало, что он любительский.
Про ЖД упомянуто, хороший пример. Стрелки отметить можно и знаки, а вокзал нельзя. Вот это поворот! Нет в ОСМ тега для вокзала. Ну неприметная же вещь, только причастные про них знают, вот и забыли. А нет, это у меня из головы вылетело. Проект же любительский, значит вокзалов специально нет.
Задача уже решается, на раз-два. При помощи Оверпаса или Джосма скачивается линия и сохраняется как трек. И не надо ждать, когда поддержку добавят (нет) в Османд или ещё куда.
С этим вроде нет проблем. В англ. ОСМ постоянно старые теги отправляют в deprecated и вводят новые более лаконичные. Более того старые теги автоматически и массово заменяются на новые.
Нужно только оформить согласно правилам.
нет. я понимаю, это сложно принять. лучше не писать сразу, а свыкнуться с этим знанием, обмозговать.
ПС. ты правда думал, что я про building=train_station не знал?
Абсолютно не так. Более того, везде жирным по белому подчёркивается, что никакой принятый пропозал и никакая статья в вики не может служить обоснованием автоматической замены “нерекомендуемого” тега на “рекомендуемый”. Легко может быть, что схему тегирования утвердили уже в третьем варианте, а 90% затрагиваемых объектов в базе до сих обозначены в соответствии с первым, и ситуация не меняется годами.
Смотрите, крупный масштаб - это большой zoom-level, т.е. детали хорошо видны, соответственно чтобы их не закрывать, на этом уровне нужно отображение только границ погранзоны. Средний масштаб - zoom-level от 8 до 12, там детали не видны, поэтому можно добавить какую-нибудь штриховку/фоновую заливку. На мелких масштабах можно не отображать совсем.
Можете зайти на osm.org и посмотреть, как там отображаются национальные парки - примерно по этой схеме.
Смотрите, OSM - международный проект, значение тэгов одинаково везде, поэтому нужно думать о применимости для всех стран.
Смотрите, я поясню, как это работает - создаётся страничка-proposal, которая описывает предлагаемый новый тэг. Далее идёт обсуждение с сообществом, в процессе которого описание дорабатывается. Потом, после того, как все замечания учтены, идёт период голосования, по результатам которого тэг принимается (или отвергается).
Процесс описан в вики.
Дублировать не нужно, это и глупо и неудобно. Напишите, что конкретно вы пытались сделать, дайте ссылку на пакет изменений. Возможно вы в чём-то просто не разобрались.
Смотрите, вручную можно много чего решить. С такой логикой можно было бы не вносить дороги/тропинки в OSM - делать набор треков для персонального использования и никуда их не выкладывать. Суть в том, что если какой-то элемент карты нужен хотя бы нескольким людям (а путешествующих в пределах погранзон довольно много), то его имеет смысл добавить в OSM для того, чтобы все могли пользоваться.
На какие элементы предлагается добавлять тэг access?
Я хочу, например, проложить маршрут через лес (не в смысле автоматической маршрутизации типа osrm) по азимуту - ибо нет в конкретном месте дороги/тропы. Я желаю знать, не встречусь ли я случайно с зелёными человечками, которые иногда всё-таки патрулируют эти погранзоны.
Вот Карелия для примера - не ставить же access= на весь лес, входящий в эту зону…
Правду написал, просто она неудобная. Такую правду проще назвать неправдой, потому что если её понять и принять, придётся с ней жить, так как исправить положение будет сложно.
Обсуждения я не вижу, ты цитируешь мои сообщения, но не читаешь их, даёшь ответ не на то, что в них написано. Теперь ещё и к оскорблениям перешёл. Впрочем, замечания я написал, так что на этом всё. Хоть меня эта тема и затрагивает непосредственно, не думаю, что что-то ухудшится.
ну да, ну да, building=train_station по вики - для зданий вокзалов и больше ни для чего. Вокзал - здание, являющееся пассажирским терминалом железнодорожной станции.
Именно поэтому “вокзал отметить нельзя”, ОСМ плохой, “меня все оскорбляют”.
Голосуем за сам тег boundary=border_zone для собственно пограничной зоны. Всё остальное (вероятное отображение, сопутствующие теги и пр.) - в качестве примера сейчас. Т.е., например, детализирующий тег border_zone=* будет отдельным proposal’ом скорее всего.