потому, что обозначаете не контур здания, а предполагаемую точку в которой находится здание! именно ТОЧКУ… пусть она имеет адрес и прочие атрибуты, но точкой она и останется, пока не будет прорисован периметр объекта.
C какой радости я должен обозначать именно контур здания (реки, города, дерева, почтового ящика)?
собственно этой цитатой и подводим итог: эти объекты являются именно точками POI, и с натяжкой применимы к полигонам, коими является зданиями… если мы подтягиваем building=yes для точки, тогда разговор можно не продолжать… каждый останется при своем мнении!
spacer, тебе Лёша совсем про другое говорит. Можно пользоваться картой, у которой система условных знаков не очень логична. Русский язык устроен не очень логично, но мы все им пользуемся. Но невозможно пользоваться картой, у которой система условных знаков внезапно и необъяснимо меняется. Особенно если при этом легенда карты остается старая (поскольку тот кто устраивает массовые замены тегов считает выше своего достоинства обновлять ее (легенду)).
с такой, что для building=yes это обозначено в wiki довольно внятно. building=yes - совокупность точек! 
Zkir, я прекрасно понял что хотел сказать liosha… я всего лишь пытался уточнить его слова применительно к нашему разговору.
Может тогда стоит завязывать с троллингом?
не надо притягивать “за уши” желаемое! но продолжать спорить на эту тему больше не буду, остаюсь при своем мнении! ибо приведенные аргументы меня не удовлетворили…
Слава богу! 
может кто нить с опытом составления пропоузелов решится и организует запрос на изменение описания building в Map_Features?
Подписываюсь! И к Zkir тоже. Если не известна форма - это не значит, что здания нет, а “более подходящих тегов” для обозначения здания кроме building=yes я не знаю.
Ну вообще, теги в ОСМ, как и любой живой язык - это просто месиво из исключений. Чего стоят только всякие shop vs amenity vs office. Нормальному человеку, недавно начавшему рисовать, очень многое будет резать глаз и вызывать возмущение. Мне, например, тяжело понять, почему shop=hairdresser и shop=car_repair не не обозначаются amenity. Тем не менее, когда я учу какой-нибудь иностранный язык, я готов к тому, что будут непонятные и ничем не объяснимые исключения просто потому, что так сложилось. Это глупо например, наезжать на англичан, почему, мол, у них множественное число у существительных не всегда добавлением s на конце образуется и требовать от них переделать все в соответствии с единым правилом.
shop означает не только магазин, но и платные услуги.
Пока что я вижу четыре аргумента против перехода на entrance=*
- Так повелось/уже привыкли. Действительно, не аргумент. Когда-то уже повелось, что Солнце вращается вокруг Земли… “Я понимаю, что формула неверная, но мне так считать удобнее”
- Нужно будет переписывать софт. Да, понимаю, что это не делается одним лишь усилием мысли, но неужели это приходится делать каждый день?
- Как теперь подъезд от входа в парк отличать. А надо? Подъезд - не вход, что ли? Я не буду у входа в парк указывать диапазон квартир, клянусь. В конце концов, можно использовать тег entrance=<значение для подъезда>
- Ну а что, у нас и так highway=bus_stop и прочее всюду. И ничего, живём. См. пункт 1.
В проекте можно оптимизировать систему обозначений. Кто-то уже задумался и даже разработал пропозал. Давайте не упускать возможность.
.
Какой access= указывать для домофонов? customer?
private, я думаю
Главный аргумент на самом деле таков: А какой смысл в замене? Что именно она поможет решить/улучшить? Вот минусы - они объективно есть, а каковы плюсы?
Добавлять entrance=* в дополнение к building=entrance - пожалуйста, никто не против. А вот заменять building=entrance на entrance=* - для этого нужна причина. Пока она была озвучена только одна - сохранение абстрактной “чистоты” тега building. ИМХО, этого слишком мало, чтобы ломать существующие программы.
А давайте составим список программ, которые дествительно используются на практике и поломаются при смене тега.
Из замеченных мной - мог быть Osmarender (но теперь уже умеет entrance=*), конвертация в СитиГид (если возникнет проблема с правкой конфигов для него, готов взяться за это и даже вспомнить VB6).
Кто ещё умеет building=entrance?
Данные OSM часто используются не только в публичных сервисах и программах. Поэтому невозможно заранее сказать сколько именно и чего поломается. За два с лишним года существования этого тега его кто угодно мог заюзать.
Так всё-таки, есть ещё плюсы от замены? Замена ради замены - это неверный подход в принципе.