landuse=brownfield/construction, значения тегов name, description

Имел в виду, что в этом случае теряется информация о том, что происходит за забором - строительство, снос, реконструкция - поэтому и не стал такой пункт приводить

Поддерживаю. Строительство само по себе вещь достаточно плохо классифицируемая, но отметка на карте объектов строительства очень важно для многих пользователей. При этом описание строительства нужно не только пользователям специализированного рендера строительной области но и важно простым пользователям - легко идти и упереться в строительный забор. Вот пример одного из нестандартных но тем не менее реальных объектов строительства:

Названия объектов строительства иногда режут слух, но иногда сложно придумать что-то красивое. Далее, объекты строительства по своей сути относительно короткоживущие объекты, в отличие от зданий или скажем рек. Сегодня стройка - завтра новый объект.

I. Раз уж пошла речь о некоторых предварительных итогах, позволю себе представить на суд общественности небольшой обзор мнений, представленных до предложения о голосовании.

1а) Для быстрого и достаточно полного понимания сути объекта важна максимально сжатая информация, отражающая суть объекта. Эта информация первична и минимально необходима и должна быть отображена в name как в основном теге, несущем информацию пользователю. Прибегать к словам «строительство, реконструкция, ремонт, снос» того-то и того-то вполне уместно.
1б) Разумно внести в name ту информацию, которая очень кратко описывает то, что за забором. Хранение описания работ в name является полезным. description хорош для дополнительной информации, которая не предназначена для широкого использования, туда могут идти все детали. Необходимо быть осторожным и разделять landuse (строительный участок) и building/highway/etc (объект, который будет построен в итоге): это разные понятия.
1в) Стройплощадка не является результатом строительства. Использование названия объекта строительства для стройплощадки не является корректным. У стройки есть и наименование, и местонахождение. Место, где происходят работы, может быть обозначено словами “Строительство…”.

2а) Необходимо написать proposal на тег label, в который можно будет писать любое описание, которое редактор будет хотеть отобразить на карте. Тег name должен использоваться для названий. Описание происходящего не должно указываться в теге name.
2б) Использовать слово «строительство» в name - глупо.
2в) Если ЖК является территорией, на территорию стройки/зачистки устанавливается тег landuse=brownfield/construction, construction:landuse=residential, construction:name=Жилой комплекс “Березки”, если ЖК является зданием, на здание (на точку внутри территории стройки/зачистки) устанавливаются теги building=construction, construction=apartments, name=Жилой комплекс “Дубки”.

Примечания:
П1) Имеется мнение о некорректности правильной трактовки тега description в тезисах 1б.
П2) Если стройка ещё не началась, а только планируется и на местности никаких изменений нет, следует использовать конструкции proposed:landuse.
П3) Варианты обозначений заброшенных строек:
П3.1) Для заброшенной стройки следует использовать теги disused=yes/abandoned=yes. disused ставить, если заброшена недавно и стройка просто законсервирована, а abandoned если уже пошло разрушение объекта. Префиксы тут использовать не стоит, т.к. строительная площадка остаётся таковой несмотря на заброшенность.
П3.2) В настоящий момент при обозначении заброшенного строительства принято использовать пространство имён, а не отдельный тег. Если процесса строительства нет, техника уехала, а стройка заросла, нужно использовать не landuse=construction, а abandoned:landuse=construction + barrier=wall.
П4) Варианты использования аббревиатур в “строительных” name:
П4.1) Использование аббревиатур возможно, чтобы сокращать длинные названия.
П4.2) Использования аббревиатур следует избегать.

При желании высказывайте, пожалуйста, конкретные замечания к вышеприведённому “обзору”: упущенные аргументы, некорректно переданные слова, утверждения, отсутствующие в обсуждении, и т. д.

II. На мой взгляд, вариант 1 и вариант 2 не противоречат друг другу (допустим, “утверждён” вариант 1, запрещать использовать дополнительные теги нельзя - вариант 2 тоже будет “в ходу”; допустим, “утверждён” вариант 2, заставить всех писать все теги не получится - вариант 1 тоже будет “в ходу”) - они должны идти в голосовании одним пунктом. Либо при подсчёте голосов нужно будет суммировать поддержку варианта 1 и варианта 2.

Принципиально, вариантов, между которыми идёт выбор, три: содержательный name, name с названием строящегося объекта и пустой name на landuse=construction.

III. Полагаю, вариант 4 выглядит незаконченным, т. к. он не разъясняет, каким образом предлагается тегировать имеющуюся информацию о строительной площадке. В текущем виде, например, информации о том, что же строится, нет. Вижу, люди, поддерживающие вариант 4, пишут о том, что name должно ставиться на строящийся объект. Надо тогда пояснить, какие теги должны ставится на строящемся объекте.

IV. Мне кажется, было бы понятнее, что рекомендуют представленные варианты, если бы были приведены какие-то примеры (строительство жилого комплекса, строительство торгово-развлекательного центра, строительство дороги/газопровода и т. д.). В случае, например, переноса подземного газопровода из зоны строительства СПАД не очень ясно, как тегировать действительность в вариантах 3 и 4.

Это, по сути, подпункт варианта 3.

Теоретически, а кто сказал, что такая информация (о том, что будет построено на этой стройплощадке) обязана быть в базе? Если воспользоваться аналогией, можно сказать, что тег shop=supermarket+name=Пятерочка тоже плохой вариант, т.к. ничего не говорит об ассортименте магазина, о цвете двери на входе, о торговой площади в кв.м, об оснащенности его пожарной сигнализацией. Еще раз: не забывайте, что множество объектов не имеют имени, ничего страшного в том, что name останется пустым - нет. 4 вариант я расцениваю как полноценный, и он будет включен в голосование.

Согласен с literan. Для подробностей можно и тегами description/note/fixme= воспользоваться

description это то что никто видеть не будет, туда нужно выносить действительно детальную информацию. Это информация для специализированного рендера который пока никому не нужен.

Но хочу отметить следующее - то что конкретному участнику в ОСМ не нужно это не повод говорить что информация не нужна. Лично мне тоже кажется что в ОСМ отмечается много не нужного, но это не повод говорить что информация не нужна. Она нужна, но не Вам. Взять те же пожарные гидранты.

Возвращаясь к строительству. ОСМ имеет преимущество перед статическими картами - там отмечается текущее состояние местности, карту ОСМ часто тащат на сайты строек (типичный пример - https://www.dalpiterstroy.ru/house/shusharyi-d-331/ ) и такого рода информация пользуется спросом. Поэтому решая “как лучше” нужно исходить из того, что потребители информации ОСМ это не пара десятков завсегдатаев этого формума а гораздо более широкая масса пользователей, которые точно ничего не напишут на этом форуме как впрочем и не примут участие в голосовании, если таковое начнётся.

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

Можно было сократить до, “давайте мапить под рендер”. Мы рассматриваем как вносить информацию. А тысяча пользователей продукта должна обращаться к своему поставщику, почему он не показывает всю информацию из базы.

literan, RSergei, давайте я на примере Пятёрочки свою мысль и поясню. Как говорится, OSM - это база данных географических характеристик и объектов с географическими свойствами. Информация о наличии или отсутствии пожарной сигнализации проверяема и востребована определённым кругом людей. Нельзя просто запретить людям добавлять в базу информацию о пожарной сигнализации. Поэтому ответ “shop=supermarket + name=Пятёрочка” на вопрос “Как мне затегировать пожарную сигнализацию в Пятёрочках?” является плохим, т. к. он, по сути, запрещает вносить в базу данные: если редактор последует рекомендации, информация в базу не попадёт. Может, отвечающий хотел лишь донести мысль о том, что информацию о сигнализации не нужно загонять в name, но в итоге получился запрет. А вот ответ “shop=supermarket + name=Пятёрочка + fire_signal_system=yes/no” является корректным, т. к. указывает на то, как редактор, при наличии у него желания, может внести в базу информацию о пожарной сигнализации. При этом тот факт, что кому-то эта информация не нужна, не является проблемой. Кому-то не нужна, а кому-то очень нужна.

Возвращаемся к строительным площадкам. Попадает человек в район новостроек, где, куда ни глянь, что-нибудь строится, и хочет сориентироваться. Стройплощадка вполне себе определяется на местности (шум, гам, пыль столбом, краны, бульдозеры, крики и т. д.). Строящийся объект обычно тоже вполне может быть идентифицирован (хотя бы по информационному стенду). Давайте хотя бы на минуту допустим, что существуют люди, которым нужна информация о том, где строится ТРЦ Август, а где строится ЖК Сосновая поляна, и которые готовы такую информацию вносить в базу, чтобы помогать друг другу. Можно ли запретить внесение такой информации? Наверное, нельзя, да и не нужно (зачем?). Значит, ответ на вопрос “как затегировать строительную площадку и основную информацию о ней?” должен содержать в себе сведения о соответствующих тегах и способах их заполнения. Не должно быть голосования между вариантами “вносить информацию” и “не вносить информацию”, должны быть варианты “вносить так” и “вносить сяк”. Поэтому вариант “landuse=construction + construction:type=construction/renovation/restoration/demolition + пустой name (description по желанию)” является неполным, т. к. не разъясняет, каким образом можно обозначить, где строится ТРЦ Август, а где ЖК Сосновая Поляна. То, что это не всем интересно, не проблема.

freeExec, если информацию не вносить, то и поставщик её показать не сможет Мы обсуждаем то, как следует вносить.

Да, этот ответ будет корректным. Проблема в том, что вы предлагаете не пользоваться таким корректным способом, а все запихивать в тег name, т.е. делать так: shop=supermarket + name=магазин Пятёрочка с пожарной сигнализацией. А это некорректно.

Впрочем, я уберу в 4 варианте “по желанию”, и информация при этом варианте в обязательном порядке будет попадать в тег description (да, этот тег, также как fire_signal_system=yes/no никем не рендерится). Полагаю, это вас устроит.

Ещё нужно указать, что должно указываться в теге description: “Строительство/реконструкция/реставрация/снос [объекта]”, “[объект]” или что-то другое.

что должно указываться в теге description, описано в вики-статье, посвященной ему. [объект] там точно быть не может.

Итак, время, отведенное на обсуждение, истекло, объявляю голосование открытым:
https://wiki.openstreetmap.org/wiki/RU:%D0%92%D0%B8%D0%BA%D0%B8%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D1%8F/%D0%93%D0%BE%D0%BB%D0%BE%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F/%D0%98%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D1%81%D1%82%D1%80%D0%BE%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D1%85_%D0%BF%D0%BB%D0%BE%D1%89%D0%B0%D0%B4%D0%BE%D0%BA

Две недели есть на то, чтобы проголосовать за понравившийся вариант

По-хорошему, ещё надо было обсудить текст голосования и варианты. Например, сейчас в описании голосования говорится о том, что названий нет, хотя то, есть название или нет, как раз и является предметом обсуждения. Текущие варианты 3 и 4 друг другу не противоречат и не должны идти разными ‘кандидатами’. Ну и предложенные на момент начала голосования теги уточнения типа стройки попросту отличаются от обсуждаемых (техническая ошибка). По-нормальному, надо выработать текст описания и варианты (на странице голосования), проверить его и потом открывать голосование. Впрочем, авось, каждый сам разберётся, как что трактовать.

Неправда, в тексте сказано, что имени собственного не имеют, а не названия. Это не одно и то же.

они не противоречат друг другу, но 3 вариант предусматривает ввод нового тега (а 4 - нет), насколько я понимаю, часть участников (и, судя по текущему наполнению базы, часть немаленькая :D) считает, что указания в name на характер стройки достаточно. Поэтому я считаю, что это должны быть разные варианты.

В целом, времени на обсуждение предложенных вариантов было достаточно, прошло не менее трех недель.

Я хотел сказать, что текст страницы голосования в вики не обсуждался вовсе (насколько я вижу, голосование открылось сразу после написания текста).

По вариантам 3 и 4: неужто в случае победы варианта 3 мы заставим сторонников варианта 4 добавлять тег, который им не нравится?)

да он почти целиком взят из предыдущего голосования… не думаю, что его формулировки могут на кого-то повлиять - как мне кажется, позиции сторон давно уже определены

я лично за этим прослежу :stuck_out_tongue: Кто не будет добавлять - пойдет рисовать тундру!

Согласен, 4-й вариант вытекает из 3-его, поэтому смысла в его выделения не вижу.

  1. Без имени
  2. В имя - объект стройки
  3. В имя - происходящее на стройке
    Б) Ввод уточняющего тега происходящего на стройке.

Голосовать не буду)
Вижу стройку, рисую, знаю что будет, добавлю название.

И меня интересует вопрос, с чего для озер, по мнению Динамика, требуется добавлять “озера” а для рек и ручьев, а так же прудов… нет? Реку с ручьем можно и перепутать. Он ссылался на какое то решение, которого я чего то не нашел, если такого не было и это его придумка, то тогда проведите новое голосование по всем пунктам водных объектов.

Это следующее на повестке дня, уже вторую неделю мусолят в чатике.

+1 про озёра. С какого перепугу в случае, например, Байкала нужно включать в название “озеро”? И при этом лезть ещё и в чужие языки.