Абсолютно ничего не теряем, напротив, получаем взамен внятную и однообразную структуру данных, а не “в лес - по дрова”. Ставим POI и туда заносим все необходимое. Даже с точкит зрения рендера есть удобства - сохраняется номер здания на карте.
Вам не кажется, что архитектурное сооружение и организация, которая это сооружение использует суть разные вещи и эта разница должна имет отражение в структуре БД?
С точки зрения лени проблем не вижу, ибо редактировать POI намного удобнее. Их, как минимум, сразу видно в редакторе, а building - чёрный ящик. Пока не ткнёшь мышом, не ясно есть там чего или нет.
Опять же, если эффективному менагеру захочется внести свой “ООО Лабеан” в OSM, то весьма желательно подсунуть ему редактор POI типа этого: http://ae.osmsurround.org/ae/index чтоб он не перся самостоятельно править теги на buldinge, как говорится, “во избежании…”
Территорию больниц/детсадов при помощи POI и тегов на здании отмечать не собираюсь. Для этого есть другие средства.
Если один пишет “Строителей” другой “Строителей улица”, третий “Строителей ул.”, то, конечно, не получится. Ибо это уже не БД, а бордель. (Что мы и имеем в реальности.) Тем не менее, небольшие города обычно делаются “в одну харю” и там вполне можно соблюдать жесткие и однозначные правила адресации.
Однообразную - да, а вот на счёт внятности - не согласен.
Нифига подобного. Сразу видно только то для чего есть соответствующая иконка у редактора (по крайней мере в JOSM). Как только ставишь тег, который редактор не знает (например тот же office) - получаешь просто точку. “Пока не ткнёшь мышом, не ясно есть там чего или нет.”. А здания с тегами, известными редактору так же отличаются, так что не вижу особой разницы.
Какие именно?
На небольших объёмах хорошо работают даже самые кривые и примитивные алгоритмы. Хороший алгоритм тем и отличается, что его относительно легко и удобно масштабировать.
Направление обхода имеет значение емнимп для береговых линий, земляных валов, и ледников. В описалове на мультиполигон про направление обхода вроде ничего не говориться. inner и outer - в общем то и нужны чтобы не заморачиваться с направлением обхода.
AMDmi3, я честно говоря вообще уже сомневаюсь в существовании схемы которая устроит, даже не большинство, а хотя-бы всех активно обсуждающих эту тему. (Это я про переменную этажность).
Я по рабоче-крестьянски поступил бы - проставил бы адрес обоим. Да некошерно - да копирование информации, да две сущности с одним адресом.
Это я к тому, что картинка с 3 мультиполигонами - просто иллюстрация к тому что составить 3 мультиполигона которые будут соответсвовать требованиям к мультиполигонам в этой ситуации - можно.
Обозначить и здание в целом и отдельные его части используя для этого одни и те же тэги так чтобы они не перекрывались - невозможно принципиально. Так что если хотим полигон для здания и полигоны для частей, то кто то из них не должен быть building’ом.
Порастекаюсь еще маленько мыслью по древу, про мультиполигоны и направление обхода:
Если бы небыло ролей inner и outer а геометрическое место точек (внутри или снаружи) определялось бы направлением обхода, то невозможно было бы нарисовать два граничащих полигона (озеро и лес к примеру) иначе как по общим точкам, т.к. общая грань должна была бы входить в эти полигоны с разным направлением обхода.