Формат ifc что это
Перейти к содержимому

Формат ifc что это

  • автор:

Формат ifc что это

What’s on this Page

.IFC вариант №

Файлы с расширением IFC относятся к формату файлов Industry Foundation Classes (IFC), который устанавливает международные стандарты для импорта и экспорта строительных объектов и их свойств. Этот формат файла обеспечивает взаимодействие между различными программными приложениями. Спецификации для этого формата файла разрабатываются и поддерживаются BuildingSMART International в качестве стандарта данных. Конечной целью формата файла IFC является улучшение связи, производительности, времени доставки и качества на протяжении всего жизненного цикла здания.

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

Краткая история

Инициатива IFC была предпринята Autodesk в 1994 году для поддержки интегрированной разработки приложений и включала такие компании, как Honeywell, Butler Manufacturing и AT&T. В 1995 году членство было открыто для всех, и название было изменено на Международный альянс за интероперабельность. Целью некоммерческой организации было опубликовать Industry Foundation Class (IFC) в качестве модели продукта AEC. В 2005 году название снова было изменено, и теперь buildSMART поддерживает его.

Формат файла IFC

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

  • IFC4 Дополнение 2 (2016 г.) IFC4 Дополнение 1 (2015 г.)
  • IFC4 (март 2013 г.) ifcXML2x3 (июнь 2007 г.)
  • IFC2x3 (февраль 2006 г.) ifcXML2 для IFC2x2 add1 (RC2)
  • Приложение IFC2x2 1 (июль 2004 г.) ifcXML2 для IFC2x2 (RC1)
  • Приложение IFC 2x2IFC 2x 1ifcXML1 для IFC2x и
  • Приложение IFC2x 1IFC 2xIFC 2.0IFC 1.5.1IFC 1.5

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

Форматы файлов данных IFC

Формат файла IFF поддерживает обмен данными между приложениями, использующими различные форматы, перечисленные ниже:

IFC: Это формат обмена IFC по умолчанию, в котором используется физическая файловая структура STEP в соответствии со стандартом ISO 10303-21. Этот формат файла имеет расширение .ifc и является наиболее часто используемым форматом IFC.

IFC-XML: Это версия IFC в формате файла XML, которая может быть создана непосредственно отправляющим приложением в соответствии со структурой ISO 10303-28, также называемой STEP-XML. Формат файла IFC-XML считается подходящим для взаимодействия инструментов XML. По сравнению с форматом файла IFC размер файла IFC-XML на 300–400 % больше.

IFC-ZIP: Это ZIP сжатая версия IFC или IFC-XML, где один из этих файлов находится в основном каталоге zip-архива. Этот формат сжимает файл .ifc на 60–80 %, а XML-файл .ifc — на 90–95 %.

Архитектура IFC

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

имена элементов данных для типов, сущностей, правил и функций начинаются с префикса «Ifc» и продолжаются английскими словами в соглашении об именах CamelCase (без подчеркивания, первая буква в слове в верхнем регистре); имена атрибутов внутри объекта следуют соглашению об именах CamelCase без префикса; определения наборов свойств, которые являются частью этого стандарта, начинаются с префикса «Pset_» и продолжаются английскими словами в соглашении об именах CamelCase; определения наборов величин, которые являются частью этого стандарта, начинаются с префикса «Qto_» и продолжаются английскими словами в соглашении об именах CamelCase.

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

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

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

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

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

Использованная литература

See Also

  • PHJ — формат файла проекта PhCNC
  • Формат файла JVSG
  • Формат файла NWC
  • Формат файла NWD
  • Формат файла NWF

Формат IFC

Если коротко, то формат Industry Foundation Classes (IFC) предназначен для описания данных об архитектуре, проектировании и строительстве и был создан по инициативе Autodesk.

Из wikipedia: Industry Foundation Classes (IFC) – нейтральная к платформе спецификация открытого формата файла, которая не контролируется одним поставщиком или группой поставщиков. Это объектно-ориентированный формат файла с моделью данных, разработанный buildingSMART (до 2005 года Международный альянс по взаимодействию, IAI) для облегчения взаимодействия в области архитектуры , проектирования и строительства (AEC), и является широко используемым форматом сотрудничества в области информации о зданиях. проекты на основе моделирования (BIM). Спецификация модели IFC открыта и доступна. Зарегистрирована ISO и является официальным международным стандартом ISO 16739-1: 2018.

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

Richard Junge взяв за основу STEP, поставил задачу разработать формат, который станет независимым от производителей САПР. Его идея заключалась в том, чтобы весь процесс от проекта до строительства и управления зданием упростить и ускорить. В отличие от традиционного обмена 2D-линиями и 3D-данными объема, IFC должен был предоставить пользователю кросс-программную «интеллектуальную» модель данных. Например, инженер-строитель мог бы изменить или расширить модель данных с учетом статических требований и вернуть изменения архитектору без потерь. Планировщик строительных услуг также мог бы использовать эту информацию для планирования маршрута. Также должны были бы учитываться все изменения модели, т.е. документироваться. Patrick MacLeamy, американский архитектор и председатель BuildingSMART, перенес тему в Соединённые Штаты. Дальнейшая разработка формата IFC осуществлялась Autodesk и в 1994 году Autodesk зарегистрировала формат IFC на своё имя.

Борьба за рынок CAD продолжается по всему миру. Сегодня всё BIM можно разделить на два типа: ClosedBIM – использование в проектировании программы одного производителя, OpenBIM – работа с открытым форматом данных, который должен автоматически читаться другими программами.

Ярким представителем ClosedBIM сегодня является Revit. Он безвозвратно изменил представление пользователей CAD-программ об интерфейсе, простоте использования и быстроте проектирования. Его прародитель, софт Pro/Engineer в середине 90-х был глобальным лидером на западном рынке конструкторского проектирования машиностроительной промышленности. Цель его состояла в том, чтобы создать систему, которая была бы достаточно гибкой, чтобы побудить инженера легко рассматривать различные конструкции, а затраты на внесение изменений в проект должны быть минимальны. Начав в 1996 году команда разработчиков Revit, используя твердотельное параметрическое моделирование с концепцией единой модели данных для всего проекта, создала радикально новый подход к программному обеспечению для строительства. В 2002 году стартап Revit купила компания Autodesk. К сожалению, и, как ни странно, формат IFC трудно стыкуется c программами от Autodesk.

Европейские производители САПР после опубликования формата IFC пытаются его использовать. Например, Graphisoft утверждает, что программа ArchiCAD идеально подходит для работы с этим форматом и говорит о “99 процентной” работе с IFC данными. Правительства многих европейских стран уже давно сделали использование формата IFC обязательным для проектов строительства с государственной помощью. Главным по ОpenBIM в Европе является Nemetschek Group с двумя подразделениями Allplan и Archicad.

Какую роль играет наше государство в вопросах контроля и установления правил по обменным форматам? Оно следует примеру европейцев и похоже, заинтересовано в развитии OpenBIM. Министерство строительства и жилищно-коммунального хозяйства РФ и ФАУ «Федеральный центр нормирования, стандартизации и оценки соответствия в строительстве» в 2017 г разработало методические указания по обеспечению интероперабельности при информационном моделировании объектов строительства.

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

Статической модели IFC оказывается достаточно для выполнения анализа с помощью аналитического программного обеспечения. Однако если вы хотите изменить модель на основе результатов анализа, то IFC не позволит этого сделать. Так, на сайте Archicad отмечается, что при импорте IFC-модели некоторые элементы, определенные как IfcWall, IfcSlab и т.д., импортируются как объекты, а не как стены, перекрытия и т.д. Причина заключается в их упрощенном геометрическом BREP-представлении, задающем «наружную поверхность» или «контурное представление». Это означает, что кроме геометрической формы элемент не включает никакой другой информации, например, нет его привязки к осевым линиям. Таким образом, при проектировании конструкций со сложной геометрией в случае обмена данными по стандарту IFC приходится сталкиваться с потерей информации.

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

Существует ряд инициатив по созданию стандартов компонентов BIM, таких как Национальная библиотека BIM в Великобритании NBS (UK NBS National BIM Library). Но в NBS Великобритании пришлось использовать файлы проприетарного формата из-за отсутствия необходимой функциональности файлов IFC. Тем не менее, возможно появится способ для создания файловой схемы компонента IFC.

Альтернативой использованию формата IFC для обмена данными является использование специальных инструментов программного обеспечения для обмена данными:

– программные решения одного производителя САПР на основе внутренних форматов и прямых API-интерфейсов (интерфейс прикладного программирования);

– программные решения различных производителей САПР на основе проприетарных форматов и прямых API-интерфейсов.

Многие специалисты BIM считают, что формат обмена IFC не соответствует в полной мере их требованиям к обмену данными. Обсуждение данного вопроса и совместной работы постоянно ведется основными BIM-вендорами, такими как, Trimble, Graphisoft, Hexagon, Nanosoft, Aveva, Renga, Dassault Systemes, Allplan, Cadmatic, CSoft Development и пр. В основном ими приветствуется концепция OpenBIM. Причин тому много. И то, что нет такой ClosedBIM (или SuperBIM) которая бы в полной мере обеспечивала все разделы проектной документации, расчет и дальнейшую эксплуатацию. И то, что чем больше проект, тем больше независимых участников. Многие производители САПР понимают, что увеличения использования их софта можно добиться, если предлагать помощь своим клиентам в интеграции и сами разрабатывают какие-либо решения. Именно европейские вендоры активно развивают конвертеры, адаптеры и сервисы с сохранением всей геометрией и атрибутивной информацией. Например, eShare – веб-портал для визуализации, обмена и интеграции проектных, строительных и эксплуатационных данных о промышленном объекте на основе BIM модели компании Cadmatic, Bimplus – открытая платформа для совместной работы над проектами на основе BIM-модели для строительной отрасли компании Allplan.

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

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

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

Привет, Мир! => \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_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 нам нужно задать значения для всех атрибутов. Первый атрибут, унаследованный от 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.’,$,(),());

Следующие элементы , , , , — опциональные и текстовые (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)

В основе любой геометрии находится элемент 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 имеет тип IfcProfileDef – это абстрактный класс, имеющий большое количество потомков «на все случаи жизни», в данном случае используется IfcRectangleProfileDef(,,,,)

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

Для стен постоянной толщины принято использовать 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 — номинальные габариты, можно не указывать – тогда эти значения будут браться из геометрии

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

Пишем IFC

Теперь, вооружившись этим знанием, попробуем описать простой домик, для начало мы возмём пустой 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;

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

IFCPROJECT, IFCUNITASSIGNMENT, IFCGEOMETRICREPRESENTATIONCONTEXT

#1=IFCPROJECT(‘abcdefghijklmnopqrs101’, $, ‘Project #1’, $, $, »,», (#7), #6);

/* Единицы измерений модели */
#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.));

IFCBUILDING=>IFCBUILDINGSTOREY=>IFCRELCONTAINEDINSPATIALSTRUCTURE

/* Дом */
#11= IFCBUILDING(‘abcdefghijklmnopqrs102’, $, $, $, $, #13, $, $, .ELEMENT., $, $, $);
#12= IFCRELAGGREGATES(‘abcdefghijklmnopqrs103’, $, $, $, #1, (#11));
#13= IFCLOCALPLACEMENT($,#8);

/* Этаж */
#14= IFCBUILDINGSTOREY(‘abcdefghijklmnopqrs104′,$,’level1’,$,»,#13,$,»,.ELEMENT.,0.);
#15= IFCRELAGGREGATES(‘abcdefghijklmnopqrs103’, $, $, $, #11, (#14));

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

Опишем пол — IFCSLAB

#17= IFCSLAB(‘abcdefghijklmnopqrs106′,$,’slab’,$,»,#13,#18,»,.BASESLAB.);
#18= IFCPRODUCTDEFINITIONSHAPE($,$,(#19));
#19= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#20));
#20= IFCEXTRUDEDAREASOLID(#21,#8,#22,100.);
#21= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,1000.,1000.);
#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,$,$);

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

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

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

#101= IFCROOF(‘abcdefghijklmnopqrs119’,$,$,$,$,#105,$,$,.FLAT_ROOF.);
#102= IFCSLAB(‘abcdefghijklmnopqrs120′,$,’roof’,$,»,#105,#18,»,.ROOF.);
#103= IFCAXIS2PLACEMENT3D(#104,$,$);
#104= IFCCARTESIANPOINT((0.,0.,1100.));
#105= IFCLOCALPLACEMENT(#13,#103);
#106= IFCRELAGGREGATES(‘abcdefghijklmnopqrs121’,$,$,$,#101,(#102));

Заключение

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

  • Работа с векторной графикой
  • CAD/CAM

Формат ifc что это

IFC (англ. Industry Foundation Classes) — это универсальный открытый объектно-ориентированный формат данных, который не принадлежит одному разработчику или группе организаций. Данный формат развивается международным альянсом buildingSMART, в который входят разработчики программного обеспечения, поставщики строительных конструкций, крупные строительные и архитектурные организации — все кого интересует развитие универсальных и открытых стандартов в строительной области. Зачастую формат IFC используется для передачи данных при проектировании по методу Информационного моделирования зданий (Building Information Modeling — BIM). IFC официально сертифицирован международным стандартом (ISO-PAS 16739) и доступен на сайте [www.iai-tech.org].

Формат хранит в себе всю информацию о строительных конструкциях, а его открытость позволяет гарантированно передавать данные из одного приложения в другое. По информации Википедии, на данный момент формат IFC поддерживает 21 программный продукт (среди них Autodesk Revit и AutoCAD Architecture, Nemetschek Allplan и SCIA Engineer, Tekla Structures, GRAITEC Advance Steel, Progman MagiCAD).

Личные инструменты
  • 95.214.216.211
  • Обсуждение для этого IP-адреса
  • Представиться системе
  • Главная страница
  • Индекс А-Я
  • Термины и понятия
  • Поставщики и продукты
  • Все категории продуктов
  • СМИ и аналитики
  • Общественные организации
  • Выставки и конференции
  • Персоны
  • Случайная статья

Поиск поиск по Энциклопедии

Похожие публикации:
  1. Rei90 стена кирпичная сколько кирпичей
  2. Как нарисовать схему электрической цепи
  3. На каком расстоянии от фундамента можно копать погреб
  4. Фундамент под крыльцо к дому

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *