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

Специалисты по картам ушли в создание геоинформационных систем (ГИС), если отвлечься от некоторых различий между большими и маленькими вендорами, то выработался, по сути, единый подход: использовать мощные СУБД для хранения не только привычной атрибутивной информации, но и пространственных данных. Благо, и проприетарные СУБД (тут «пионером» был Oracle, но и остальные не дремали), и свободно распространяемые СУБД (PostgreSQL с PostGIS) предоставили возможность хранить пространственные данные собственными средствами. Это тут же решило многие проблемы с хранением больших объемов пространственных данных, регламентации доступа к ним, индексации для быстрого поиска, построения аналитических запросов.

Любители «изобрести велосипед» и делать все это по-своему, конечно, поупирались, но вынуждены были сдаться, оставшись только в тех отраслях знаний, где понятность и прозрачность никак не приветствуется (оборонная сфера, к примеру). Для всех остальных поддержка хранения пространственных данных собственными средствами СУБД стала буквально «маст-хэв». А получилась эта «базификация» удачной ровно потому, что пространственные объекты, которые можно найти на карте, можно представить в виде нескольких «атомарных» типов объектов, с которыми СУБД уверенно научились работать: точка, линия, полигон, а разные подходы в используемых системах координат разработчикам СУБД также удалось нивелировать, введя в СУБД понятие их стандартизованного описания (SRID – Spatial Reference ID). После этого построение той или иной ГИС для города, страны, отрасли, различными исполнителями перестало отличаться кардинально, разнясь только выбранными СУБД и специализированным программным обеспечением для манипулирования данными и для разработки пользовательских приложений.

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

Почувствуйте разницу: если на карте появился новый газопровод, то расположенные рядом русло реки или автострада автоматически меняться от этого никак не обязаны, а вот замена типоразмера окон в объекте автоматически должна за собой потянуть именно обязательные изменения (меняется размер проема в стене, может поменяться способ установки окна, что может привести к изменению прочностных характеристик стены, и так далее). Так что, компоненты строительного проекта по определению – сложные и иерархические. Вследствие этого фундаментального различия, вместо логичной, но недостижимой «базификации» начали развиваться отдельные замкнутые экосистемы, умеющие оперировать такими сложными и затейливо связанными между собой составными объектами. Тот самый BIM.

Но что же делать, если все же нужно управлять всей территорией города, региона, страны, крупного промышленного комплекса, которая, по определению, описывается и пространственными (картографическими) данными, и строительными проектами? Как соединить технологии ГИС и BIM?

Есть, конечно коварные предложения от двух известных вендоров, успешно работающих в областях ГИС и BIM (ESRI-Autodesk), вот-де, мы эти свои технологии прекрасно связали между собой, вэлком, дорогие гости! Но это привлекательное предложение подозрительно похоже на рекламу Форда в начале его деятельности про то, что можно выбрать автомобиль любого цвета, при условии, что он черный. Ведь по сути предлагается для ГИС строго использовать программное обеспечение именно ESRI, а для BIM – исключительно Autodesk. Никак не ставя под сомнение впечатляющие достижения каждого из упомянутых вендоров в своей рыночной нише, хочется все же некоторой свободы выбора, поэтому мы считаем разумным избегать жесткой привязки к каким-либо технологиям ГИС или BIM.

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

А с BIM-технологиями, в силу невозможности по описанным выше причинам, применения «базификации», пришлось искать другой подход, и он был найден нами в гарантированно поддерживаемом любым BIM-вендором обменном формате IFC. Разумеется, впрямую использовать этот громоздкий файл неудобно, а вот если именно его, а не исходную BIM-модель, быстро «разобрать» и положить в СУБД, то, наконец, появляется возможность создания единого информационного пространства ГИС-BIM, в полной мере описывающего всю территорию. Причем формирование и постоянное обновление этого единого информационного пространства как раз и происходит с помощью совершенно произвольного набора ГИС и BIM инструментов, привычных и удобных заказчику такого проекта.

 

 

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

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

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

 

 

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