Что такое ifc в строительстве

IFC: примеры рабочих процессов

IFC — универсальный формат данных, позволяющий вести обмен информацией между программами, поддерживающими BIM-процесс, произведенными разными вендорами. Если говорить по-простому, то мы можем собрать модель в Revit, экспортировать её в IFC и затем открыть, например, в Archicad или Tekla, ну и наоборот. IFC, в силу своей универсальности, также считается оптимальным форматом для выбора его в качестве основного при выдаче результатов проектирования заказчику. Так, по крайней мере, считают составители стандартов и ГОСТов. Попробуем разобраться, что из себя представляет IFC на самом деле, и какие задачи могут быть решены при использовании этого формата.

Вот какие задачи будем рассматривать:

Перед тем, как перейти к разбору задач, поясню, что IFC имеет различные стандарты (IFC 2×2, IFC 2×3, IFC 4) — по сути, наборы описательных инструкций, где указано, как должен быть представлен элемент модели и его параметры при экспорте в IFC. В стандарте прописан список категорий IFC, и, например, в Revit есть вот такая чудесная табличка, позволяющая настроить соответствие категорий Revit и категорий IFC (аналогичные настройки присутствуют и в других BIM-программах):

1. Корректировка модели (экспорт в IFC из одной программы и открытие модели в другой программе)

Задача номер один, самая очевидная: у нас имеется модель, доставшаяся нам по наследству, в которую нужно внести изменения, и модель эта — в формате IFC. В такой ситуации позавидовать нам сложно, так как импортированная из IFC модель будет структурирована совсем не так, как это принято в той или иной BIM-программе.

Например, если у вас есть дверь в стене, импортированная из IFC, и вы хотите добавить в проект еще одну дверь. При составлении сводной спецификации у первой двери (той, что из IFC) все стандартные параметры такие, как «Ширина», «Высота», «Маркировка типа», окажутся с пустыми значениями.

Надо ли говорить, что элементы, которые в родной программе были параметрическими, перестанут таковыми быть после экспорта в IFC и последующего импорта оттуда? То есть нельзя будет выделить ту же дверь и, перебив значение параметра, поменять её высоту. Так же нельзя будет поменять контур геометрически сложного перекрытия, эскиз лестницы или путь для ограждения. Все элементы превратятся в обычные, не редактируемые параметрически, контекстные компоненты.

Ниже — картинка с примером импортированной из IFC модели (часть геометрии удалилась при импорте, у части были изменены геометрические очертания, геометрия некоторых элементов переведена в mesh):

При импорте будет потеряна и некоторая атрибутивная информация. В случае Revit, например, некорректно будут переданы стадии элементов, значения их геометрических характеристик. Графическая информация (оформленные виды и листы) также будет утеряна.

Подробности процесса экспорта/импорта IFC модели для дальнейшего редактирования описал Егор Глебов в нашем онлайн-курсе «Информационное моделирование зданий» (если вы об этом курсе ранее не слышали, то, можете смело переходить по ссылке, так как все материалы там в открытом доступе).

Вывод

Модели формата IFC не подходят для продолжения работы над ними (редактирования, дополнения) в среде какой-либо BIM-программы. Если возникает подобная задача, то оптимальным выходом будет полное воссоздание геометрии в среде той программы, в которой вы работаете. IFC, в таком случае, будет служить вам как референс, что, правда, в любом случае, лучше, чем ничего или 2D-подложки.

2. Совместная работа по разделам проекта в разных программах

Пожалуй, наиболее часто возникающая задача при использовании IFC.

Пример: существуют две компании, которые работают над проектом совместно, и одна из них использует Revit (где, скажем, выполняются инженерные и конструктивный разделы), другая — Archicad (где разрабатывается архитектурная модель). Стоит задача обмена информацией (моделями) между этими компаниями. В такой ситуации также производится экспорт в IFC, но затем модель не открывается в рабочей среде, а настраивается ссылка на неё. Здесь перестают быть важными аспекты, связанные с возможностью изменения геометрии, так как ничего менять в модели, созданной смежниками, нет необходимости. Нужно просто видеть эту модель и изменять свою на основе полученной информации.

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

Вывод

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

Кстати, IFC может быть использован не только в случае, когда проектные команды работают в разных программах, но и когда они работают, например, в разных версиях Revit или просто не хотят отдавать друг другу изменяемые модели. Но это — уже плохая ситуация, когда участники процесса изначально выбрали неверный путь. BIM — это всё-таки про прозрачность всех процессов и про умение договариваться.

3. Обмен заданиями на проектирование

Для начала стоит пояснить, как задания передаются в случае, когда все специалисты различных отделов работают в Revit.

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

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

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

Вывод

IFC частично подходит для обмена некоторыми видами заданий. Оформленные 2D-задания через IFC передавать нельзя. Потребуется дополнительный процесс экспорта/импорта через формат DWG.

4. Проверка качества модели

Под проверками качества подразумеваются, прежде всего:

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

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

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

Вывод

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

5. Выдача законченного проекта заказчику

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

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

Вывод

IFC не подходит для выдачи законченного проекта заказчику.
__________________________________________________________________________________________

Мой опыт использования IFC все же является достаточно ограниченным, а данная статья была написана лишь потому, что меня попросили поделиться информацией на эту тему (сам бы я её не выбрал).

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

Источник

Что такое BIM и IFC или как упростить работу между проектировщиками, строителями и эксплуатантами?

Что такое IFC и причина его появления.

Для решения проблемы совместимости между приложениями и исключения искажения данных и/или информации был разработан открытый формат файлов IFC (англ. Industry Foundation Classes )

Концепция BIM

Для полного раскрытия сути IFC нужно немного посмотреть в сторону и объяснить концепцию BIM

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

-Заказчик с менеджером проекта определяет концепцию здания и накидывают примерное видение по объекту;

-Архитектор определяет внешнюю и внутреннюю геометрию здания на основе ранее разработанной концепции в соответствие с местными нормами;

-Конструктор разрабатывает несущие конструкции на основе предоставленной ему геометрии здания и вносит в них корректировки совместно с архитектором;

-Инженер коммуникаций размещает оборудование своих систем в образовавшемся объеме и так же, как и конструктор, может передавать архитектору внести изменения в геометрию здания;

-Аналитик, на основе готовой модели, с конструкциями, изоляцией, оборудованием и отделкой проводят расчет энергетики, логистики, вентиляции и прочих систем;

-Менеджер проекта, на основе готовой аналитической модели и архитектуры согласовывают завершение проектирования или внесение правок в проект;

-строитель может просматривать рабочую документацию и узлы при возведение здания

История IFC

В 1994 году промышленный консорциум инвестировал средства в разработку компьютерного кода. Двенадцать американских компаний присоединились к консорциуму, который получил название “ Industry Alliance for Interoperability ” смененное в 1997 на “ International Alliance for Interoperability ”. С 2005 года альянс осуществляет свою деятельность через BuildingSMART.

OpenBIM IFC

Основным требованием для openBIM является использование открытых и нейтральных форматов данных, в то время как формат IFC является наиболее распространенным решением для openBIM.

Сертифицированные приложения для работы с IFC.

Источник

Industry Foundation Classes. Краткое введение

Введение

В связи с политикой Партии и Правительства, происходит активное изменение законодательства в целях внедрения технологии BIM — Информационное моделирование Зданий. В продолжении линии Партии рассмотрим открытый формат представления BIM — IFC (Industry Foundation Classes).

История IFC начинается в 1995 (на самом деле — летом 1993 [1]), когда корпорация Autodesk с группой «товарищей» организовала Картельный сговор с целью разработки обменного формата для различных САПР для проектирования зданий. Через год, товарищи пришли к пониманию, что этот формат должен быть открытым и разрабатываться организацией с открытым членством, так в 1996 появилась International Alliance for Interoperability. Позже, в 2008 году, организация была переименована в buildingSMART — для большей гламурности.

Разработчики IFC не обладали богатым воображением, да и не имели возможности его применить – им были поставлены весьма скромные сроки, а задача выглядела весьма глобально. Поэтому, они взяли за основу формат STEP (Standard for the Exchange of Product model data), а точнее Application Protocol 225: Building Elements. Надо сказать, что вокруг STEP создана богатая инфраструктура в виде кучи спецификаций в статусе ИСО-стандартов. В основе этой инфраструктуры лежит язык моделирования данных EXPRESS и его графическая инкарнация EXPRESS-G, этот язык разрабатывался для удобства автогенерации кода на различных языках программирования.

Разработка IFC началась в Сентябре 1995, IFC 1.0 опубликован в Июне 1996, окончательная редакция в Январе 1997. Фактически целью первой версии IFC — была демонстрации самой возможности реализации задуманной цели, различные компании представили свои демонстрации экспорта/импорта в этот формат.

В Ноябре 1997 вышла следующая версия — 1.5, но попытка её реализация быстро выявило множество ошибок, которые потребовали разработки исправленной версии 1.5.1, которая ввелась параллельно с разработкой версией 2.0 — которая была представлена в Марте 1999.

Все эти версии сейчас признаны устаревшими.

В Ноябре 2000 вышла версия 2.1, это самая старая версия, по которой доступна документация. Позже она была опубликована как ISO/PAS 16739:2005.

Сейчас наиболее распространённая версия (которую понимает большинство программ) — IFC 2.3.

Релиз	Дата	Идентификатор	Документация	ИСО-Стандарт
4.2.0.0	2019	IFC4X2	IFC 4.2
4.1.0.4	2018	IFC4X1	IFC 4.1
4.0.2.1	2017	IFC4	IFC 4.0 Addendum 2 TC1	ISO 16739-1:2017
4.0.2.0	2016	IFC4	IFC 4.0 Addendum 2
4.0.1.0	2015	IFC4	IFC 4.0 Addendum 1
4.0.0.5	2013	IFC4	IFC 4.0	ISO 16739:2013
2.3.0.1	2007	IFC2X3_FINAL	IFC 2×3 TC1
2.3.0.0	2006	IFC2X3_FINAL	IFC 2×3
2.2.1.0	2004	IFC2X2_FINAL	IFC 2×2 Addendum 1
2.2.0.0	2003	IFC2X2_FINAL	IFC 2×2
2.1.1.0	2001	IFC2X_FINAL	IFC 2x Addendum 1
2.1.0.0	2000	IFC2X_FINAL	IFC 2x	ISO/PAS 16739:2005
2.0.0.0	1999	IFC 2.0
1.5.1.0	1998	IFC 1.5.1
1.5.0.0	1997	IFC 1.5
1.0.0.0	1996	IFC 1.0

Для чтения IFC пригодится текстовый редактор с подсветкой синтаксиса, например я использовал n++ и vs code со своими корявыми настройками синтаксиса IFC.

Но ещё необходимым инструментом будет программа способная визуализировать графику в IFC. Сейчас появилось множество вьюверов для этого и даже бесплатных, лично я предпочитаю XbimXplorer от проекта xBIM. Также я использовал Revit, но надо сказать, что чистый Revit не очень дружит с IFC — он даже не способен прочитать файл, который сам создал (да, Revit от Autodesk’а не умеет работать с форматом придуманным Autodesk’ом — это визитная карточка Autodesk’а, просто они не придумали Revit, а купили его — как обычно), но у него есть не плохой плагин для этого — IFC for Revit (пока писал статью — нащёл несколько ошибок, нужно будет исправить, когда будет время. )

Надо сказать, что формат IFC настолько запутанный, что ни одна программа не обрабатывает его правильно — каждая это делает по своему. Так XbimXplorer игнорирует 2d-графику и некоторые синтаксические ошибки.

Описание

Структура файла IFC-SPF описана в ISO 10303-21 (существует ГОСТ ИСО 10303-21-2002) в нотации Вирта. Это текстовый файл, в котором используется только символы с кодами в диапазоне 32-126 (третье издание допускает использование символов с кодами 127-255, но не рекомендуется — для совместимости)
Многострочные комментарии отмечаются парами символов /* */

Для записи символов в другой кодировке предусмотрено несколько способов

Запись ISO 8859:
Директива \S\ — код символа после директивы указывает код символа в таблице ISO 8859-1
Директива \P*\ — здесь вместо * должна стоять заглавная латинская буква, она указывает номер таблицы ISO 8859 которая используется для директивы \S\, A означает ISO 8859-1, B означает ISO 8859-2 и т. д.

Запись ISO 10646:
Директива \X\ — за директивой следует двузначное шестнадцатеричное число указывающее символ в диапазоне от U+0000 до U+00FF
Директивы \X2\*\X0\ и \X4\*\X0\ — здесь вместо * идёт последовательность двузначных (X2) или четырёхзначных (X4) шестнадцатеричных чисел, которые обозначают соответствующие символы

Привет, Мир! => \X2\041F04400438043204350442\X0\, \X2\041C04380440\X0\!

Максимальная длина сырой строки — 32769 байт

Структура файла — файл начинается строкой ISO-10303-21; и заканчивается строкой END-ISO-10303-21; правда после ещё может быть секция подписи SIGNATURE_SECTION, но этот вариант я не буду рассматривать.
Между этими строками должна быть секция заголовка HEADER_SECTION, после неё могут быть секции ANCHOR_SECTION и/или REFERENCE_SECTION, а также одна или несколько DATA_SECTION (в IFC только одна)

Структура заголовочной секции HEADER_SECTION — IFC допускает лишь три элемента в этой секции: FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA

ENTITY file_description;
description : LIST [1:?] OF STRING (256) ;
implementation_level : STRING (256) ;
END_ENTITY;

Минимальный вариант:
FILE_DESCRIPTION((‘ViewDefinition [CoordinationView_V2.0]’),’2;1′);
Содержимое description очень важно для IFC – здесь перечисляются используемые дополнения ViewDefinition, содержание ExchangeRequirement и опции Option[2], но обязательным является только элемент ViewDefinition
implementation_level состоит из двух цифр, первая обозначает редакцию ISO-10303-21 (их три), вторая – режим совместимости (их два), описаны в п.4.3 ISO-10303-21. Для IFC implementation_level всегда имеет значение — 2;1

Ещё вариант:
FILE_DESCRIPTION( (‘ViewDefinition [CoordinationView_V2.0, QuantityTakeOffAddOnView]’, ‘ExchangeRequirement[Structural]’),’2;1′);

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

ENTITY file_schema;
schema_identifiers : LIST [1:?] OF UNIQUE schema_name;
END_ENTITY;

Имя схемы, в которой описано содержание секции данных (смотри столбец Идентификатор в таблице выше)

Секция данных начинается с ключевого слова DATA; и заканчивается ENDSEC;. Содержимым этой секции является последовательность сущностей следующего синтаксиса:
# = ( );
Возможные сущности и их параметры описаны в IFC-схеме.

Пустой IFC файл:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION((‘ViewDefinition [CoordinationView_V2.0]’),’2;1′);
FILE_NAME(»,»,(»),(»),»,»,»);
FILE_SCHEMA((‘IFC2X3’));
ENDSEC;
DATA;
ENDSEC;
END-ISO-10303-21;

Секция данных

Корневым элементом IFC является IfcProject. Тут надо рассказать, как формируется список атрибутов, нужный для создания сущности, во-первых, сущность может иметь собственные атрибуты, а во-вторых она может унаследовать их от предка, порядок атрибутов задаётся — от предка к потомку. Для IfcProject цепочка наследования будет следующая: IfcRoot=>IfcObjectDefinition=>IfcObject=>IfcProject.

— опциональные и текстовые (IfcLabel, IfcText) — описание проекта для человека

RepresentationContexts – это список пространств/контекстов, идея была в том, что у нас может быть несколько пространств/контекстов, например: эскиз, проект и рабочая документация. И разные объекты могут иметь разное представление в разных контекстах. Например, стена в эскизе – просто линия, в проекте уже имеет толщину, а в рабочей документации – состоит из разных слоёв. Но в IFC2x3 концепция поменялась, контексты ‘Sketch’, ‘Outline’, ‘Design’, ‘Detail’ или отменили или они переехали в IfcGeometricRepresentationSubContext. А сам класс IfcRepresentationContext стал абстрактным, с единственным потомком – IfcGeometricRepresentationContext, который может быть объёмным ContextType = ‘Model’, CoordinateSpaceDimension = 3, плоским ContextType = ‘Plan’, CoordinateSpaceDimension = 2 и фиг знает каким ContextType = ‘NotDefined’.

UnitsInContext – объект IfcUnitAssignment, формирующий список элементов IfcUnit с описанием единиц измерения проекта, нужно для правильного импорта, иначе софт будет применять свои настройки по умолчанию – в Revit’е например стоят футы (он всё хранит в футах).

#2= IFCSIUNIT(*,.LENGTHUNIT. MILLI. METRE.);
#3= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#4= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#5= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#6= IFCUNITASSIGNMENT((#2,#3,#4,#5));

От корневого элемента IfcProject формируется дерево элементов, наследников типа IfcSpatialStructureElement (IfcBuilding (здание), IfcBuildingStorey (этаж), IfcSpace (пространство или помещение), IfcSite (участок)). Но эти элементы связываются не на прямую, а через специальный элемент IfcRelAggregates, отношением один-к-многим.

Эти элементы могут быть связанны только в следующем порядке: IfcSite=>IfcBuilding=>IfcBuildingStorey=>IfcSpace, а также могут быть связанны однотипные элементы, но тогда их атрибут CompositionType должен иметь разное значение и только в определённом порядке COMPLEX=>ELEMENT=>PARTIAL

Полная возможная структура проекта:
IfcSite.COMPLEX=>IfcSite.ELEMENT=>IfcSite.PARTIAL=> IfcBuilding.COMPLEX=>IfcBuilding.ELEMENT=>IfcBuilding.PARTIAL=> IfcBuildingStorey.COMPLEX=>IfcBuildingStorey.ELEMENT=>IfcBuildingStorey.PARTIAL=> IfcSpace.COMPLEX=> IfcSpace.ELEMENT=>IfcSpace.PARTIAL

ifc-файл

Хотя все элементы не обязательные, обязателен лишь порядок наследования
Предпологоается, что вы описываете Здание (Building), которое состоит из этажей (Storey) и в которых существуют помещения (Space), вам нужно показать существующий рельеф (Site) в который вы вписываете своё здание

Атрибут Representation, унаследованный от IfcProduct, указывает на объект IfcProductRepresentation, имеет двух потомков IfcProductDefinitionShape – для описания формы объекта и IfcMaterialDefinitionRepresentation – описания материала (стиля визуализации), они через атрибут Representations связывают различные представления.

IfcMaterialDefinitionRepresentation для Representations принимает только IfcStyledRepresentation — описания стиля
Атрибут RepresentedMaterial даёт текстовое описание материала объекта.
IfcProductDefinitionShape для Representations принимает только IfcShapeRepresentation или IfcTopologyRepresentation (IfcShapeModel)

IfcShapeRepresentation самый важный в IFC класс, потому что отвечает за геометрическое представление объектов. Доступные типы геометрии: Curve2D (плоские линии), GeometricSet (точки, линии, поверхности, 2d и 3d), SurfaceModel (поверхности), SolidModel (тела), дополнительные типы (BoundingBox, SectionedSpine, MappedRepresentation)

ProfileType – тип профиля enum-значение типа IfcProfileTypeEnum (Значения: CURVE,AREA). Опциональное имя профиля ProfileName, размещение Position и размер по координатам X Y – XDim, YDim.

Или более сложный IfcFacetedBrep он состоит из одной закрытой оболочки IfcClosedShell, которая в свою очередь состоит из списка граней IfcFace, которые состоят из рёбер IfcFaceBound, которые описаны петлями IfcLoop, которые уже состоят из точек IfcCartesianPoint. Граничное представление (brep) диктует массу условий на свою структуру – подробно описанные в документации и соответствующей литературе.

#57= IFCSHAPEREPRESENTATION(#7, ‘Body’, ‘Brep’, (#58));
#58= IFCFACETEDBREP(#59);
#59= IFCCLOSEDSHELL((#80, #81, #82, #83, #84, #85));

#60 = IFCCARTESIANPOINT((0.,0.,0.));
#61 = IFCCARTESIANPOINT((1.,0.,0.));
#62 = IFCCARTESIANPOINT((1.,1.,0.));
#63 = IFCCARTESIANPOINT((0.,1.,0.));
#64 = IFCCARTESIANPOINT((0.,0.,1.));
#65 = IFCCARTESIANPOINT((1.,0.,1.));
#66 = IFCCARTESIANPOINT((1.,1.,1.));
#67 = IFCCARTESIANPOINT((0.,1.,1.));

#68= IFCPOLYLOOP((#60, #61, #62, #63));
#69= IFCPOLYLOOP((#64, #65, #66, #67));
#70= IFCPOLYLOOP((#60, #61, #65, #64));
#71= IFCPOLYLOOP((#61, #62, #66, #65));
#72= IFCPOLYLOOP((#62, #63, #67, #66));
#73= IFCPOLYLOOP((#63, #60, #64, #67));

#80= IFCFACE((#74));
#81= IFCFACE((#75));
#82= IFCFACE((#76));
#83= IFCFACE((#77));
#84= IFCFACE((#78));
#85= IFCFACE((#79));

В IFC4 появился IfcAdvancedBrep, грани которого могут быть описаны NURBS-кривыми

Объекты IfcSpatialStructureElement могут иметь собственную геометрию, но вообще то здания состоят из других объектов: стен, полов, крыш, окон, дверей и т. д. В IFC все эти объекты описываются соответствующими объектами: IfcWall, IfcSlab, IfcRoof, IfcWindow, IfcDoor – все они являются потомками IfcProduct. Все эти объекты могут быть связанны с соответствующим объектом IfcSpatialStructureElement, через специальный объект IfcRelContainedInSpatialStructure

Для стен постоянной толщины принято использовать IfcWallStandardCase (в IFC4 считается устаревшим), для остальных случаев используем IfcWall. В случае IfcWallStandardCase нужно использовать SweptSolid – выдавливающий контур стены на заданную высоту

#8= IFCAXIS2PLACEMENT3D(#10,$,$);
#10= IFCCARTESIANPOINT((0.,0.,0.));
#13= IFCLOCALPLACEMENT($,#8);
#22= IFCDIRECTION((0.,0.,1.));
#23= IFCAXIS2PLACEMENT2D(#24,#25);
#24= IFCCARTESIANPOINT((0.,0.));
#25= IFCDIRECTION((1.,0.));
#26= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs107′,$,’wall1’,$,»,#13,#27,»);
#27= IFCPRODUCTDEFINITIONSHAPE($,$,(#28));
#28= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#29));
#29= IFCEXTRUDEDAREASOLID(#30,#32,#22,1000.);
#30= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,100.,1000.);
#31= IFCCARTESIANPOINT((500.,0.,100.));
#32= IFCAXIS2PLACEMENT3D(#31,$,$);

Дверь описывается объектом IfcDoor, его можно добавить в IfcRelContainedInSpatialStructure, но этот объект не делает «вырез» в стене для себя

За «вырез» отвечает специальный объект IfcOpeningElement, который связывается с «родительским» объектом через IfcRelVoidsElement. В IfcOpeningElement можно «вставить» дверь, с помощью объекта IfcRelFillsElement. С помощью IfcOpeningElement можно делать не только сквозные отверстия, но и углубления.

Объект IfcWindow сильно похож в использовании, на IfcDoor, OverallHeight, OverallWidth — номинальные габариты, можно не указывать – тогда эти значения будут браться из геометрии

Пишем IFC

Дальше, мы должны наполнить содержанием DATA-секцию. Первым обязательным обектом должен быть IFCPROJECT (хотя он может быть и в конце файла, но он просто должен быть), также нам понадобится IFCUNITASSIGNMENT, если мы конечно хотим, что бы программы читали модель в тех еденицах измерения, которые мы задумали. Так же нам понадобится, хотя бы один IFCGEOMETRICREPRESENTATIONCONTEXT — иначе мы не сможем добавить описание геометрии.

/* Единицы измерений модели */
#2= IFCSIUNIT(*,.LENGTHUNIT. MILLI. METRE.);
#3= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#4= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#5= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#6= IFCUNITASSIGNMENT((#2,#3,#4,#5));

/* Контекст */
#7= IFCGEOMETRICREPRESENTATIONCONTEXT($,’Model’,3,0.01,#8,#9);
#8= IFCAXIS2PLACEMENT3D(#10,$,$);
#9= IFCDIRECTION((0.,1.));
#10= IFCCARTESIANPOINT((0.,0.,0.));

#16= IFCRELCONTAINEDINSPATIALSTRUCTURE(‘abcdefghijklmnopqrs105’,$,$,$,(#17, #26, #33, #39, #46, #57, #94, #101),#14);

#26= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs107′,$,’wall1’,$,»,#13,#27,»);
#27= IFCPRODUCTDEFINITIONSHAPE($,$,(#28));
#28= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#29));
#29= IFCEXTRUDEDAREASOLID(#30,#32,#22,1000.);
#30= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,100.,1000.);
#31= IFCCARTESIANPOINT((500.,0.,100.));
#32= IFCAXIS2PLACEMENT3D(#31,$,$);

#33= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs108′,$,’wall2’,$,»,#13,#34,»);
#34= IFCPRODUCTDEFINITIONSHAPE($,$,(#35));
#35= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#36));
#36= IFCEXTRUDEDAREASOLID(#30,#38,#22,1000.);
#37= IFCCARTESIANPOINT((-500.,0.,100.));
#38= IFCAXIS2PLACEMENT3D(#37,$,$);

#39= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs110′,$,’wall3’,$,»,#13,#40,»);
#40= IFCPRODUCTDEFINITIONSHAPE($,$,(#41));
#41= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#42));
#42= IFCEXTRUDEDAREASOLID(#43,#45,#22,1000.);
#43= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,1000.,100.);
#44= IFCCARTESIANPOINT((0.,-500.,100.));
#45= IFCAXIS2PLACEMENT3D(#44,$,$);

#46= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs109′,$,’wall4’,$,»,#13,#47,»);
#47= IFCPRODUCTDEFINITIONSHAPE($,$,(#48));
#48= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#49));
#49= IFCEXTRUDEDAREASOLID(#50,#52,#22,1000.);
#50= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,1000.,100.);
#51= IFCCARTESIANPOINT((0.,500.,100.));
#52= IFCAXIS2PLACEMENT3D(#51,$,$);

#57= IFCDOOR(‘abcdefghijklmnopqrs111′,$,’door’,$,»,#88,#86,»,$,$);
#86= IFCPRODUCTDEFINITIONSHAPE($,$,(#87));
#87= IFCSHAPEREPRESENTATION(#7,’Body’,’Brep’,(#58));

#58= IFCFACETEDBREP(#59);
#59= IFCCLOSEDSHELL((#80, #81, #82, #83, #84, #85));

#60 = IFCCARTESIANPOINT((0.,0.,0.));
#61 = IFCCARTESIANPOINT((200.,0.,0.));
#62 = IFCCARTESIANPOINT((200.,200.,0.));
#63 = IFCCARTESIANPOINT((0.,200.,0.));
#64 = IFCCARTESIANPOINT((0.,0.,500.));
#65 = IFCCARTESIANPOINT((200.,0.,500.));
#66 = IFCCARTESIANPOINT((200.,200.,500.));
#67 = IFCCARTESIANPOINT((0.,200.,500.));

#68= IFCPOLYLOOP((#60, #61, #62, #63));
#69= IFCPOLYLOOP((#64, #65, #66, #67));
#70= IFCPOLYLOOP((#60, #61, #65, #64));
#71= IFCPOLYLOOP((#61, #62, #66, #65));
#72= IFCPOLYLOOP((#62, #63, #67, #66));
#73= IFCPOLYLOOP((#63, #60, #64, #67));

#80= IFCFACE((#74));
#81= IFCFACE((#75));
#82= IFCFACE((#76));
#83= IFCFACE((#77));
#84= IFCFACE((#78));
#85= IFCFACE((#79));

#88= IFCLOCALPLACEMENT($,#89);
#89= IFCAXIS2PLACEMENT3D(#90,$,$);
#90= IFCCARTESIANPOINT((-100.,400.,100.));

#91= IFCRELVOIDSELEMENT(‘abcdefghijklmnopqrs112’,$,$,$,#46,#92);
#92= IFCOPENINGELEMENT(‘abcdefghijklmnopqrs113′,$,$,$,’Opening’,#88,#86,$);
#93= IFCRELFILLSELEMENT(‘abcdefghijklmnopqrs114’,$,$,$,#92,#57);

Для описания двери мы используем IFCFACETEDBREP и его используем для IFCOPENINGELEMENT в который вставленна наша дверь. Используя разные IFCLOCALPLACEMENT мы можем вставить одну и туже геометрию в разные места и для представления разных объектов — например можем использовать тот же IFCFACETEDBREP для окна.

#94= IFCWINDOW(‘abcdefghijklmnopqrs115’,$,$,$,$,#95,#86,$,$,$);
#95= IFCLOCALPLACEMENT($,#96);
#96= IFCAXIS2PLACEMENT3D(#97,$,$);
#97= IFCCARTESIANPOINT((-100.,-600.,400.));

#98= IFCRELVOIDSELEMENT(‘abcdefghijklmnopqrs116’,$,$,$,#39,#99);
#99= IFCOPENINGELEMENT(‘abcdefghijklmnopqrs117′,$,$,$,’Opening’,#95,#86,$);
#100= IFCRELFILLSELEMENT(‘abcdefghijklmnopqrs118’,$,$,$,#99,#94);

Заключение

Теперь, мой дорогой читатель, ты можешь написать дом свой мечты. К сожалению я не расмотрел IfcMaterialDefinitionRepresentation который отвечат за стиль отображения объектов, не расмотрел IfcTopologyRepresentation — не очень понимаю для чего он служит и не знаю как его визуалезировать. Не расмотрел опции IFC и дополнительный набоы свойств. Но иначе это не было бы кратким введением.

Формат IFC содержит огромное количество объектов, которое становится лишь больше от версии к версии. В тексте спецификации встречаются примечания, которые не отраженны в EXPRESS-схеме, но при этом сильно влияют на обработку файла. По этому трудно реализовать этот формат, не прочитав внимательно всю документацию, но это врядли возможно одному человеку, по этому не существует программы — которая читает его абсолютно правильно, каждая имеет свои особенности. И если в случае open source программ всегда есть возможность исправить обнаруженные ошибки, для проприетарных программ это приводит к невозможности полноценного использования формата IFC.

Формат IFC абсолютно не приспособлен для хранения информации раздела генплана, но в настоящее время идёт активная работа над этим разделом, эта работа должна быть закончена к концу Апреля 2020 и войти в состав IFC5. Так же сейчас идёт работа над IFC Road, IFC Airport и IFC4precast (сборный железобетон). В IFC4x2 появился IFC Bridge, для котрого придумали специальный геометрический объект — IfcSectionedSolidHorizontal

Последние изменения IFC сильно сближают его с GML, даже появился IfcCoordinateReferenceSystem — описание геодезической системы координат. При этом IFC делает упор на описание внутренних структур объекта, а GML описывает его внешнее представление. Но главным отличием IFC является возможномть ссылатся на одни и тежи объекты в разных местах — одна и таже точка, может быть использованна в описании геометрии стены и окна. В GML же, каждый геометрический объект — абсолютно независим.

Источник