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

Я за третий вариант.

Насколько понимаю идею (construction|disused|…):=*, при удалении префикса из ключей должны получаться актуальные теги. Поэтому нельзя назвать тег “construction:type” т.к. после завершения работ получим неправильный “type=construction/…”, лучше construction_type

В целом, я за 4 - name ставим на строящийся объект.
Правда и 3 иногда допустим, например, если строится парк аттракционов.

Судя по вики construction=mall должен быть у здания, а у прилегающей территории - construction=retail + amenity=marketplace

Продолжу пропаганду отлично работающего на населённых пунктах (и нигде за пределами России не используемого) official_status. official_status=ru:Торгово-развлекательный комплекс ))

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

предлагаю обсуждать в отдельной теме, эта таки о стройплощадках

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

выше были люди, аргументированно высказывавшиеся за этот пункт. Он будет включен в голосование.

Причём тут что будет потом, вы что не разу не видели как одноэтажный жилой дом превращался в трехэтажный торговый центр.

То есть этот пункт о том, что даже если у будущего объекта уже есть имя, то писать его в любом случае не надо? Пока идёт стройка никакого нэйма?

насколько я понял аргументацию этой стороны - да, это объект (территория, занятая строительством), который не имеет названия (имени собственного) а имеет лишь описание. Пусть меня поправят:)

Забыли самый простой пункт
landuse=construction + name=[объект]

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

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

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

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: “Строительство/реконструкция/реставрация/снос [объекта]”, “[объект]” или что-то другое.