Amigo, кладрокод для магазинов не определён, насколько мне известно.
Номер комнаты или этаж, где расположено предприятие, действительно невозможно добыть из полигона здания. Всё остальное, по сути, решается обычным point-in-poly. Так же, как и бессмысленно прописывать на каждом доме is_in:country=RU.
А вот и нет, osm2mp вытаскивает.
Тогда отлично если это так, но почему-то в Garmin эта информация не попадает, используются адресные теги только с точек, Nominatim к сожалению тоже. И прийдется строго следить за адресацией полигонов, есть куча составных зданий с пристройками, где адрес только на одном полигоне указывается, что логично.
Да, еще как быть тогда с ситуацией когда рекламный (общеизвестный) адрес - читай адрес точки POI, отличается от адреса здания (иногда опускаются строения, корпуса и т.п.)?
Тут нужно уточнение.
Те точки, что генерятся из полигонов с заданными адресными данными, и у для типов которых в конфигах задано “contacts: yes”, должны вытаскиваться с адресом. Я сейчас нашел в приборчике пару таких объектов, адрес у них виден.
А вот если точка просто нависает над домом, тогда ой. Самое правильное - переносить теги с точки на дом, но, естественно, только если она его весь занимает. Если не занимает, то пока, действительно, с таким хитрым определением адреса облом, не реализовано.
Об этом и речь, пока не реализовано, а уже выпиливают, можно же сделать это позже хотя-бы. Может этот кусок оффтопа в отдельную ветку вырезать?
Пните лучше Лешу чтобы реализовал 
Алгоритм там уже для этого есть. И вообще, правильная модель данных первична)
Создавайте relation из точки и полигона (aka area в GRASS).
Выпиливаю еще и потому, что в половине случаях ещё и неправильно адресацию на точку ставят. И она не соответствует тому что на здании. Проспект Науки, к примеру, это не Науки проспект, Науки пр., пр-т Науки и тп.
А вообще стараюсь “прилепить” пои к зданию, если их не много, или на дом, если пои относится ко всему дому. В случаях с торговыми центрами, где их бывает много, оставляю на местах.
Да ну, а завтра подвинут точку за пределы полигона, или сам полигон разрисуют по этажности или “цвету крыши”… “То не трогаем, что работает”, то создаем трудности, хотя бы временные, для казуалов, отталкивая от проекта. liosha, не сомневаюсь, “распилится”, а кто будет пилить nominatim, мапник и другие сервисы?
Amigo, а вы уверены, что дополнительные адреса в точках не создадут проблем с поиском на других навигационных программах? Насколько безвредны такие правки под Garmin?
Не только же под Garmin, и не правки, изначально были адреса на точках, не я их придумал, мапник их рендерит, nominatim их оттуда берет.
Если данные схемы верны http://www.spb-projects.ru/showpage.php?id=206 (верхний рисунок), то это скорее всего немного восточнее, примерно тут
Это просто невнимательность при изменении нескольких выделенных объектов в JOSM.
а никто не пробовал сделать wms на основе rgis?
или хотя бы чтобы я дал bbox, масштаб и координаты центра в их системе (т.е. url картинки, проще говоря, и саму картинку сохранённую) — и оно сделало из этого wms или что-нибудь подобное в josm
ну или хотя бы расскажите, как их СК преобразовать в нормальную, которая в josm 
Там у них сервер не сказать чтобы быстрый. На формирование картинки несколько секунд уходит. Причём это они уже соптимизировали, раньше было гараздо хуже. И это всего на единицах пользователей. При большом кол-ве запросов там всё ляжет. Кроме того, настройки слоёв запоминаются в сессии, параметрами url-а ими не поуправляешь.
Ну, дистанция у них считается по евклиду, вот параметры обзорной карты, можно попробовать найти что-то похожее:
Надо бы сравнить с “кадастровой” СК, которая тут уже обсуждалась.