Все руководства ifc

Стандарты и методики

• Стандарты OpenBIM
• BIM стандарты Великобритании
• BIM стандарты США
• Стандарт IFC

Стандарты OpenBIM

5 базовых OpenBIM стандартов

Наименование	Стандарт	Назначение
IDM (Information Delivery Manual)	ISO 29481−1:2016 ISO 29481−2:2012	Описание бизнес процессов
IFC (Industry Foundation Classes)	ISO 16739:2013	Описание передачи информации / данных
BCF (BIM Collaboration Format)	buildingSMART BCF	Описание взаимодействия между BIM приложениями
IFD (International Framework for Dictionaries)	ISO 12006−3:2007 buildingSMART Data Dictionary	Описание условий преобразования данных
MVD (Model View Definitions)	buildingSMART MVD	Описание преобразования процессов в технические требования

наверх

BIM стандарты Великобритании

В таблице приведены стандарты BIM для AEC отрасли в Великобритании. Ссылка на источник.

Наименование	Дополнительная информация
AEC (UK) BIM Протоколы
AEC (UK) BIM Technology Protocol v2.1	Главный документ
AEC (UK) BIM Protocol v2.0	Перевод на русский язык
AEC (UK) BIM Protocol — BIM Execution Plan v2.0
AEC (UK) BIM Protocol — Model Matrix v2.0
AEC (UK) BIM Protocol For Autodesk Revit v2.0	Дополнительный документ для Autodesk Revit
AEC (UK) BIM Protocol For Autodesk Revit — Model Validation Checklist v2.0	Дополнительный документ для Autodesk Revit
AEC (UK) BIM Protocol For Bentley ABD v2.0	Дополнительный документ для Bentley AECOsim Building Designer
AEC (UK) BIM Protocol For Bentley ABD — Model Validation Checklist v2.0	Дополнительный документ для Bentley AECOsim Building Designer
AEC (UK) BIM Technology Protocol For Archicad v2.0	Дополнительный документ для Archicad
AEC (UK) BIM Technology Protocol For Archicad — Template Checklist v2.0	Дополнительный документ для Archicad
AEC (UK) BIM Technology Protocol For Archicad — Model Validation Checklist For Import v2.0	Дополнительный документ для Archicad
AEC (UK) BIM Technology Protocol For Archicad — Model Validation Checklist For Export v2.0	Дополнительный документ для Archicad
AEC (UK) BIM Protocol For Nemetschek Vectorworks v1.2
AEC (UK) CAD Стандарты
AEC (UK) Protocol For Layer Naming — v4.0.2

наверх

BIM стандарты США

Ссылка на источник. Предварительно нужна регистрация.

National BIM Standard-United States® (NBIMS-US™) — версия 2 — 2012 г. — скачать — файл .zip (15 Мбайт)

National BIM Standard-United States® (NBIMS-US™) — версия 3 — 2015 г. — скачать — файл .zip (86 Мбайт)

Архив содержит файлы .pdf, собранные по разделам.

Содержание стандарта National BIM Standard-United States® версии 3 представлен в таблице.

Раздел	Дополнительная информация
FOREWORD
ACKNOWLEDGMENTS
1 SCOPE
2 REFERENCE STANDARDS
2.1 Introduction to Reference Standards
2.2 ISO 16739, Industry Foundation Class 2X3	Февраль 2006 г. *
2.3 W3C XML 1.0 Fifth Edition	Ноябрь 2008 г. *
2.4 OmniClass™
2.4.4.1 Table 11 — Construction Entities by Function	Февраль 2013 г.
2.4.4.2 Table 12 — Construction Entities by Form	Октябрь 2012 г.
2.4.4.3 Table 13 — Spaces by Function	Май 2011 г. *
2.4.4.4 Table 21 — Elements	Февраль 2011 г. *
2.4.4.5 Table 22 — Work Results	Август 2013
2.4.4.6 Table 23 — Products	Июнь 2010 г. *
2.4.4.7 Table 31 — Phases	Октябрь 2012 г.
2.4.4.8 Table 32 — Services	Июнь 2010 г. *
2.4.4.9 Table 33 — Disciplines	Октябрь 2012 г.
2.4.4.10 Table 34 — Organizational Roles	Октябрь 2012 г.
2.4.4.11 Table 36 — Information	Июнь 2010 г. *
2.4.4.12 Table 41 — Materials	Октябрь 2012 г.
2.4.4.13 Table 49 — Properties	Октябрь 2012 г.
2.5 International Framework for Dictionaries (IFD)/buildingSMART Data Dictionary (BSDD)	Май 2012 г. *
2.6 BIM Collaboration Format (BCF)	Версия 1.0
2.7 LOD Specifications	Август 2013 г.
2.8 United States National CAD Standard® (NCS)	Версия 5
3 TERMS AND DEFINITIONS
4 INFORMATION EXCHANGE STANDARDS
4.1 Introduction to Information Exchange Standards
4.2 Construction Operations Building information exchange (COBie) Annex A — COBie Mapping Rules Annex B — Life Cycle information exchange (LCie) for Product and Product Type Data Exchanges	Версия 2.4
4.3 Design to Spatial Program Validation (SPV)	*
4.4 Design to Building Energy Analysis (BEA)	*
4.5 Design to Quantity Takeoff for Cost Estimating (QTO)	*
4.6 Building Programming information exchange (BPie)	Версия 1.0
4.7 Electrical information exchange (SPARKie)	Издание 2013 г.
4.8 Heating, Ventilation and Air Conditioning information exchange (HVACie)	Издание 2013 г.
4.9 Water Systems information exchange (WSie)	Издание 2013 г.
5 PRACTICE DOCUMENTS
5.1 Introduction to Practice Documents
5.2 Minimum BIM	2-е издание
5.3 BIM Project Execution Planning Guide	Версия 2.1 *
5.4 BIM Project Execution Plan Content	Версия 2.1 *
5.5 Mechanical, Electrical, Plumbing and Fire Protection Systems Spatial Coordination Requirements for Construction Installation Models and Deliverables	Май 2012 г. *
5.6 Planning, Executing and Managing Information Handover	*
5.7 BIM Planning Guide for Facility Owners
5.8 Practical BIM Contract Requirements
5.9 The Uses of BIM
ANNEX A — NATIONAL BIM STANDARD — UNITED STATES PROJECT COMMITTEE RULES OF GOVERNANCE
ANNEX B — UNITED STATES NATIONAL BUILDING INFORMATION MODELING STANDARD™	Версия 1. Первая часть (обзор, принципы и методология) — Декабрь 2007 г. *

* — Содержание раздела не изменилось с версии 2.

наверх

Стандарт IFC

Форматы стандарта IFC

Формат	Описание	Иконка
.ifc	IFC файл данных, использующий физическую файловую структуру обмена данными о модели изделия STEP (от англ. STandard for the Exchange of Product data) согласно ISO 10303−21. Файл *.ifc подтверждается согласно спецификации IFC-EXPRESS. Этот формат используется по умолчанию для обмена IFC данными.
.ifcXML	IFC файл данных, использующий структуру документа XML. Он может быть получен непосредственно из приложения или с помощью файла *.ifc, используя конвертацию согласно ISO 10303−28 (XML представления схем и данных EXPRESS). Файл формата .ifcXML обычно на 300−400% больше файла формата .ifc.
.ifcZIP	IFC файл данных, использующий алгоритм сжатия PKzip 2.04g (например, совместим с winzip, zlib, info-zip и др.). Требуется один .ifc или. ifcXML файл данных в главной директории zip архива. Файл формата .ifcZIP обычно сжимает файл формата .ifc на 60−80% и файл формата. ifcXML — на 90−95%.

наверх

Версии стандарта IFC

Обозначение	Описание
IFC5	На данный момент находится в начальной стадии планирования. Ожидается полная поддержка для различных доменов инфраструктуры и больше параметрических возможностей.
IFC4 Add2	Второе дополнение к версии IFC4. Версия IFC4 Add2 вышла в июле 2016 г. как buildingSMART стандарт.
IFC4 Add1	Первое дополнение к версии IFC4, включающее улучшения, которые были выявлены во время экспериментальных внедрений и разработки MVD. Версия IFC4 Add1 вышла в июле 2015 г. как buildingSMART стандарт.
IFC4	Изначально IFC2x4. Была выпущена как новая IFC платформа на годы вперед. Версия IFC4 вышла в марте 2013 г.
IFC2x3-TC1	IFC2x Edition 3 Technical Corrigendum 1 (IFC2x Выпуск 3 Технические поправки 1). Версия была выпущена в июле 2007 г. для внесения поправок в версию IFC2х3.
IFC2x3	IFC2x Edition 3 (IFC2x Выпуск 3) — третий выпуск платформы IFC2x. В основном изменения касались качественного улучшения версии IFC2x2. Версия была выпущена в феврале 2006 г.
IFC2x2-Add1	IFC2x Edition 2 Addendum 1 (IFC2x Выпуск 2 Дополнение 1) — маленькое дополнение версии IFC2x для фиксации выпусков, которые были сделаны во время внедрения. Версия была выпущена в июле 2004 г.
IFC2x2	IFC2x Edition 2 (IFC2x Выпуск 2) — второй выпуск платформы IFC2x. Были сделаны некоторые улучшения в предметной области знаний. Версия была выпущена в мае 2003 г.
IFC2x-Add1	IFC2x Addendum 1 (IFC2x Дополнение 1) — маленькое дополнение версии IFC2x для фиксации выпусков, которые были сделаны во время внедрения. Версия была выпущена в октябре 2001 г. Эта версия использовалась для сертификации и внедрения IFC 2x.
IFC2x	IFC2x — первый выпуск платформы IFC2x. Версия была выпущена в октябре 2000 г. В основном, внимание было уделено обеспечению стабильности работы платформы.
IFC2.0 IFC1.5.1 IFC1.5 и IFC1.0	Эти версии с течением времени устарели и не упоминаются больше.

наверх

Что включает в себя версия стандарта IFC?

Каждая версия стандарта включает в себя следующие спецификации:

• html документация спецификации IFC (включая все определения, схемы, библиотеки):
  • для версии IFC4 Add2
  • для версии IFC4 Add1
  • для версии IFC4
  • для версии IFC2x3 TC1
  • для версии IFC2x3
• URL для схемы IFC EXPRESS:
  • для версии IFC4 Add2
  • для версии IFC4 Add1
  • для версии IFC4
  • для версии IFC2x3 TC1
  • для версии IFC2x3
• URL для схемы ifcXML XSD
  • для версии IFC4 Add2
  • для версии IFC4 Add1
  • для версии IFC4
  • для версии IFC2x3

наверх

Сертифицированное программное обеспечение по стандарту IFC

Сертифицированное компанией buildingSMART® программное обеспечение по стандарту IFC2x3 вы можете посмотреть здесь.

Руководства по внедрению стандарта IFC в BIM-приложения

Более 150 приложений поддерживают импорт и/или экспорт данных по стандарту IFC. Этот стандарт становится открытым стандартом для BIM данных.

buildingSMART поддерживает фреймворк для компаний, разрабатывающих программное обеспечение, чтобы сотрудничать в поддержке открытых стандартов для BIM. Создана специальная группа поддержки внедрения — ISG (Implementation Support Group), главной задачей которой является поддержкой во внедрении и сертификации стандартов buildingSMART. Любая компания, занимающаяся разработкой программного обеспечения, являющаяся членом местного или регионального отделения buildingSMART, может стать участником этой группы.

Существуют руководства по внедрению стандарта IFC, полезные для разработчиков программного обеспечения:

• руководство по внедрению секции заголовка для файла стандарта IFC — IFC header implementation guide — содержит данные:
  • о версии IFC схемы;
  • об описании содержания и опций, используемых для создания файла;
  • об имени файла, его авторах, приложении, которое создало этот файл и IFC трансляторе/обработчике.

  Пример заполнения секции заголовка файла стандарта IFC:

  
  
  
  

  Пример секции заголовка в обменном файле IFC STEP:

  
  
  
  

• руководство по внедрению стандарта IFC — IFC implementation guide — предназначено для общего понимания внедрения стандарта IFC используя технологии внедрения STEP. Руководство по внедрению стандарта IFC не заменяет собой определений и соглашений MVD (Model View Definition). Это руководство описывает секцию данные файла стандарта IFC;
• руководство по внедрению стандарта IFC формата ifcXML — ifcXML Implementation Guide — описывает внутреннюю структуру формата ifcXML, дает определения, поясняет возможные приложения.
  Сравнение описания данных в файлах формата .ifc и .ifcXML:

  
  
  
  

Скачать актуальные версии руководств по внедрению стандарта IFC вы можете здесь.

наверх

Инструментальные средства IFC

Большинство внедрений стандарта IFC среди приложений основаны на специальных инструментальных средствах — средствах, предназначенных для чтения и записи файлов стандарта IFC в формат STEP, а также для создания интерфейсов преобразования сущностей приложений в сущности стандарта IFC и наоборот. API (Application Programming Interface) приложений строится на одном или нескольких языках программирования (например на С++, Java, VB). Инструментальные средства IFC также могут осуществлять постоянное хранение в базе данных, поддерживать чтение и запись файлов формата ifcXML и др. Существуют и другие инструментальные средства, полезные для разработки IFC:

• IFC валидаторы — средства для валидации файла данных IFC в соответствии со схемой стандарта IFC. Эти средства гарантируют, что полученный файл данных IFC построен синтаксически правильно.
• IFC вьюверы — средства, которые читают файл стандарта IFC и отображают изделия, имеющие 3D или 2D геометрию в файле стандарта IFC. Часто такие средства позволяют увидеть структуру проекта (здание, этажи), компоненты (перечень стен, перекрытий) и свойства каждого компонента (групповые свойства и т.д.). Существуют как платные, так и бесплатные IFC вьюверы. Наиболее известные:
  • от компании Solibri — Solibri Model Viewer
  • от компании Data Design System — DDS-CAD Viewer
  • от компании AllPlan — IFC Viewer
  • от компании Trimble Solutions — Tekla BIMsight
  • от компании RDF — IFC Engine Viewer

  Полный перечень IFC вьюверов вы можете посмотреть здесь, раскрыв группировку Model Viewer.

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

наверх

Введение

В связи с политикой Партии и Правительства, происходит активное изменение законодательства в целях внедрения технологии 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.

Софт

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

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

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

Описание

Формат IFC существует в трёх ипостасях: IFC-SPF (.ifc), IFC-XML (.ifcXML), IFC-ZIP (.ifcZIP)
IFC-SPF — это текстовый формат, определённый в ISO 10303-21 — фактически это STEP-файл
IFC-XML — это XML-формат определённый в ISO 10303-28 («STEP-XML»)
IFC-ZIP — zip-архив который может содержать .ifc или .ifcXML

Структура файла 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) шестнадцатеричных чисел, которые обозначают соответствующие символы

Привет, Мир! => X241F04400438043204350442X0, X241C04380440X0!

Максимальная длина сырой строки — 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_name;
name : STRING (256) ;
time_stamp : time_stamp_text ;
author : LIST [ 1 : ? ] OF STRING (256) ;
organization : LIST [ 1 : ? ] OF STRING (256) ;
preprocessor_version : STRING (256) ;
originating_system : STRING (256) ;
authorization : STRING (256) ;
END_ENTITY;

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

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.

IFCPROJECT(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>, <LongName>,<Phase>, (<RepresentationContexts>),<UnitsInContext>);

Теперь для создания IfcProject нам нужно задать значения для всех атрибутов. Первый атрибут, унаследованный от IfcRoot – GlobalId, имеет значение IfcGloballyUniqueId. Это простой тип – строка длиной в 22 символа, в них нужно записать уникальный идентификатор GUID или UUID, что бы 128 битное число упихать в 22 символа – существует специальный алгоритм, опубликованный на сайте buildingSMART[3]. Следующий атрибут OwnerHistory имеет значение IfcOwnerHistory. Этот элемент отвечает на вопросы – кто, как и когда создал этот IFC-элемент, фактически почти для каждого объекта в IFC может быть указан его автор, через этот элемент. Что бы заполнить этот атрибут, можно создать элемент «по месту», но лучше сделать это в другом месте, а на месте просто на него сослаться записью вида #<индекс сущности>. Также символ $ означает null-значение, символ * используется если потомок сам присваивает значению атрибуту предка. Значения типа enum записываются между двумя точками — .ELEMENT.

Пример создания IfcProject:
#1=IFCPROJECT('abcdefghijklmnopqrs101', #2, 'sample project', $, $, '','',$,$);
#2=IFCOWNERHISTORY(#3,#6,.READWRITE.,.ADDED.,87763554,#3,#6,87763554);
#3=IFCPERSONANDORGANIZATION(#4,#5,());
#4=IFCPERSON('Public','Jane','Q.',(),(),(),(),());
#5=IFCORGANIZATION($,'Architecture by Jane Q. Public, Inc.',$,(),());
#6=IFCAPPLICATION(#7,'Version 1.0','Building Architecture Toolkit','BAT1.0');
#7=IFCORGANIZATION($,'Creating Instance Software, Inc.',$,(),());

Следующие элементы <Имя>, <Описание>, <ObjectType>, <LongName>,<Phase> — опциональные и текстовые (IfcLabel, IfcText) — описание проекта для человека

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

IFCGEOMETRICREPRESENTATIONCONTEXT(<Имя>,<Тип>,<Размерность пространства>,<Точность - расстояние на котором точки считаются идентичными>,<Система координат>,<Направление на север>)

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, отношением один-к-многим.

IFCRELAGGREGATES(<GlobalId>, <OwnerHistory>, <Имя>, <Описание>, <Родительский элемент>, (<список потомков>));

Эти элементы могут быть связанны только в следующем порядке: 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) в который вы вписываете своё здание

IFCSITE(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<LongName>,<CompositionType>,<RefLatitude>,<RefLongitude>,<RefElevation>,<LandTitleNumber>,<SiteAddress>);

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

IfcProductDefinitionShape(<Имя>,<Описание>,(<Representations>))
IfcMaterialDefinitionRepresentation(<Имя>, <Описание>,<Representations>),<RepresentedMaterial>)

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

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

IFCSHAPEREPRESENTATION(<контекст>,<RepresentationIdentifier>,<тип геометрии>,<список элементов>);

В основе любой геометрии находится элемент IfcCartesianPoint – просто точка.
#13= IFCCARTESIANPOINT((0.,0.,0.));
#16= IFCCARTESIANPOINT((1.,0.,0.));
#22= IFCPOLYLINE((#13, #16));

#510= IFCBSPLINECURVEWITHKNOTS(3,(#511,#512,#513,#514,#511,#512,#513),.UNSPECIFIED.,.T.,.T.,(1,1,1,1,1,1,1,1,1,1,1),(-7.0,-6.0,-5.0,-4.0,-3.0,-2.0,-1.0,0.0,1.0,2.0,3.0),.UNSPECIFIED.);
#511= IFCCARTESIANPOINT((239.758213537139,192.193559404919,-83.9999999999991));
#512= IFCCARTESIANPOINT((0.0,275.591853484122,-83.9999999999991));
#513= IFCCARTESIANPOINT((-239.75821353295,192.193559404918,-83.9999999999991));
#514= IFCCARTESIANPOINT((0.0,-108.13323051355,-83.9999999999991));

#34= IFCSHAPEREPRESENTATION(#7,'Body','SweptSolid',(#35));
#35= IFCEXTRUDEDAREASOLID(#36,#8,#37,0.5);
#36= IFCRECTANGLEPROFILEDEF(.AREA.,$,#38,0.5,0.5);
#37= IFCDIRECTION((0.,0.,1.));
#38= IFCAXIS2PLACEMENT2D(#39,#9);
#7= IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,0.01,#8,#9);
#8= IFCAXIS2PLACEMENT3D(#10,$,$);
#9= IFCDIRECTION((0.,1.));
#39= IFCCARTESIANPOINT((0.,0.));

Геометрия может состоять просто из списка точек, а может иметь сложную структуру с кучей параметров и дочерних элементов.
Рассмотрим IfcExtrudedAreaSolid(<SweptArea>,<Position>,<ExtrudedDirection>,<Depth>)

Это тело полученное выдавливанием исходного плоского контура SweptArea размещённого в пространстве Position выдавленного в направлении ExtrudedDirection на глубину Depth. Атрибут SweptArea имеет тип IfcProfileDef – это абстрактный класс, имеющий большое количество потомков «на все случаи жизни», в данном случае используется IfcRectangleProfileDef(<ProfileType>,<ProfileName>,<Position>,<XDim>,<YDim>)

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));

#74= IFCFACEOUTERBOUND(#68, .T.);
#75= IFCFACEOUTERBOUND(#69, .T.);
#76= IFCFACEOUTERBOUND(#70, .T.);
#77= IFCFACEOUTERBOUND(#71, .T.);
#78= IFCFACEOUTERBOUND(#72, .T.);
#79= IFCFACEOUTERBOUND(#73, .T.);

#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

IFCRELCONTAINEDINSPATIALSTRUCTURE(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>, (<RelatedElements>),<RelatingStructure>)

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

IFCWALLSTANDARDCASE(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>);

#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 можно делать не только сквозные отверстия, но и углубления.

IFCDOOR(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<OverallHeight>,<OverallWidth>)

IFCWINDOW(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<OverallHeight>,<OverallWidth>)

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

Объект IfcRoof подразумевается сложным объектом – он должен описывать всю кровлю, для связи всех дочерних элементов с ним – нужно использовать IfcRelAggregates. Но при этом IfcRoof может иметь собственую геометрию Representation.
IFCSLAB(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<PredefinedType>);
IFCROOF(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<IfcRoofTypeEnum>);

Пишем IFC

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

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

Структура дома

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

готовый файл

Заключение

Теперь, мой дорогой читатель, ты можешь написать дом свой мечты. К сожалению я не расмотрел 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 же, каждый геометрический объект — абсолютно независим.

Ссылки:

1.

www.ibpsa.org/proceedings/BS1997/BS97_P125.pdf

2.

standards.buildingsmart.org/documents/Implementation/ImplementationGuide_IFCHeaderData_Version_1.0.2.pdf

3.

technical.buildingsmart.org/resources/ifcimplementationguidance/ifc-guid

IFC Specifications Database

Official releases of the IFC specification are listed here, as well as their components including HTML, EXPRESS, XSD/XML, and OWL documentation and formats.

Release Notes and Errata for all versions can be found here.

IFC is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/

Version	Name (HTML Documentation)	ISO publication	Published (yyyy-mm)	Current Status	HTML	EXPRESS	XSD	pSet XSD	OWL HTML	RDF	TTL
4.4 — dev	IFC 4.4.0 development	not started		Extension of 4.3.0. Adding additional functionality (mainly for Tunnels). Currently under development in the Standards & Solutions program
4.3.1.0	IFC4.3.1.x dev	Updates from 4.3.1.x might be used as input into the ISO DIS process.	Updates after 4.3.0.1 coming from the Implementer Forum.	Focussed on documentation improvement, clarifications and further detailing of implementation.	Latest HTML	GitHub output		PSD output
4.3.0.1	IFC4.3 TC1 (zip)	Under ISO DIS Voting		under ISO DIS Voting	HTML
4.2.0.0	IFC4.2	—	2019-04	Withdrawn	ZIP	EXP	IFC4x2.xsd	—
4.1.0.0	IFC4.1	—	2018-06	Withdrawn	ZIP	EXP	IFC4x1.xsd	—	ifcOWL IFC4.1	RDF	TTL
4.0.2.1	IFC4 ADD2 TC1	ISO 16739-1:2018	2017-10	Official	ZIP	EXP	IFC4.xsd	—	ifcOWL IFC4 ADD2 TC1	RDF	TTL
4.0.2.0	IFC4 ADD2	—	2016-07	Retired	ZIP	EXP	IFC4_ADD2.xsd	—	ifcOWL IFC4 ADD2	RDF	TTL
4.0.1.0	IFC4 ADD1	—	2015-06	Retired	ZIP	EXP	IFC4_ADD1.xsd	—	ifcOWL IFC4 ADD1	RDF	TTL
4.0.0.0	IFC4	ISO 16739:2013	2013-02	Retired	ZIP	EXP	ifcXML4.xsd	PSD_IFC4.xsd	ifcOWL IFC4	RDF	TTL
2.3.0.1	IFC2x3 TC1	ISO/PAS 16739:2005	2007-07	Official	ZIP	EXP	IFC2X3.xsd	PSD_R2x3.xsl	ifcOWL IFC2x3 TC1	RDF	TTL
2.3.0.0	IFC2x3	—	2005-12	Retired	ZIP	EXP	—	—	ifcOWL IFC2x3	RDF	TTL
2.2.1.0	IFC2x2 ADD1	—	2004-07	Retired	ZIP	EXP	—	—	—	—	—
2.2.0.0	IFC2x2	—	2003-05	Retired	ZIP	EXP	—	—	—	—	—
2.1.1.0	IFC2x ADD1	—	2001-10	Retired	ZIP	EXP	—	—	—	—	—
2.1.0.0	IFC2x	—	2000-10	Retired	ZIP	EXP	—	—	—	—	—
2.0.0.0	IFC2.0	—	1999-10	Retired	—	—	—	—	—	—	—

The table IFC Release Database was last modified at 2022-11-08 11:32:30 by Léon van Berlo.

Version Notation

IFC versions are identified using the notation «Major.Minor.Addendum.Corrigendum«.

Major versions consist of scope expansions or deletions and may have changes that break compatibility.

Minor versions consist of feature extensions, where compatibility is guaranteed for the «core» schema, but not for other definitions.

Addendums consist of improvements to existing features, where the schema may change but upward compatibility is guaranteed.

Corrigendums consist of improvements to documentation, where the schema does not change though deprecation is possible.

1. Manuals
2. Brands
3. IFC Manuals

ManualsLib has more than 17 IFC manuals

Цель данного раздела обеспечить пользователя необходимой информацией для самостоятельной работы на торгово-аналитической платформе NetTradeX и платформах MetaTrader 4,MetaTrader 5.
Изучив материалы данного раздела Вы узнаете: