Комментарии 25
В IFC нет Bridge Cap, если мы посмотрим на картинку, то увидим, что Bridge Cap реализован через IfcBuildFacilityPart http://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcFacilityPart.htm, а это довольно универсальный тип, который применяется для репрезентации части разных объектов и весь пример демонстирует высокую гибкость IFC. И то что, ты нихрена не слышишь, что тебе говорят...
Трир, спасибо за твою критику, ты один из немногих кто читал эту статью перед публикацией. Я тебе тоже уже отвечал на этот вопрос в сообщениях.
Конкретно эту презентация я слушал вживую (онлайн конференция по BIM в инфраструктурных проектах Германии), где эти специалисты из мюнхенского TUM - открыто радовались тому, что сумели запихнуть этот элемент, хотя в других странах он не используется. Меня поразило то, что в одном предложении было - "Мы смогли добавить в классификатор" и "этот элемент в других странах не используется"
Ок, элемент добавили в IfcFacilityPart - значит он будет открываться в немецких CAD программах. А зачем он нужен то вообще в мировом формате, если в других странах он не используется.
IfcFacilityPart это просто абстрактный объект обозначающий часть чего то - моста, дороги, набережной. В каждой стране есть свои нюансы для отображения которых можно использовать этот абстрактный объект
Чтобы добавить этот абстрактный объект нужно сидеть в chapters и rooms. Могу предположить в таких группах почти нет граждан с российскими паспортами.
Главный факт, неупомянутый в статье, что крупнейшие строительные компании Германии IFC компании не используют, хотя в Германии лежат корни IFC.
его не нужно добовлять, он уже есть
Не удевительно, сам же говоришь, что они в плоских чертежах работают
Главный факт, неупомянутый в статье, что крупнейшие строительные компании Германии IFC компании не используют, хотя в Германии лежат корни IFC.
"Главный факт" противоречит самой статье:
Активными разработчиками и основными бенефициарами идеи IFC сегодня являются европейские вендоры, стремящиеся переломить гегемонию Autodesk над данными, и азиатские компании
Т.е. люди активно разрабатывают и поддерживают открытый формат, и даже стремятся переломить гегемонию Autodesk.
Тут нет противоречий. Просто в одном случае это компании занимающиеся созданием софта, а во втором это строительные компании.
Большое количество софтверных компаний борется с Автодеск. На рынке Европы эти компании продают свои решения небольшим региональным клиентам.
В то время как основные игроки строительного рынка (Strabag, Zublin, Implenia, Siemens, Bosch, DB) практически не используют формат IFC в своих процессах 4D-5D.
Стандарт IFC он для разработчиков софта. Они разбираются в его устройстве (при желании) и делают софт. Наверняка, они тратят свои ресурсы на реализацию чтения/записи IFC как раз потому, что он используется. Поэтому и формат IFC развивается.
Те компании которые инвестировали своё время и деньги в поддержку IFC и разочаровались в формате - сегодня начинают смотреть на другие форматы, которые намного проще передают данные из модели.
Например формат CPIXML - содержит все те же данные, что содержит IFC, только в более простом виде и без параметрической геометрии. Этот формат и завоёвывает сегодня европейский рынок.
Опять видится противоречие тексту статьи. Всегда есть возможность создавать IFC без параметрической геометрии (например IfcTessellatedItem). Если в этом была цель, то она уже достигнута, никакого "лоббирования" для этого не нужно, это максимально простое использование части стандарта IFC, доступное любому вендору, без какого либо членства в buildingSMART.
опять путаешь тёплое с мягким, IFC и CPIXML - совершенно разные вещи
К сожалению, не все элементы или классы добавляемые европейскими и азиатскими специалистами в IFC используются при строительстве в других странах мира. Т.е. редкие элементы или классы, используемые в менее богатой стране (неспособной продвигать своих производителей через buildingSMART)
Участвуют и европейские специалисты, и азиатские, и они смогли консолидировать усилия. Было бы странно, если они вместо этого, за свои деньги, начали разрабатывать классы для "менее богатых стран", которые и не просят их об этом.
Всё правильно значит сейчас идё наполнение и разработка только элементов, которые интересуют европейских и азиатских специалистов. Какие здесь тогда шансы у России, получить отстраивание своей "национальной" геометрии через формат IFC в разных программах?
Прежде чем отстраивать "национальную геометрию" желательно освоить применение уже существующей геометрии. IFC описывает множество геометрических представлений, достаточных для решения подавляющего большинства задач любого региона. Кто-то развивает и создаёт, а кто-то рассуждает о гипотетической возможности, гипотетической страны добавлять гипотетическую национальную геометрию. Эдак точно ничего никуда не добавить.
Проблема не в геометрии а в том, кто и как её генерирует, импортирует и экспортирует. Должна быть строгая сертификация софтверных продуктов, которая сегодня де-юре есть, но де-факто ничего не говорит о качестве данных, которые можно будет получить в IFC файле.
Даже если формат будет идеальным - всё равно будет зависимость качества данных от воли, желания и способностей разработчкиков имплементировать все возможные особенности формата IFC свой продукт.
Должна быть строгая сертификация софтверных продуктов
Любая сертификация ПО — это дорого, особенно для небольших игроков или инди-разработчиков. Я не знаю намеренно ли у вас опущено слово "обязательная", но такая жесткая политика негативно скажется на конкуренции. Сертификация может быть добровольной. Отсутствие сертификата не говорит о плохом качестве реализации ПО, а наличие сертификата не означает, что хорошее качество.
Даже если формат будет идеальным - всё равно будет зависимость качества данных от воли, желания и способностей разработчкиков имплементировать все возможные особенности формата IFC свой продукт.
Т.е. проблема не в формате, и не в держателе стандарта, как представлено в статье, а всё зависит от воли разработчика? Да, это так, и это не зависит от применяемого формата. Если у разработчика нет воли создавать качественне чтение/запись какого-либо формата, то возможность "лоббирования" качества в его ПО не добавит. Надо работать.
Проблема всегда в нас самих. В данном случае - наше поведение снизу (нашей отрасли) само дало направление развитию этой хорошей изначально идеи в бюррократичскую систему.
Проблема в формата в том, что качество данных в этом формате зависит от человеческого фактора: будь то разработчик софта или специалист который импортирует или экспортирует файл. Т.е. данные зависят от воли, способностей людей, которые оперируют этим файлом.
Проблема в формата в том, что качество данных в этом формате зависит от человеческого фактора: будь то разработчик софта или специалист который импортирует или экспортирует файл. Т.е. данные зависят от воли, способностей людей, которые оперируют этим файлом.
Файлами оперирует программное обеспечение, а не разработчики стандартов. Таким образом содержимое файлов зависит от ПО и данных пользователей ПО. Бюрократическая защита как раз и нужна, чтобы в стандарт не просачивались идеи от тех, кто не желает изучать стандарт и делать на его основе реализации, но готовы впихивать в него абстрактные сущности, например, под соусом "национальной геометрии", не неся потом за это ответственность.
Т.е. редкие элементы или классы, используемые в менее богатой стране (неспособной продвигать своих производителей через buildingSMART) не войдут в официальную классификацию IFC и будут распознаваться всеми программами CAD только через дополнительный “костыль” - IfcBuildingElementProxy.
На то они и "редкие классы". И IfcBuildingElementProxy хорошо решает свою задачу.
Но если работа с данными ведётся между системами, за которыми стоят разные разработчики, то из-за проблемы объектно-ориентированного подхода и “небольших особенностей” формата IFC корректно экспортировать, отстроить данные по геометрии и передать их корректно через формат IFC без трудоемкого ручного маппинга (соответствия) всех свойств UserDefined и геометрии в IfcBuildingElementProxy не получится.
Применение IfcBuildingElementProxy никак не мешает использовать классы точного описания геометрии. Для IfcBuildingElementProxy доступны GeometricCurveSet, SurfaceModel, SweptSolid, Brep, BoundingBox, MappedRepresentation.
Очень полезная информация, спасибо!
Open Source в строительстве. Непрозрачность IFC формата и buildingSMART. Войны лоббистов и развитие BIM. Часть 7