Несколько показательных файлов с ошибками пришло от пользователей буквально в течение прошлого месяца.
Первый .step содержал ошибку аж прямо в заголовочной секции Step Physical File, а именно в названии схемы, т.е. в объекте FILE_SCHEMA. И вроде бы правильно было написано её название, да грамматика запрещает использовать точку для EXPRESS идентификаторов, которая была поставлена в конце строкового литерала с названием схемы.
Второй .ifc файл пришел со значениями типа REAL, сохранёнными как слово nan. Очевидно, имелись в виду unsetы для REAL, которые в памяти по ISO стандарту представлены как те самые NaN. Ещё из недавних .ifc – LISTы, хранящие наборы $ в своих ячейках, немного неправильных GlobalId, содержащих более двадцати двух символов и пр.
Как вы наверное уже заметили, я плавно подошел к перечислению семантических проблем, часто встречающихся в файлах. Например, типичная и хорошо всем известная проблема на протяжении десятков лет – некорректная топологическая информация для фасетированных объектов, пропущенные фасеты, ребра и пр. Ошибочно сформированной пространственной (spatial) структурой модели тоже никого не удивишь в 2025 году.
Но вот из нового: buildingSMART так и не могут объяснить, каким образом правильно сформировать re-usable (переиспользуемую) топологию для дорожных профилей (IfcAlignment), когда общая горизонтальная часть является основой для двух разных вертикальных профилей. Первый, интуитивный, и второй, полуофициально предлагаемый где-то на просторах сети, варианты не правильные, хотя вполне себе рабочие. Или вот взять хотя бы несколько разных интерпретаций IfcMapConversion от разных вендоров и самих авторов, которые, кажется, так до сих пор и не пришли к единому мнению.
Кроме всего прочего достаточно часто приходят свежие IFC4X1 и IFC4X2 файлы со старой версией IfcAlignment, которая была заменена более грамотной формализацией дорожных версий IFC в версии схемы IFC4.3. Напомню, что ранние версии были заблокированы компанией bSI ещё в начале 2023 года, на официальном сайте которой предписано не создавать новые файлы этих версий. Тогда buildingSMART поспешили, выпустив 4X1, а за ней и 4X2 для мостов, из-за чего спровоцировали вал файлов с описаниями алайнментов, которые потом были полностью переделаны. Вроде бы эти версии уже и не надо поддерживать, особенно, если кто-то начал поддержку IFC после упомянутых изменений, но файлы всё равно появляются с завидным постоянством.
Самое печальное здесь, что обозначенные проблемы как с IFC, так и со STEP не были решены ЗА ДЕСЯТИЛЕТИЯ существования форматов, и со временем только множатся. Тулкиты, как маленькие и бесплатные, так и большие коммерческие, продолжают сохранять STEP Physical файлы с синтаксическими ошибками, а крупные вендоры не позаботились об изъятии устаревших версий форматов из оборота, так что многие компании в индустрии, связанные круговой порукой, вынуждены как-то расходовать ресурсы на поддержку чего-то совсем не актуального.
И вот вдруг bSI вместе с товарищами из Autodesk на саммите в Марокко в октябре 2024 года объявили о работе над новым форматом IFC5, который синтаксически будет не совместим с предыдущими версиями IFC, а семантически возьмет лишь какую-то часть от этих ранних форматов. На текущий момент авторы IFC5 думают над тем, как описать с его помощью дорожные профили, а некоторые вендоры УЖЕ объявляют о создании приложений, поддерживающих новый формат!
Но что в итоге может получиться из этой затеи? Предполагаю, что всё это выльется в создание пачки новых тулкитов которые на протяжении следующих 30 лет будут бороться с аналогичными детскими проблемами новорожденного формата IFC5, т.е. с теми проблемами, с которыми боролись десятилетиями, но так и не смогли с ними совладать: ошибочная геометрия, синтаксические ошибки (используемый JSON менее устойчив к подобного рода ошибкам, чем SPF), семантические ошибки в связях между объектами и т.д. А ведь к этим проблемам добавятся еще как минимум и вероятные ошибки интерпретации слоёв (layers) IFC5 и ограниченные геометрические возможности OpenUSD, у которого просто нет средств для работы с кривыми, поверхностями и сложными операциями геометрического моделирования с их помощью. Придется ещё и вкладываться в обучение всех заинтересованных в то, как это должно (бы) работать.
Работа ради работы! Впрочем, на недавнем мероприятии в Сингапуре представители bSI несколько сдали назад и заявили, что IFC5 не будет заменой предыдущих версий формата, но будет существовать как одна из альтернатив, наравне с развиваемыми IFC2X3, IFC4, т.е. «interoperability has no version number». Видимо, кому-то из [остальных] крупных игроков идея полностью поменять правила игры пришлась не по душе.
