literan,
как предостережение покатит, но как совет - не уверен. Всё же cuisine - один из немногих тегов, где перечисление нескольких значений действительно оправдано, притом что способ сделать это через точку с запятой - самый популярный для этого тега. Так советует поступать страничка Key:cuisine, а значения вида "donut;coffee_shop" исчисляются тысячами в taginfo. К слову, Maps.me парсит и отображает список кухонь на страничке POI, а редактор POI вроде умел задавать несколько значений.

Добрый день. Похоже, StreetComplete неверно устанавливает теги для максимальной скорости. На странице тега maxspeed:type явно указано, что он поясняет тег maxspeed и, стало быть, без него не должен употребляться.

landuse=commercial wiki: "Such area may consist of offices, ..., car repair stations..."
Вообще я до этого момента считал ритейл частным случаем коммерции, но, видимо, это не так. Можно тут поставить retail как основное назначение.

Там при каждом автосалоне есть автосервис, поэтому я так сделал, но не настаиваю.

Приветствую новых мапперов в Долгопрудном!
У проекта OSM если своя wiki, где описаны теги и рекомендации по рисованию объектов. Укажу Вам на две неточности:
1) На странице parking=* сказано, что parking=lane непонятно, что означает, и лучше этот тег не использовать. Здесь подошло бы parking=surface.
2) amenity=parking
Тут сказано, что capacity - это полное кол-во парковочных мест, включая места для инвалидов. Комбинация тегов capacity=10+capacity:disabled=10 означает, что парковка только для инвалидов.

Первое, на что стоит обратить внимание - это подпись "updated a month ago" в строке атрибуции, так что если ваши правки более свежие, они могли ещё не проявиться. Однако я посмотрел ещё несколько частей зданий с тегом building:min_level - ни одна не отображается правильно. Так что проблема рендера.

That relation was a pile of ways not conforming the definition of a valid multipolygon. Look "Valid Multipolygon conditions" section of the Relation:multipolygon wiki article, in particular "Graphical examples of OGC validity" link.
A building relation should contain several parts and an outline each of which is an area (closed way or multipolygon), while a multipolygon often contains members that are unclosed ways.
Thus, the idea of converting "outer" role to "part" role of any (valid or invalid) multipolygon to make a building relation from multipolygon relation is initially incorrect.

Чисто технически тут всё ок. https://osmbuildings.org/?lat=55.88773&lon=37.45582&zoom=18.4&tilt=45&rotation=-46

Добрый день.
Действительно ли часть здания начинается с 3-го этажа? building:min_level=2 означает
building:min_level=*

Jeff Underwood,
no, building relation is not similar to multipolygon relation, neither it's a replacement for the latter. Mechanical replacement of type=multipolygon tag with type=building and 'outer' member roles with 'part' almost never gives you a correct building relation. I hope you carefully read Relation:building and Relation:multipolygon OSM wiki articles before further work on complex buildings.

-Alexey

54 000 (45%) of place=island and 270 000 (80%) of place=islet objects have no name tag. Are you certain to start struggling against the "place" tag on them?
"Written in wiki" and "used in practice" are two powerful arguments that diverge sometimes. Bringing them into complience in important aspects is a matter of discussion. Renderes and other applications may rely on the "place" tag. Algorithmically, to ignore "place=island" tag on unnamed features is too much simplier than to dirive that a closed way is an island.
The wiki page history reveals that originally place tag was intended for populated places only - as a billet to put the name and population tags.

Hello.
Thank you for fixing coastline intersection. But why have you removed place=island tags?

Здравствуйте.
Не надо дублировать тег amenity=school на точке и на здании, а то получается, что тут две школы. Ещё хуже, что после ваших правок со здания пропадает тег building, отчего здание перестанет отображаться на картах совсем или правильно. Вероятно, это поведение редактора iD, но оно в любом случае деструктивное, и я бы попросил тщательнее следить за этим.
Также дублирование адреса на здании и на точке внутри неё - лишнее. Адрес - это свойство здания, а не организаций внутри.

Здравствуйте!
Вы знаете о смещении спутниковых снимков? Здания могут казаться "не на своём месте", если подложка не точно привязана к земной поверхности. Перед рисованием желательно выровнять подложку по трекам, такая возможность есть и в редакторе iD.

С уважением, Алексей

Добрый день! Правильно ставить префикс жизненного цикла в начало: "was:building", а не "building:was".

Другое дело! :)

Здравствуйте!
Если хотите, чтобы ваша дорожка действительно принесла пользу, её надо соединить с другими элементами дорожной сети. Сейчас она одним концом присоединена к границе парка, но непонятно, можно ли по ней попасть в парк. Если да, то надо довести её до дорожек в этом парке.

Приветствую!
Неправильно удалять этажность со здания, если оно отрисовано частями. Не все приложения нисходят до детализации уровня building:part, при этом у них должна оставаться возможность получить приближённую информацию о свойствах здания с его контура. В качестве огрублённого значения высоты проставляется максимальная, данное соглашение зафиксировано на странице osm.wiki/RU:Key:building:levels

Здравствуйте. К сожалению, не могу быть на 100% уверен, видео-подтверждений нет. По косвенным признакам:
1) проезжал вчера с GPS-трекером, отмечал все важные скоростные знаки, при этом дорога была практически пуста, т.е. ничего не загораживало обзор
3) в точке node/2974232598 у меня сделана аудио-пометка "направо на съезд знак 80, потом 60 и 40". Может, "ваш" знак 80 относился к съезду?

Но я запомню и в ближайшее время проеду там ещё внимательней.

Если что, я не выступал против отношений associatedStreet. Я лишь просил сохранять текущее тегирование (addr:street на здании), пока associatedStreet не получит достаточно широкого распространения и признания, чтобы его заменить (если это вообще произойдёт).