Если модераторам будет угодно, можно это перенести куда-нибудь поглубже, например, в вопросы новичков:
Мультиполигоны — вещь дико удобная. А вопрос такой: если у частей здания есть характеристики разной природы, которые не образуют иерархии, но для использования требуют тега building, то как их правильно вносить в базу? Поясню примером.
не смотря на то, что здание вполне монолитно и строилось сразу, у него много корпусов, при этом:
1.1. есть кадастровые корпуса;
1.2. есть корпуса по инженерному плану, не совпадающие с кадастровыми (одни в другие не входят, но пересекаются);
у разных его частей разная этажность;
есть 5 эркеров, начинающихся со 2 этажа.
Сейчас это всё внесено в базу мной и ещё полутора маньяками.
Проблема в том, что всё это деление принципиально не образует иерархии. И проблема в том, что для указывания кадастровых и инженерных номеров, этажности и т.д. у соответствующего мультиполигона должен стоять атрибут “building”. В итоге, некоторые участки здания (в пересечении мультиполигонов) маркируются атрибутом building фактически по 3-4 раза. Какие-то больше, какие-то меньше. В JOSM выглядит уродливо, растеризаторами рендерится хорошо. Но главное меня это беспокоит по сути. Здание-то одно (а не 3-4), просто разные его характеристики его по-разному делят.
Предвижу ответ вроде “адекватные люди столько над одним домом не издеваются”. С точностью до этого, какие будут предложения?
убрать тег building с общего контура, и вообще желательно убрать этот контур, а название перенести на территорию
оставить building на кусках здания, имеющих разные адреса (литеры). Сейчас обычно используется схема один адрес = один дом
заменить building на building:part на кусках с этажностью. Glosm и latlon понимают этот тег и проставленные вместе с ним building:levels, building:min_level, height и min_height (правда, Glosm не понимает, если тег на мультиполигоне)
также заменить на building:part куски с названиями корпусов, если они не совпадают с литерами или частями с одной этажностью.
Кстати столкнулся с тем, что 3D-рендерилки (glosm не пробовал) вообще не связываются со зданиями из мультиполигонов, обходят их стороной. Интересно, это в зданиях накосячено, или рендерилки в принципе этого не поддерживают?
Я уже неоднократно говорил что building:part - зло. Добро - отношение типа collection, которое явно не ограничивает относительное расположение частей (пересекаюся/касаются/накладываются) и явно задаёт как относятся тэги на частях и отношении (тэги на частях уточняют тэги на отношении). Использование building:part разрывает здание на части, никак не связанные между собой и с, например, адресной информацией.
Создавать дополнительное отношение для собирания частей дома воедино - то же самое, что и собирать части улицы с помощью street, и даже хуже, потому что здесь части дома могут быть мультиполигонами. Т.е. само здание будет отношением с членами - отношениями, и адрес будет стоять скорее всего стоять на нём. Интересно, кто будет поддерживать ещё и такую схему адресации?
И вспомним, как “популярна” нынешняя схема тегирования маршрутов общественного транспорта - там ведь тоже отношение из двух отношений … правда там от этого не отвертеться.
Так почему бы не допустить, что геометрическое положение building:part внутри building автоматически приписывает его к этому building. С адресами внутри населённых пунктов ведь это работает.
Спасибо. Если теги на частях уточняют теги на целом и имеет место нечто вроде наследования — это ещё лучше.
Правда написано про collection всего ничего: http://wiki.openstreetmap.org/wiki/Relation:collection
Тем не менее, как пользоваться — понятно. Группировка с наследованием свойств. Надеюсь, что ещё и с перекрытием.
Одно только вызывает сомнения: если про него так мало написано, то возможно оно ещё менее популярно, чем building:part… Кто его поддерживает?
