Вот мною было отмаплено именно согласно тому месту, которое Вы процитировали и подчеркнули: у меня не был обозначен ни shape, ни general width с помощью area=yes. Наоборот, собственно дорога (с гравийным покрытием), предназначенная для передвижения, мною была изначально замаплена как area:highway, а в area=yes попадали лишь «карманы» (тот самый «an occasional widening»), предназначенные для рекреации и хаотического перемещения, да большие площадки входов-выходов и прочих «a number of ways meet». У меня не был обозначен shape с помощью area=yes, а было отмаплено в соответствии как раз с инструкцией, которую Вы процитировали. Но Вы зачем-то решили это исправлять.

Человек в самом деле может прийти туда и заявить о преступлении. Об этом в явном виде написано в Законе "О полиции" (ФЗ №3 от 07.02.2011):
ст.27 п.2.2: "Сотрудник полиции независимо от замещаемой должности, места нахождения и времени суток обязан: в случае обращения к нему гражданина с заявлением о преступлении, об административном правонарушении, о происшествии либо в случае выявления преступления, административного правонарушения, происшествия принять меры по спасению гражданина, предотвращению и (или) пресечению преступления, административного правонарушения, задержанию лиц, подозреваемых в их совершении, по охране места совершения преступления, административного правонарушения, места происшествия и сообщить об этом в ближайший территориальный орган или подразделение полиции."

Поэтому размечать подобные посты охраны как amenity=police — это не вводить в заблуждение.
Ровно наоборот, введением в заблуждение было бы не размечать их так.

Или тогда что, с приёмной ГУ МВД по МО тоже снимаем тег amenity=police на основании того, что там, по всей видимости, не происходит на постоянной и систематической основе "suspects and evidence are collected and processed"?

Поскольку я интересовался не тем, как тегировать британских копов, а тем, как тегировать российских ментов, то и смотрел я, очевидно, здесь: osm.wiki/RU:Tag:amenity%3Dpolice

Если Вы настаиваете, что в постах охраны всё же сидят британские копы (хотя мой личный опыт свидетельствует об обратном), то как Вы предлагаете их тегировать?

Спасибо. Исправил также в другом месте аналогичный пункт выдачи и добавил на этот тег ссылку в wiki.

Там написано: «объект, который служит для размещения сотрудников полиции».

Насколько мне известно, посольства и всякие подобные представительские учреждения охраняются именно силами полиции. Они размещены в специальных строениях, основное предназначение которых — резмещать сотрудников полиции внутри себя.

Что не так?

А поясните, плз, зачем Вы изменили у way/671268030 area=yes на area:highway ?

В вики разница проведена вполне чётко: area:highway=*#Differentiation_area:highway_vs._area.3Dyes_on_a_highway
=== цитата ===
area:highway=* had been proposed to describe the non-routable, detailed shape of a (typically linear) highway. The tag requires the linear, routable direction of the highway mapped in addition as lines with highway=*.

area=yes on a highway=* describes a routable highway area on which the dedicated traffic can route omnidirectionally, i.e. from any point along the edge to any other. This is typical for pedestrian areas, or service areas where vehicles drive without prescribed lanes. There are strong voices that argue that routing engines should consider those omnidirectional objects in addition to nodes+edges in classical graph theory; thus no linear highway lines would be required within.
=== конец цитаты ===

Руководствуясь ровно этой логикой, я обозначил как area:highway только собственно гравийную дорожку, которая предполагается для передвижения. Мощёные плиткой «карманы» и прочие области вокруг представляют из себя «рекреацию» с лавочками: там люди никуда не идут, а сидят на лавочках, общаются, что-то поедают, дети пускают мыльные пузыри (на днях наблюдал и такое), передвижения хаотичны (тот самый "omnidirectional").

В любом случае, тег area:highway требует наличия внутри себя highway=*, который и задал бы направление возможного движения, но Вы его добавлять не стали.

Помимо прочего, наличие нескольких area:highway, идущих параллельно друг с другом, искажает реальность, поскольку в реальности там нету разных параллельных друг другу дорожек. Если же area:highway сделать один большой, всё в себя включающий, то становится непонятно как отражать разные типы покрытия, ведь, насколько я понимаю, тег surface носит уточняющий, а не самостоятельный характер. (Впрочем, area:highway тоже носит дополнительный уточняющий характер, как я понимаю, а не самостоятельный, поскольку направления не задаёт)

Как быть?

Спасибо. Поправил.

Спасибо.
Аналогично выправил то место у Покровских ворот, где велодорожка заканчивается.

Спасибо, я в курсе.
Обозначенные мною мачты не несут функцию освещения улицы (дорожного полотна), а выполняют функцию цветного декоративного освещения деревьев и неба, распугивания птиц по ночам, и услады эстетического чувства прогуливающихся граждан. То, что у них небольшой размер — ещё не превращает их в фонари уличного освещения.

Вы предлагаете, «пользоваться тем, что есть», но тега division нету, а тег department используется для разметки учреждений высшего образования (я уже упоминал об этом).
У меня нет информации о том, что это именно «отделы» с точки зрения внутреннего административного деления в Почте России. То, что мне известно — что это разные помещения, с разной функциональной нагрузкой, с разными входами, попасть в которые посетитель может только через улицу. При этом все они формально относятся к одному почтовому отделению.
К одному отделению их можно отнести административно, а не территориально. Почему Вы предлагаете именно мультиполигон?

Если очень хочется, чтобы был один элемент на отделение в целом, то единственный вариант я вижу — relation типа site, в который собрать все эти точки.

Отделение почтовой связи — одно. Однако отправка и получение посылок возможна лишь в одном помещении, куда посетитель может добраться только через улицу, обслуживание юрлиц — в другом помещении (даже в двух других: в одном из них по договорам), отдел доставки — в третьем помещении, обычные письма — в четвёртом. Они не сообщаются друг с другом неслужебными помещениями (а в некоторых случаях даже служебными тоже не сообщаются). Для посетителя это разные входы с улицы как если бы они были разнесены вообще по разным зданиям.

Я ориентировался на то, как этот вопрос представлен в wiki: osm.wiki/RU:Tag:amenity%3Dpost_office, хотя лично мне и не кажется такой подход оптимальным.
По предложенной схеме, по сути единственное, что можно варьировать, оставаясь в её рамках, это содержание тега official_name. Именно в него я всё и прописал (идентично тому как они сами себя называют на табличках перед каждым входом). Конкретно mapnik, может, этого и не рендерит — но ведь это же не повод начинать «мапить под рендер»?
Максима «одна фича — один тег», безусловно, прекрасна, но это именно максима, с которой, к сожалению, иногда расходится устоявшаяся практика. Я не смог найти информацию о сложившейся практике использования тега division — судя по taginfo он вообще не используется, за исключением пары десятков случаев на всю планету. department, судя по wiki и taginfo, в основном используется в контексте университетов, при разметке кафедр и отделений на факультетах. Что, в принципе, довольно логично.
Чем плох тег official_name?

Ровно по этой схеме у меня всё и отрисовано. Но, судя по тому, что Вы не удосужились потратить время и посмотреть (но удосужились потратить время и написать), то, пожалуй, тратить Ваше время на продолжение коммуникации действительно не стоит.

Да, еще по поводу «дублирования» тегов. Если у нас есть уже какая-то сложившаяся практика (подтверждённая формальным голосованием), и дополнительно к этому есть сыроватый proposal (в данном случае касающий всего, что относится к indoor и внешнему виду 3d-моделей зданий).
Я исхожу из того, что мы не можем убирать информацию из «стабильных» тегов ради переноса её в «proposal» — потому что proposal могут иметь лишь факультативный смысл. Но, с другой стороны, если мы не будем размещать часть инфы в «proposal»-тегах — мы не сможем оценить их целесообразность.
Вы полагаете такую позицию ошибочоной?

Я понял Вашу мысль про level на точке и согласен, что у меня не вполне логично и эстетично — я буду переделывать.
Но всё же хотел бы подчеркнуть, что в этом нет ничего криминального. Если у нас сложное архитектурное решение, при котором не все углы идут ортогонально земле, то контуры здания не просто «могут», но они даже «должны» изменяться от этажа к этажу.
Я согласен с Вашей позицией по конкретно этому углу здания, но не уверен, что нужно именно снимать тег level, а не добавлять тег repeat_on, раз уж так получилось, что в этой точке угол здания оказался перпендикулярен земле.

Спасибо за пример с Охотным рядом! Там, как я понял, не всё идеально, но мне определённо есть чему поучиться.
Постараюсь всё это учесть.

Теги «и на здании, и на территории», потому что имеют разный смысл. Есть «школа» как организация и «школа» как здание, в котором непосредственно проходит учебный процесс. Это интернат: многие здания служат для проживания учащихся и учителей, поэтому эта разница видна чётче, чем в обычной районной школе.
К слову, имя собственное тут состоит из двух слов: «Школа „Летово“»

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

Что же до углов здания, то периметр (который входит как outline в отношение type:building — это заготовка, чтобы в будущем отразить переменную этажность здания, пока это ещё не сделано) — вот он, периметр: way/658408612
Он не содержит никаких тегов level вообще.

Тег с именем "level=0" — это опечатка, конечно же (просто случайно вставилось из буфера). Я её вовремя заметил и, мне казалось, исправил-вычистил всюду, да, видно, всё же проглядел. Спасибо. Это должен был быть тег description (из-за отсутствия однозначно понятного amenity). Что касается содержимого этого description, то дословно так они обозначены на большом плане, нанесённом непосредственно на стену школы, именно так они и используются. level_name — спасибо, что обратили внимание. Похоже, я некритично заимствовал, разглядывая чужие работы: https://taginfo.openstreetmap.org/keys/level_name По логике это лучше назвать level:name,наверное, — это название этажа.
Поскольку здание строилось не по типовому, а по индивидуальному проекту на конкурсной основе, там отсутствует, вообще говоря, строгая этажность (и, более того, некоторые стены могут перемещаться в пространстве, позволяя реорганизовывать пространство под конкретные задачи). Поэтому вместо плана разных этажей на практике используется просто "план на отметке 0.000", "план на отметке +4.200", "план на отметке +8.400". (Вероятно, это соответствует высоте.)

Спасибо, что обратили внимание. Это мой первый опыт с индорами — внутренней планировкой здания. Я ориентировался вот на эту вики в основном: osm.wiki/Simple_Indoor_Tagging
Честно говоря, у меня даже не возникло сомнений, что я понял что-то неправильно (иначе б спросил бы на форуме). Тем более хорошо, что Вы это заметили. Но мне пока до сих пор непонятно в чём тут мои ошибки.

level на каждой точке получился, видимо, по невнимательности: я массово тегировал кучу объектов разом, и, помимо линий, тупо захватил и точки.
Но какой с этого может быть вред? Ведь в общем случае точки точно так же находятся на своём этаже здания и в общем случае могут не иметь аналогов на других этажах. Так что они вполне правомерно могут иметь свой level. Я не прав?

Русскоязычных тегов (в смысле, у которых имя тега кириллицей задано) быть не должно, это однозначно опечатка и её необходимо исправить. Только можно ткнуть меня в конкретное место, плз, — не могу найти.