Перевод концепции модели данных ESRI внутреннего пространства зданий (BISDM)

Модель данных внутреннего пространства зданий (помещений) обеспечивает шаблоны классов пространственных объектов и таблиц, которые представляют информацию о здании. В то время как основное внимание уделяется планированию и управлению помещениями, также есть цель обеспечить основы для дополнительных данных, связанных со зданиями и сооружениями для поддержки разнообразных применений. Модель вобрала в себя наилучшие практики в области, которая быстро развивается по многим направлениям в различных организациях.

Этот документ содержит справочную информацию и описание модели данных.

Цель

В октябре 2007 года компания ESRI организовала дискуссию между представителями организаций по стандартизации, пользователями ГИС и поставщиками программного обеспечения с целью построения модели данных помещений.

Полученная модель намеревается:

• Инициировать проекты в области управления помещениями, позволяющие достигать краткосрочных организационных целей.
• Преодолеть реальные или мнимые барьеры для соединения с ГИС систем ERP (Управление ресурсами предприятия), IWMS (Интегрированная система управления рабочим пространством), CAFM (Система автоматизации управления инфраструктурой недвижимости) и AEC (архитектура, проектирование и строительство) приложений.
• Осуществлять более целостное взаимодействие между приложениями и снизить число преобразований и переделок данных. Модель делает это выделяя стандартный формат и методы для хранения в ГИС чертежей, связей с чертежами внутри ГИС или с чертежами, импортируемыми/экспортируемыми в ГИС.
• Сфокусироваться на получении практически полезных результатов. То есть сосредоточить внимание на всех элементах модели, которые обеспечивают немедленную высокую отдачу и повышают полезность приложения. Следует признать, что уникальное преимущество или вторичное использование модели становится возможным только после того как основные ее элементы размещены по своим местам; но текущая стадия развития модели фокусируется на данных, которые обеспечивают основу для приложений, которые сами по себе оправдывает немедленную адаптация ГИС для работы с помещениями.
• Быть осуществимой. Представляет набор лучших практик для использование данных о помещениях на уровне предприятия. Сосредотачивается на использовании программных и аппаратных технологий сегодняшнего дня вместо использования теоретически возможных достижений будущего в области ГИС-технологий, производительности процессора или приложений.
• Заложить основу для успеха, установив разумные ожидания по использованию ГИС с помещениями.

За границами модели

Для того, чтобы не терять концентрацию и избежать дискуссий, которые касаются целей модели помещений, важно определить, что модель не собирается делать:

• Становиться стандартом. Есть существующие хорошо разработанные стандарты для хранения и обмена данными по недвижимому имуществу и A/E/C (архитектура, проектирование и строительство) домены. Эта модель направлена на практическую реализацию вместо абстрактной классификации. Она отражает существующие стандарты где это возможно. Она не будет дублировать или заменять их.
• Быть единственным решением. Эта модель представляет одну из возможных структур данных, пригодную для практического применения. Она не претендует на звание единственный обоснованной структуры, используемой для работы в ГИС с помещениями.
• Поддерживать все возможные сценарии использования. Есть большое число сценариев использования помещений в ГИС. Эта модель сосредоточена только на основных и широко распространенных видах применения. Вертикальные приложения, такие как системы отслеживание сетей газоснабжения, являющиеся по-настоящему ГИС ориентированными приложениями, могут обнаружить, что они нуждаются в своих собственных специализированных элементах данных.
• Поддерживать всех ГИС производителей. Хотя принципы модели базируются на обобщенных понятиях, конкретная модель выражается в терминах ESRI-объектов и пространственных объектов.
• Оставаться статичной. Каждая организация имеет уникальную миссию или бизнес-модель. Таким образом каждая организация скорее всего имеет веские причины для расширения модели для представления возможности управления собственным уникальным направлением. Поэтому нам следует ждать дополнения модели.
• Становиться завершенной. Первая черновая фаза модели данных будет завершена в 2007 году, а первые пилотные проекты — в феврале 2008 года. Сценарии использования, которые не будут реализованы в эти временные рамки, будут перенесены на следующие фазы.
• Сказать последнее слово. Программное и аппаратное обеспечение, а также стандарты непрерывно улучшаются. Возможности, которые были непрактичны в этом году станут возможны в следующем. Модель планирует стать катализатором для действий, но не ограничена для изменения. Но одну вещь про модель можно сказать наверняка — она будет развиваться.

Руководство

Технологические процессы и данные для управления помещениями являются сложными и часто, казалось бы, не поддающимися обработке. Однако есть несколько руководящих принципов, разработанных в различных организациях, которые могут быть использованы для реализации успешного приложения.

Применение сервис-ориентированного подхода

Большинство обоснований использования помещений в ГИС связаны с созданием географических данных, доступных к развертыванию в масштабе предприятия. Поэтому модель структурирована таким способом, который позволяет интегрировать ее в типичный стек предприятии. Это тема заслуживает некоторого представление поскольку этот подход упрощает модель, скорость развертывания и делает очевидным позиционирование модели в больших рабочих процессах, в которых будут работать ГИС приложения.

Этот подход является более важным при обработке в ГИС данных о помещениях, а не в других применениях ГИС. В большинстве других применений ГИС, таких как гидрология, ГИС системы сами являются ядром рабочих процессов. При этом построение данных о помещениях чаще всего осуществляется вне ГИС. Даже когда информация генерируется с помощью геодезических методов в ГИС многие из потребителей информации такие как A/E/C консультанты и поставщики требуют поставки информации таким образом, чтобы ее можно было интегрировать в их собственные инструменты.

Столкнувшись с аналогичными требованиями рабочих процессов и информационного обмена многие ИТ организации переходят к сервис-ориентированному подходу, который позволяет достигать цели, без замены существующих корпоративных приложений, что даст возможность избежать необходимости централизации всех данных и процессов, разделяя информацию и логику вдоль естественных границ ответственности. Ярким примером такой практики в условиях ГИС является функция учета. Не требуется изобретать функции учета ERP (Управление ресурсами предприятия) систем внутри ГИС для их интеграции. Функции учета и практика ГИС требуют только установления интерфейсов, которые будут передавать данные и задачи.

Те же принципы применяются, когда работают с данными об объектах недвижимости, архитектуре, о техническом обслуживании и эксплуатации зданий, или с данными хранящимися в системах IWMS (Интегрированная система управления рабочим пространством) и CAFM (Система автоматизации управления инфраструктурой недвижимости). Эти данные уже управляются системами с долгой историей, установленными нормами и сильным индустриальным импульсом — каждую из которых ГИС может попытаться усилить вместо изобретения заново. Чтобы повысить эффективность, даже в случае если ГИС системы предоставляют уникальные данные, необходимо только связать ГИС с этими системами.

Например, система управления техническим обслуживанием будет иметь сложные схемы для отслеживания оборудования, профилактические процедуры и шаги, запросы на проведение работ, наряды на выполнение работ, сведения о рабочей силе и других аспектах осуществляемого в настоящее время обслуживания. ГИС может добавить огромную ценность для этой бизнес-функции, предоставляя информацию о местоположениях, управляя маршрутом и создавая контекст для принятия решения по оборудованию. Для обеспечения этих возможностей модель данных должна только соединяться с существующей информацией об оборудовании. Модель данных не нуждается в импорте или попытках управления полным массивом данных об оборудовании.

Такой подход избавляет от необходимости перезаписать существующие стандарты, или дублировать данные, или модели данных уже в достаточной степени управляемые в системах BIM (Информационная модель здания), CAD (Система автоматизированного проектирования), ERP (Управление ресурсами предприятия), Системе управления недвижимостью, IWMS (Интегрированная система управления рабочим пространством), CAFM (Система автоматизации управления инфраструктурой недвижимости), или CMMS (Компьютеризированная система управления техническим обслуживанием).

Применение логических идентификаторов объектов

Способы соединения систем между собой находятся в центре внимания предприятий, т.к. множество элементов модели данных нуждается в использовании идентификаторов, которые генерируются системами внешними по отношению к ГИС.

Рассмотрим оборудование, которое часто идентифицируется по штрих-коду, получаемому при его приемке в рамках программы управления активами. Этот штрих код идентифицирует оборудование на протяжении всего его жизненного цикла и используется в различных целях: для легкого управления задачами перемещения и физического размещения, для решения задач обслуживания и для финансовых задач, таких как отслеживание его стоимости и амортизации, а также аудита.

Внутри этого контекста ГИС может обеспечить огромную добавленную стоимость при определении местоположения оборудования в масштабах всего предприятия без учета того внутри или снаружи здания оно находится. Однако для этого элемента данных — оборудования — ГИС отвечает только за местоположение. Другие элементы данных и сам факт существования оборудования управляется другими системами, и ГИС приложения должны проектировать свои идентификаторы в соответствии с идентификаторами внешних систем. Имущество, здания, квартиры и другие элементы следует тому же самому шаблону.

В этих случаях используются первичные ключи, идентифицирующие элементы, что обеспечивает наилучшее соединение данных. В сочетании с фактом, что во многих случаях дополнительная информация является внешней по отношению к ГИС, это структура часто означает что пространственные данные ГИС хранятся в наборе таблиц, включающем логические идентификаторы (такой как штрих-код оборудования) в виде ссылки или внешнего ключа. Остальная часть данных хранится в отдельных таблицах внешний системы (такой как система управления активами) или импортируется из таблиц внешней системы. В некоторых обстоятельствах множество внешних ключей может требоваться для соединения между пространственными данными ГИС и связанной, но независимой внешней информационной системой. Это предполагает использование технического приема, при котором первичный ключ хранится в таблице пространственных объектов как атрибут, а таблица пространственных объектов и таблица с дополнительными сведениями объединяются, используя ArcSDE представления (View) или инструмент “Join” карты.

Определение системы-источника графических данных

Объекты с сильными графическими связями руководствуются другими принципами. Например, идентификация стен и дверных проемов генерируется из их графического представление и местоположения. Ни одно другое представление включая стоимость не существует без ссылки на графическую идентичность. Кроме того, ключевыми свойствами элементов являются их соотношения друг с другом: такие как соединение стен друг с другом. В этом случае соединение с существующими системами возможно только с помощью массового импорта или экспорта целых частей модели таких как этаж или крыло здания.

Обратите внимание, что вы не можете просто использовать оба подхода. Вы не можете установить соответствие между стенами, сгенерированными ГИС на основе данных измерений (внешние данные), со стенами, сгенерированными в архитектурной модели BIM (внутренними данными), без ручной обработки.

Вы не сможете надежно повторно импортировать данные об элементах, таких как стены, так как в отличие от помещений или оборудования стены не имеют уникального идентификатора, который говорил бы вам какие отдельные элементы должны быть добавлены, удалены или воссозданы.

Соблюдайте технологические процессы, создающие данные

Из-за этих свойств технологические процессы для графики являются односторонними. Вы можете повторить импорт стен зданий из модели BIM (Информационная модель здания), но вы должны каждый раз заменять эти стены в ГИС.

Вы также можете повторно импортировать помещения из BIM (Информационная модель здания) модели, но все поворотные точки для отдельных зданий, комнат или квартир должны быть воссозданы. Вы не можете экономно сопоставить данные, созданные в модели BIM (Информационная модель здания) и данные, созданные в ГИС, на том же самом месте.

Однако вы можете определить различные системы-источники для различных областей. Например, вы можете установить, что графическое местоположение у всех объектов, расположенных внутри здания приходит из BIM (Информационная модель здания) модели или из САПР. С другой стороны, Вы можете утвердить, что местоположение всего внешнего оборудования такого как трансформаторы или телефонные столбы приходит из данных геодезических измерений, полученных внутри ГИС систем. В этом нет никакого конфликта, так как для каждого экземпляра оборудования устанавливается только один источник информации. Опять же это является только рекомендацией, а не ограничением.

Как уже упоминалось выше, модель данных помещений имеет значение только внутри больших рабочих процессов, которые генерируют или потребляют данные. Убедитесь, что ГИС данные остаются связанными с “живыми” рабочими процессами, т.к. это позволит гарантировать, что данные будут точными, актуальными и значимыми для предприятия.

Обеспечение масштабируемости

Одним из ключевых преимуществ ГИС является их способность к репликации и масштабированию, поэтому модель должна учитывать проблемы масштабируемости и производительности. С этой целью модель данных сосредоточена на реляционной основе ГИС систем; то есть модель помещений не является объектно-ориентированным проектом. Такой подход не исключает использование объектно-ориентированных методов, а предполагает, что объектно-ориентированный код должен находиться на логическом уровне или на уровне приложения, обрабатывающего информацию, вместо уровня данных, хранящего модель.

С точки зрения описания стандартизованных объектов, связи отражают соответствие стандарту, но не реализуют его. Например, в модели данных помещений стены будут сопоставлены с элементами внутри элемента buildingSmart (семейство стандартов) IFCWall (стена); однако они не будут реализовывать всю иерархию объектов, помещенную внутри IFCWall.

Включение только обоснованных данных

Пока не стандартизовано какие элементы и атрибуты включаются в модель данных есть только надежда, что сбор информации будет обеспечивать возврат инвестиций. Это особенно верно для стадии проектирования работ по сбору, вводу в эксплуатацию и обработке данных, так как персонал, проектирующий строительство, не знает какие данные будут использоваться последователями и будут ли они сохраняться.

Все данные вызывают издержки на протяжении всего жизненного цикла, будут ли они преобразовываться, пересматриваться или обслуживаться. Даже если вы делаете полевое обследование каждый дополнительный атрибут, который вы решите собрать в любом случае создает затраты на ввод данных, проверку и импорт. Кроме того, любые данные, отрезанные от процесса, который их производит, становятся опасно устаревшими и уменьшают ценность данных, являющихся точными и надежными.

Эти соображения приводят к необходимости сосредоточиться в модели данных на минимальном наборе элементов, которые поддерживают краткосрочные сценарии использования, вместо широкого набора данных, поддерживающего “туманные” цели. Такой подход вместе с прагматичными рабочими процессами вероятно ускорит практическую реализацию по сравнению с наивной методикой, демонстрирующей, что невозможно обоснованно обеспечить постоянную точность для данных, которые она претендуют обрабатывать.

Сосредоточенность только на передовом опыте масштаба предприятия

Избегайте любых рекомендаций, которые хорошо работают только для демонстрационных целей, но не масштабируются для корпоративного использования. Например, возможно включать информацию об оценке состояния в запись об оборудовании. Но в условиях предприятия задачи по оценке отслеживаются отдельно, т.к. они могут выполняться многократно для каждого элемента оборудования, могут быть загружены на КПК и назначены мастеру и впоследствии могут трансформироваться в запрос на проведение работ. Таким образом, следует избегать элементов оценки в таблице оборудования.

Сосредоточенность на ГИС-направленных элементах

Случаями использования, обосновывающими краткосрочное внедрение ГИС-технологий для помещений, являются те, которые бесспорно требуют усиления с помощью свойств, уникальных для ГИС.

Этими случаями является те, которые:

• Требуют масштабирования;
• Требуют пространственные связи;
• Собраны с помощью геодезических инструментов, естественных для геопространственных окружений;
• Требуют перебора и анализа топологических сетей масштаба предприятия;
• Оправданно являются неотъемлемой частью общей эксплуатационной картины здания и его инфраструктуры.

Таким образом, модель данных начинается с ГИС-направленного содержания.

Связь с существующими стандартами

Рассматриваемая модель данных намерена ссылаться, а не изобретать существующие стандарты для смежных областей.

buildingSmart IFC Model

http://www.iai-na.org/bsmart/

Этот стандарт используется некоторыми членами индустрии AEC (архитектура, проектирование и строительство) и стандартизирует геометрические элементы, связи и ограничения для элементов зданий, таких как стены, двери, столбы и оборудование. Эти элементы в модели данных помещений представляют из себя внутренние элементы зданий и имеют взаимно однозначное отображение на элементы IFC (Industry Foundation Classes) модели.

IFC (Industry Foundation Classes) модель создана в расчете на системы настольного компьютера, а не на развертывание в среде предприятия. Это модель также создана без учета того факта, что различные части данных могут быть созданы различными группами внутри предприятия. Например, данные об оборудовании разрабатываются не только архитектором и инженером, но и работниками сферы финансов, закупок, эксплуатации и технического обслуживания. Теоретически они могут быть сохранены в одном IFC (Industry Foundation Classes) объекте. Но на практике эти части данных управляются в различных системах, связанных между собой с помощью web-сервисов, так как информация об амортизации, местоположении и обслуживании сильнее связана с технологическим процессом-владельцем, а не с другими частями данных. По сути IFC (Industry Foundation Classes) является абстрактным стандартом, который служит в большей степени справочником, в частности для обмена данными, но не структурой или моделью, которая может быть развернута на уровне предприятия “как есть”.

CityGML

http://www.citygml.org/

CityGML принадлежит к ГИС городского масштаба. В основном совпадает с моделью помещений при визуализации зданий. С этой целью 3D здания во внутренней модели имеют отображение на CityGML.

OSCRE

http://www.oscre.org/

Этот стандарт ссылается на данные портфеля недвижимости уровня зданий и ссылается на внутреннем уровне на стандарты BOMA (Ассоциации владельцев и управляющих недвижимости), IFMA (Ассоциация профессионалов в области эксплуатации и обслуживания объектов недвижимости), FICM (Facilities Inventory and Classification Manual). Описываемые им элементы, как правило, управляются в рамках приложений IWMS (Интегрированная система управления рабочим пространством).

Соответствующие элементы в рамках ГИС-модели помещений, не включают в себя элементы, относящиеся к стандартам OSCRE (Открытые стандарты консорциума по недвижимости). Например, ГИС модель помещений включает в себя местоположение имущества в виде точечного объекта с одним атрибутом, представляющим уникальный код недвижимости (PROPERTY_ID). Например, код EO13327 является уникальным идентификатором объекта недвижимости, используемым в существующем реестре недвижимости. Таким образом внутренняя ГИС модель хранит расположение, а внешняя система хранит другие свойства и их иерархии.

BOMA/IFMA/FICM/DIN277

http://www.boma.org/AboutBOMA/

http://www.ifma.org/

http://nces.ed.gov/pubs2006/2006160.pdf (FICM)

Эти стандарты регулируют классификацию помещений и, в значительной степени, поддерживают распределение между подразделениями прямых или косвенных расходов, направленных на получение дохода. В отношении помещений эти стандарты определяют, как границы квартир и комнат будут идентифицироваться внутри BIM (Информационная модель здания) или САПР и как эти пространства будут классифицированы по уровню оснащения оборудованием и типу. Рассматриваемая модель хранит ссылки на записи, внешние по отношению к пространственным таблицам ГИС, и эти внешние записи находятся в системах IWMS (Интегрированная система управления рабочим пространством) или CAFM (Система автоматизации управления инфраструктурой недвижимости), охватываемых этими стандартами.

COBIE – Обмен информацией о конструкции и эксплуатации зданий

http://www7.nationalacademies.org/ffc/Bill_Brodt_NASA_COBIE_Oct_06_WP.pdf

http://www.bfrl.nist.gov/PSSIWG/presentations/COBIE1.pdf

Этот стандарт регламентирует операционные процедуры в нарядах на выполнение работ и данные о планировании обслуживания в заявках на выполнение работ. Стандарт концентрируется на обмене таких элементов как гарантии, руководство по обслуживанию, запасные части, специальные средства. Рассматриваемая модель данных о помещениях ссылается на эту информацию вместо ее включения. Таким образом, до тех пор, пока связанная система технического обслуживания подчиняется стандарту COBIE она совместима с данной моделью.

Интеграционные методы

При анализе зданий реального мира вы не можете высказывать свое мнение даже о базовой архитектурной концепции здания, не зная о способе реализации его структуры в бетоне или стали. Также тяжело высказывать свое мнение о модели данных без некоторого представления о том, как реализовывать построенные на нем приложения.

Веб-сервисы/Сервис-ориентированная архитектура

В этом случае приложение само отвечает за трансформацию исходных данных модели в логику приложения. Приложение также отвечает за координацию с ГИС.

На рисунке показан пример такого приложения. Модель использует точки (долгота и широта) для зданий и применяет эту информацию для пространственной привязки договоров аренды, заключенных по помещениям в этом здании. Приложение использует веб сервисы для соединения с ГИС и предоставляет актуальное отображение данных, в данном случае данные инвентаризации.

Прямое соединение с базой данных

В этом случае модель данных приложения и модель данных помещений соединяются на уровне базы данных. Один из способов сделать это — это использовать раздельные табличные области внутри одного экземпляра базы данных и соединение их с помощью представлений (View) ArcSDE. Первым преимуществом этого подхода является то, что данные приложения и ГИС могут быть запрошены так, как если бы они были частью одной унифицированной модели. Вторым преимуществом является то, что эти запросы обладают очень высокой производительностью. Третьим — то, что соединения могут осуществляться с помощью составных ключей — незаменимый элемент для работы с данными о комнатах.

Этот проектный подход сохраняет базы геоданных настолько специализированными насколько это возможно и поддерживает раздельное присваивание атрибутов, если это может быть сделано лучше в связанной системе, содержащей рабочие потоки и соответствующие отношения. Проблема составных ключей иллюстрирует некоторые ограничения баз геоданных с точки зрения поддержки приложений и этот подход позволяет избежать эти ограничения полностью.

На рисунке показан пример интеграции базы данных. Данные о дорогах, коммунальных сооружениях и о земельных участках поступают из традиционных источников данных ГИС. Данные о зданиях и их надписи поступают из приложения управления недвижимостью, а данные и надписи оборудования поступают из приложения по управлению активами. Тем не менее, данные из всех источников доступны и отображаются “бесшовно” в среде ГИС.

Расширение базы данных

Предприятия при развертывании некоторых сайтов будут предпочитать расширять рассматриваемую модель вместо интеграции её с внешней системой. Например, вместо использования коммерческой системы управление активами для учета оборудования они могут отдать предпочтение своей собственной реализации с помощью новой таблицы в базе геоданных.

Это можно сделать, следуя вышеупомянутой конвенции. Например, данные о пространственном местоположении оборудования, идентифицируемые кодом оборудования, могут располагаться в одной таблице. А остальные данные об активах будут размещены в другой таблице, связанной с классом пространственных объектов. Несмотря на то, что данное внутреннее решение не полагается на какую-либо внешнюю систему, оно следует передовому опыту структурирования данных, облегчающему их обслуживание. Например, без потери данных или их целостности ГИС может создавать и удалять пространственные данные, а система управления активами — данные об активах. Единственное ограничение состоит в том, что, когда создается графика, ГИС приложение должно отслеживать код оборудования.

Импорт и экспорт

Элементы модели данных помещений отображают, а не реализовывают или переосмысливают существующие стандарты. Например, приложения могут создавать элементы модели данных из BIM (Информационная модель здания) модели или экспортировать их в BIM модель без дополнительных потерь, характерных для подобных перемещений данных.

Тем не менее модель данных помещений не собирается становиться стандартом и поэтому экспорт элементов в промежуточные форматы становится необязательным. Такой подход позволяет модели сконцентрироваться на создание прямого преобразование элементов из ключевых пакетов таких как Revit™, Bentley™ или ArchiCAD™ — практичных и готовых к производству.

Данный подход также позволяет модели усилить существующие API’s этих пакетов в части управления ключевыми аспектами этого переноса и поддерживать широкую совместимость с существующими стандартами. Например, вы можете создать стены с помощью Revit API просто используя необходимые материалы, толщину и высоту элементов. Затем Revit сам может экспортировать модель в совместимый с buildingSmart IFC формат. В качестве альтернативы Вы можете создавать элементы в ESRI и использовать программу преобразования данных, такую как Safe Software’s FME™ для создания формата совместимого с IFC (Industry Foundation Classes). Этот подход удовлетворяет все желательные сценарии использования: Вы можете быстро и эффективно преобразовывать данные, созданные в коммерческих пакетах программного обеспечения, в насыщенный возможностями, не зависящий от вендора формат.

Такой подход также позволяет избегать любой зависимости от того, как хранятся графические данные. Данные будут создаваться в среде, которую диктуют технологические процессы, но они могут переходить в любую другую среду, которая в этом нуждается.

Элементы начального охвата модели

Это быстрый обзор элементов рассматриваемой модели, разработанных в начальной фазе.

Для того чтобы сохранить сосредоточенность на непосредственных целях, это резюме группирует элементы по поддерживаемым ими вариантам использования. Некоторые элементы, такие как здания, нуждаются в различных уровнях пространственной детализации для поддержки различных вариантов использования. В этих случаях отдельные классы пространственных объектов описываются в общих чертах, так как классы пространственных объектов ESRI могут включать только 1 тип геометрии (точка, линия, полигон, мультиточка). Приложения могут использовать один или другой базовый класс по необходимости.

Элементы управления недвижимостью

ГИС элементы хранят географическое расположение элемента, который создается, поддерживается и удаляется за пределами пространственных таблиц. Например, код EO13327 является уникальным идентификатором объекта недвижимости, используемым в существующем реестре недвижимости, содержащем элементы данных, установленные Federal Real Property Council (США, Межведомственный совет, созданный в целях содействия эффективному и рациональному использованию недвижимого имущества Америки). По существу, ГИС модель помещений хранит местоположение, а внешние системы хранят другие данные по имуществу и их иерархии.

Варианты использования

Эти элементы подходят для включение пространственной составляющей в приложения по управлению объектами недвижимости и арендой, таким образом, что любое имущество, договор аренды или данные о затратах могли быть связаны и визуализированы вместе со зданиями.

Эти элементы не охватывают уровень собственности на земельные участки, поскольку участки хорошо отслеживаются в других моделях и стандартах (таких как ESRI Parcels and Cadastre data model).

Объединив данные об имуществе с вашей системой управления недвижимости Вы можете быстро достигнуть включения в неё пространственной составляющей.

Класс пространственных объектов “Имущество”

Эта таблица (на самом деле набор таблиц) содержит графические пространственные данные.

Property_Point		Точечный класс пространственных объектов представляет местоположение имущества
PROP_ID	String	Уникальный идентификатор имущества. Имущество может состоять из множества зданий

Все другие атрибуты будут храниться в системе — источнике и как правило не поддерживаются ГИС.

Таблица “Информация об имуществе”

В то время как некоторые сайты будут связываться с существующими IWMS (Интегрированная система управления рабочим пространством) или CAFM (Система автоматизации управления инфраструктурой недвижимости) системами, другие будут отслеживать элементы данных об имуществе в своих собственных таблицах. Эти таблицы содержат данные о свойствах имущества. Между записями в пространственной таблице “Имущество” и таблицей “Информация об имуществе” устанавливается связь один-к-одному. Дополнительные специфичные для сайта поля должны быть добавлены к таблице “Информация об имуществе”, а не к пространственной таблице “Имущество”.

Также можно добавить таблицу с объектами недвижимости, или таблицу OSCRE (Открытые стандарты консорциума по недвижимости), или любую другую таблицу или сервис. Но они всегда должны быть связаны с пространственной таблицей “Имущество” тем же способом, а именно используя связь один-к-одному: имущество имеет 1 запись в таблице “Информация об имуществе”.

Любая площадь отслеживается зданием и его границами или участком и его границами. Здания и участки связаны свойствами.

Property_Info		Информация об имуществе
PROP_ID	String	Уникальный идентификатор имущества. Имущество может состоять из множества зданий
PROP_NAME	String	Наименование имущества
DESCRIPTION	String	Описание имущества
ADDRESS1	String	Строка адреса 1
ADDRESS2	String	Строка адреса 2
STREET	String	Наименование улицы
CITY	String	Идентификатор города или наименование
STATE	String	Идентификатор субъекта федерации или USPS State код
ZIP	String	Почтовый индекс
ZONING	String	Код функциональной зоны
BOOK_VALUE	Double	Балансовая стоимость
MARKET_VALUE	Double	Рыночная стоимость

Соблазнительно унифицировать адреса имущества с другими типами адресов, находящимися в ГИС. Однако адреса принадлежат создавшему их приложению и имеют в этом контексте специфичное для каждого приложения значение. Агентство по доставке имеет одно определение для адреса, приложение по общественной безопасности — другое. Установление связи между адресом и имуществом, а также между адресом и зданием является не простым делом.

В случае если адрес должен быть связан с кадастром или с системой построения маршрутов, адресация будет поддерживаться специальным технологическим процессом. Организация создает структуру, получающую разрешение выдавать адреса. Итогом является модель в виде точек, связанных с уличной сетью, таким образом, что вы можете выполнять построение маршрутов. В случае зарегистрированного имущества корпоративные пользователи вручную вводят адрес, не следуя формальному процессу его определения.

Столбцы с координатами долгота-широта. Здания, в зависимости от способа использования информации, имеют более одного связанного с ними класса пространственных объектов. В качестве альтернативного способа хранения данных о местоположении Вы можете добавить столбцы с координатами долгота-широта в таблицу активов. Системы управления недвижимостью будут часто задавать местоположение как адрес, а не как точку. Сайты, желающие использовать информацию о местоположении могут использовать долготу и широту для перемещения к конкретному местоположению. Это быстрый и эффективный способ отображение недвижимости на картах. Также он может помочь при геокодировании местоположения здания из их адресов. В результате добавления данного столбца получается метод определения местоположения зданий и любого их содержимого в самом широком смысле: договоров аренды, арендаторов, оборудования и т.д., дающий высокую окупаемость инвестиций.

Пространственные данные о зданиях

Информация о зданиях имеет два уровня геометрической детализации:

• точки — используются для анализа вашего портфеля в масштабе города, региона или государства;
• площадные объекты — используются для планирования на уровне территории предприятия.

Каждый тип геометрии имеет свой собственный класс пространственных объектов, который может быть привязан к записям в таблице “Информация о здании”.

Класс пространственных объектов “Здания точечные”

Building_Point		Точечный класс пространственных объектов представляет местоположение зданий
PROP_BLDG_ID	String	Уникальный идентификатор, комбинирующий ИД имущества и здания

Класс пространственных объектов “Здания площадные”

Building_Footprint		Полигональный класс пространственных объектов представляет площадку под зданием
PROP_BLDG_ID	String	Уникальный идентификатор, комбинирующий ИД имущества и здания

Любая высота, назначенная габаритам здания, является условной высотой, используемой при планировании территории предприятия для визуализации зданий относительно друг друга, вместо использования фактической высоты, используемой в ландшафтной архитектуре. Если сайту нужна фактическая высота здания для ландшафтной архитектуры, компоновки архитектурных масс или анализа зонирования им вероятно нужно моделировать здания более точно.

Соблазнительно включить в таблицу информацию о высоте здания, дающую возможность грубой компоновки архитектурных масс. Однако просто одного значения недостаточно для того чтобы удовлетворить ожидания даже от базовой визуализации. Полная визуализация предполагает третье представление зданий с использованием мультипатчей (пространственный класс ESRI для 3D визуализации).

Таблица “Информация о зданиях”

Это связанная таблица содержит прикладную информацию. Пример таблицы, иллюстрирующей это отношение приведен ниже.

Building_Info		Подробная информация о здании
PROP_ID	String	Уникальный идентификатор имущества. Имущество может состоять из множества зданий
BLDG_ID	String	Уникальный идентификатор здания в пределах имущества.
PROP_BLDG_ID	String	Уникальный идентификатор, комбинирующий ИД имущества и здания
BLDG_NAME	String	Наименование здания
BLDG_USE	String	Код использования здания
DATE_BUILT	Date	Дата постройки
ADDRESS1	String	Строка адреса 1
ADDRESS2	String	Строка адреса 2
STREET	String	Наименование улицы
CITY	String	Идентификатор города или наименование
STATE	String	Идентификатор субъекта федерации или USPS State код
ZIP	String	Почтовый индекс

Элементы управления внутренним устройством зданий

Случаи использования

Эти элементы подходят для:

• включения геопривязки в IWMS (Интегрированная система управления рабочим пространством), CAFM (Система автоматизации управления инфраструктурой недвижимости), систему управления активами и систему оперативного управления;
• базировании полевого сбора геопривязанных данных об окружающей среде, температуре или других полезных данных.

Этажи и группы. Объекты-посредники, такие как этажи или группы для недвижимости или для оперативного управления недвижимостью могут быть полезны. В этих случаях “Этаж” может быть просто подтверждающим кодом или графическим элементом.

Building_Floor		Таблица содержит информацию про этажи здания
PROP_BLDG_ID	String	Уникальный идентификатор, комбинирующий ИД имущества и здания
FLR_ID	String	Идентификатор этажа
BLDG_FLR_ID	String	Уникальный идентификатор, комбинирующий ИД здания и этажа

Класс пространственных объектов “Комната”

Building_Room		Полигоны, которые представляют контур определяющий помещение в соответствии с правилами группировки
BLDG_FLR_RM_ID	String	Уникальный идентификатор, комбинирующий ИД здания, этажа и комнаты
CEILING_HEIGHT	Double	Высота потолка, как расстояние от пола, в футах
ACTUAL_ELEVATION	Double	Фактически измеренная высота

Как и у других элементов геометрические свойства находятся в таблице с пространственными данными; назначение и функциональная группа находятся в связанной таблице.  Они могут быть реализованы как связанное представление. Высота потолка используется для 3D визуализации. Этот атрибут находится в пространственной таблице, т.к. это сильно упрощает в таком случае создание 3D объекта выдавливанием. Этот атрибут должен храниться в каждой комнате, т.к. некоторые комнаты на том же этаже (такие как лекционный зал, кафетерий) будут иметь их собственную высоту.

Фактическая высота используется для анализа зон прямой видимости и исследования зонирования.

Ключевые геометрические свойства, такие как площадь могут быть рассчитаны на основе геометрических границ комнаты.

Таблица “Информация о комнате”

Пока некоторые сайты будут связывать существующие IWMS (Интегрированная система управления рабочим пространством) или CAFM (Система автоматизации управления инфраструктурой недвижимости) системы, другие будут отслеживать основные данные о комнатах внутри базы геоданных. Эта таблица содержит информацию о комнатах. Дополнительные, специфичные для сайта поля должны быть добавлены в эту таблицу, вместо пространственной таблицы.

Room_Info		Подробная информация о комнате
BLDG_FLR_ID	String	Уникальный идентификатор, комбинирующий ИД здания и этажа
RM_ID	String	Идентификатор комнаты
RM_NAME	String	Название комнаты
BLDG_FLR_RM_ID	String	Уникальный идентификатор, комбинирующий ИД здания, этажа и комнаты
RM_CAT	String	Описание категории комнаты
RM_TYPE	String	Тип комнаты
DESCRIPTION	String	Описание “Информации о комнате”
DV_ID	String	Идентификатор подразделения
DP_ID	String	Идентификатор департамента

Используя поля категории комнаты и типа комнаты сайты могут категорировать помещения согласно их стандартным методологиям (BOMA (Ассоциации владельцев и управляющих недвижимости), IFMA (Ассоциация профессионалов в области эксплуатации и обслуживания объектов недвижимости), FICM (Facilities Inventory and Classification Manual), DIN277 (Площадки и размеры зданий)). Сайты могут пожелать устанавливать допустимые значения на основе выбранного стандарта.

Класс пространственных объектов “Зона”

Building_Zone		Полигональный класс пространственных объектов, который представляет часть здания. Зоны могут быть связаны с такими системами как HVAC (отопление, вентиляция и кондиционирование), безопасность или другими аспектами управления зданиями
BLDG_FLR_ZONE_ID	String	Уникальный идентификатор, комбинирующий ИД здания, этажа и зоны
CEILING_HEIGHT	Double	Высота потолка, как расстояние от пола, в футах
ACTUAL_ELEVATION	Double	Фактически измеренная высота

Зоны являются подмножеством этажей, служащим специфическим целям, таким как пожарная безопасность, безопасность жизнедеятельности и охрана.

Таблица “Информация о зонах”

Зоны назначаются такими системами как как пожарная безопасность, HVAC (отопление, вентиляция и кондиционирование), безопасность жизнедеятельности, электричество, водоснабжение, канализация, пожаротушение или система охраны здания.

Building_Zone_Info		Подробная информация о зонах
BLDG_FLR_ID	String	Уникальный идентификатор, комбинирующий ИД здания и этажа
ZONE_ID	String	Идентификатор зоны. Уникален в пределах этажа.
BLDG_FLR_ZONE_ID	String	Уникальный идентификатор, комбинирующий ИД здания, этажа и зоны
DESCRIPTION	String	Описание “Информации о зоне”
SYSTEM_ID	String	Идентификатор системы, которая может быть связана с зонами. Например может включать HVAC (отопление, вентиляция и кондиционирование), безопасность жизнедеятельности, электричество, охрану и т.д.

Класс пространственных объектов “Оборудование”

Equipment		Класс пространственных объектов определяющий местоположение оборудования внутри здания
EQUIP_ID	String	Уникальный идентификатор оборудования

Оборудование можно позиционировать точечным объектом (например, широта и долгота телефонного столба на котором расположен трансформатор).

Оборудование устанавливает связь с подробными данными с помощью кода оборудования, о котором вы можете думать, как о штрих-коде, который индивидуализирует его в системе управления активами и технического обслуживания.

Трудно найти случай использования, который нуждается в фактической высоте оборудования вместо условной высоты.

Таблица “Информация об оборудовании”

Equipment_Info		Таблица “Информация об оборудовании” сведения про оборудование, расположенное внутри здания
EQUIP_ID	String	Уникальный идентификатор оборудования
EQUIP_STD	String	Классификация оборудования или стандартное описание
DESCRIPTION	String	Описание “Информации об оборудовании”
BLDG_FLR_RM_ID	String	Уникальный идентификатор, комбинирующий ИД здания, этажа и комнаты

Таблица “Информация об оборудовании” содержит информацию о назначение и функциональной группе оборудования. В большинстве случаев эта информация будет находиться системе управления активами (например, системы IWMS (Интегрированная система управления рабочим пространством)) или системе технического обслуживания (CMMS).

Таблица оборудования содержит эти элементы, которые будут каталогизированы для инвентаризации активов или для технического обслуживания. Таблица оборудования не содержит других элементов, таких как элементы систем связи: панели, порты, разъемы, сетевые устройства и так далее. Они будут нуждаться в своих собственных таблицах с уникальными атрибутами.

Внутреннее моделирование и анализ зданий

Поддерживаемые варианты использования

Набор элементов позволяет:  

• Собирать информацию о внутренней геометрии здания из геопространственных съемок с помощью автоматических роботизированных исследований;
• Собирать данные об окружающей среде;
• Анализировать линии видимости для обеспечения безопасности.

Эти данные позволяют, но сами по себе не достаточны для:

• Анализа необходимой информации о связности узлов сети для ориентирования или аварийной эвакуации.

В теории наружные стены, окна и двери могут быть использованы для визуализации, таким же образом, как и в CityGML используя LOD 2 (уровень детализации). На практике эти данные дорого создавать или импортировать в высоко структурированную форму только для целей визуализации, и поэтому это не является приоритетом для данных масштаба предприятия. Дизайнеры ищут способ визуализировать свои здания в контексте их окружения, вероятно, используя уровень детализации до здания, или специальные инструменты для одного, представляющего интерес здания, вместо зависимости от библиотек, структурирующих данные о здании, доступных для этих целей.

Пространственные классы внутренних элементов здания

Все внутренние элементы зданий используют те же линейные классы пространственных объектов, чтобы представлять свои границы как совокупность линий.

Стены, например, состоят из 5 линий, где пятая представляет собой ось. Внутренние стены, внешние стены, колонны, двери и окна — все будут подтипами этого же класса.

3D отображение должно использовать мультипатчи (пространственный класс ESRI для 3D визуализации) для отображения соответствующих высот проемов и форм. Эта разновидность 3D представления выходит за рамки данной фазы модели данных, за исключением представления, как правило, созданного выдавливанием 2D пространственных объектов.

Boundary_Line		Линейный пространственный класс, используемый для генерации полигонов внутреннего пространства. Линейные подтипы могут включать стены, окна, двери или административные границы
BLDG_FLR_ID	String	Уникальный идентификатор этажа. Уникален внутри здания
BOUNDARY_SUBTYPEID	Integer	Поле подтипа базы геоданных для различения граничных объектов: стены, окна и т.д.
NOTES	String	Заметки по границам
SPACE_CATEGORY	String	Код категории классификации пространства
CEILING_HEIGHT	Double	Высота потолка, как расстояние от пола, в футах
BASE_ELEVATION	Double	Базовая высота здания или его части

Подтипы — BOUNDARY_SUBTYPEID
Boundary Line	Граничная линия
Centrline	Ось
Door	Дверь
Exterior Door Line	Внешняя линия двери
Exterior Wall Line	Внешняя линия стены
Phantom	Искусственная линия
Wall	Стена
Window	Окно

Как уже говорилось выше, внутренние геометрические элементы не имеют связанной с ними таблицы детализации.

Внутренние элементы могут быть соотнесены с IFC’s (Industry Foundation Classes). Отношения между элементами обсуждаются ниже.

Стены

Стены, лексическое описание:
http://www.iai-international.org/Model/documentation/IfcR2x_Final/IFCSHAREDBLDGELEMENTS/lexical/IfcWall.html

Обсуждение геометрии IFC (Industry Foundation Classes):
http://www.blis-project.org/private/proposals/IFCR2_WallGeometry_991107_jh.pdf

Пошаговый каталог:
http://www.steptools.com/support/stdev_docs/express/ifc2x3/html/t_ifcwall.html

Проемы

Связь между стенами и проемами:

http://www.iai.fhm.edu/how-to-implement-ifc/Implementer-Agreements/ifc2x3-coordview-agreements/cv-06-134/

Двери

Двери, лексическое описание:

http://www.iai-international.org/Model/documentation/IfcR2x_Final/IFCSHAREDBLDGELEMENTS/lexical/IfcDoor.html

Окна

Окна, лексическое описание:
http://www.iai-international.org/Model/R2x3_final/ifcsharedbldgelements/lexical/ifcwindow.htm

Заключение

Будущие элементы охвата модели — визуализация элементов недвижимости

Случаи использования

Эта часть модели подходит для:

• Визуализация компоновки архитектурных масс для городов;
• Просмотр архитектурного контекста;
• Обзор режима зонирования: высоты строительства и условий видимости.

Визуализация зданий

Для этих целей здания создают в виде объектов polymesh (многогранные сети) с отображением на их внешней стороне фотографий, отображающих их внешний вид. Используется тот же пространственный объект здания, но только применяемые элементы компоновки архитектурных масс. Эти элементы отображаются на CityGML LOD 1 (уровень детализации).

Этот случай использования согласуется с современным уровнем техники с точки зрения визуализации. Это представление играет важную роль в рабочих процессах, где люди пытаются понять отношения искусственной и природной среды. Группа разработчиков модели переместится на эту тему на более поздних фазах.

Элемент данных	Тип	Назначение
Код здания	Буквенно-цифровой	Содержит уникальный идентификатор здания
Компоновка архитектурных масс здания	Polymesh (многогранные сети)	Содержит геометрические данные о компоновке архитектурных масс здания
Фотографии внешней стороны здания	Растр	Содержит коллекцию совокупности внешних сторон здания

Рисунки из gbXML.org

Будущие элементы охвата модели — другие функции

Случаи использования, подходящие для будущих фаз, включают:

• Ориентирование. Как только будет смоделировано внутреннее пространство и его элементы следующим высоко значимым шагом станет добавление внутренней маршрутной сети, информирующей и ориентирующей персонал, посетителей и ремонтников.
• План эвакуации. Сети внутреннего пространства могут также поддерживать планирование эвакуационных выходов и соблюдение зонирования при осуществлении деятельности.

Словарь узкоспециализированных терминов

BIM	Building Information Modeling	Информационная модель здания
CAD	Computer Aided Design	Система автоматизированного проектирования
CAFM	Computer Aided Facility Management	Система автоматизации управления инфраструктурой недвижимости
CRE	Corporate Real Estate	Корпоративная недвижимость
CMMS	Computerized Maintenance Management Systems	Компьютеризированная система управления техническим обслуживанием
ERP	Enterprise Resource Planning	Управление ресурсами предприятия
Feature	An object that has a geographic location or georeferenced shape stored as one of its properties.   Features can be points, lines, polymeshes and other shapes	Пространственный объект — объект, который имеет географическое местоположение или геопривязанную геометрию, хранящуюся как один из его атрибутов. Пространственный объект может быть точкой, линией, Polymesh (многогранной сетью) и др.
Feature Class	A set of features that have the same type of geographic representation and the same attributes	Множество пространственных объектов, которые имеют один и тот же тип представления геометрии и одни и те же атрибуты
GIS	Graphical Information System	ГИС. Географическая информационная система
IWMS	Integrated Workplace Management System	Интегрированная система управления рабочим пространством
Polymesh	A GIS feature used for representing complex 3D objects by tesselating the surface with triangular faces	Многогранные сети. Пространственный объект ГИС, используемый для представления сложных 3D объектов с помощью тесселяции (замощения, автоматизированный процесс добавления новых выпуклых многоугольников в полигональную сетку с целью повышения детализации сетки) поверхности треугольными гранями.

Автор: FFFFF

Источник