💳Про требования к ЦИМ АГР
💬Вот уже второй месяц сообщество взбудоражено новостью о том, что со 2 апреля сего года вступают в силу новые требования к материалам для согласования архитектурно-градостроительного решения (АГР) в г. Москва, в частности по новым требованиям должны предоставляться цифровые информационные модели (ЦИМ) в формате IFC, соответствующие утвержденным требованиям.
🔍Я изучил эти требования и они по структуре и формату представления довольно похожи на требования к ЦИМ от Мосгосэкспертизы, выполнение которых обязательно для проектов, финансируемых городом. Но вот для согласования АГР в Москве, как я понимаю, попотеть придется всем, вне зависимости от способа финансирования проекта. Посмотреть эти требования вы можете на портале СтроимПросто .
Делать краткий пересказ требований не планирую. Но вы можете посмотреть довольно полезный вебинар от команды разработчиков в их тг-канале . Я тут выскажусь о двух важных, на мой взгляд, волнующих меня аспектах.
1️⃣ Не опять, а снова. Все свойства элементов моделей – пользовательские. Более того – пунктом 5.3.16 системные свойства классов IFC (входящие в наборы Pset_, Qto_) при рассмотрении не учитываются! Но при этом, разбор элементов по классам IFC используется, а класс IfcBuildingElementProxy вообще запрещен, за исключением абстрактного понятия как «Вспомогательное 3D-тело».
🆗 Да, пользовательские свойства допускаются стандартом IFC, но неиспользование системных параметров снижает интероперабельность между системами. Национальное расширение – ок, ну добавляйте туда те свойства, которых нет в стандарте IFC.
❓Но для чего выводить туда количественные параметры (типа RUS_Height, RUS_Width), которые автоматически рассчитываются из геометрии элементов и выводятся в стандартые свойства наборов типа Qto_*? К тому же можно и ручками в них что угодно вписывать.
🤷🏻♂️Да и в целом без системных параметров можно игнорировать и сами классы IFC (кроме базовых проекта). Классы то имеют свою специфику и типизацию, атрибуты и специфические набор свойств. Но если нет разницы, зачем платить больше нет смысла и разделять, тем более что классификация по МССК по прежнему требуется. Конечно, это не смертельно, но это однозначно повышает трудоемкость при формировании модели, утрачивая при этом преимущества, которые дает стандарт IFC.
2️⃣ Требования к технико-экономическим показателям (ТЭП) в XML. Несмотря на то, что в требованиях явно указывается, что ЦИМ АГР является «источником формирования ТЭП», связи между XML-схемой и элементами ЦИМ как таковой не усматривается. При этом мы все понимаем, что XML формат текстовый. Таким образом, все что необходимо для получения XML из ЦИМ можно получать из ЦИМ. А в данном случае мы получаем два разорванных источника данных, которые могут просто друг другу не соответствовать.
💁🏻♂️Лучше бы задали требования к ЦИМ АГР в части ТЭП и сами выгружали из них нужные ТЭП. Тогда бы и источник не дублировался, и нагрузка на разработчика была бы ниже. Хорошо, что есть умельцы, которые делают бесплатные сервисы для формирования такой XMLки. Но исходную проблему это всё же не решает.
😒Возвращаясь выше, мне эта ситуация с пользовательскими свойствами напоминает Оруэлловский новояз. Ведь метафорически, стандарт IFC это единый «язык», который можно дополнять, так скажем «диалектами», т.е. свойствами, которых не хватает. Но тотальное игнорирование системных параметров приводит именно к такому неутешительному сравнению…
#информационнаясреда
💬Вот уже второй месяц сообщество взбудоражено новостью о том, что со 2 апреля сего года вступают в силу новые требования к материалам для согласования архитектурно-градостроительного решения (АГР) в г. Москва, в частности по новым требованиям должны предоставляться цифровые информационные модели (ЦИМ) в формате IFC, соответствующие утвержденным требованиям.
🔍Я изучил эти требования и они по структуре и формату представления довольно похожи на требования к ЦИМ от Мосгосэкспертизы, выполнение которых обязательно для проектов, финансируемых городом. Но вот для согласования АГР в Москве, как я понимаю, попотеть придется всем, вне зависимости от способа финансирования проекта. Посмотреть эти требования вы можете на портале СтроимПросто .
Делать краткий пересказ требований не планирую. Но вы можете посмотреть довольно полезный вебинар от команды разработчиков в их тг-канале . Я тут выскажусь о двух важных, на мой взгляд, волнующих меня аспектах.
1️⃣ Не опять, а снова. Все свойства элементов моделей – пользовательские. Более того – пунктом 5.3.16 системные свойства классов IFC (входящие в наборы Pset_, Qto_) при рассмотрении не учитываются! Но при этом, разбор элементов по классам IFC используется, а класс IfcBuildingElementProxy вообще запрещен, за исключением абстрактного понятия как «Вспомогательное 3D-тело».
🆗 Да, пользовательские свойства допускаются стандартом IFC, но неиспользование системных параметров снижает интероперабельность между системами. Национальное расширение – ок, ну добавляйте туда те свойства, которых нет в стандарте IFC.
❓Но для чего выводить туда количественные параметры (типа RUS_Height, RUS_Width), которые автоматически рассчитываются из геометрии элементов и выводятся в стандартые свойства наборов типа Qto_*? К тому же можно и ручками в них что угодно вписывать.
🤷🏻♂️Да и в целом без системных параметров можно игнорировать и сами классы IFC (кроме базовых проекта). Классы то имеют свою специфику и типизацию, атрибуты и специфические набор свойств. Но если нет разницы, зачем платить больше нет смысла и разделять, тем более что классификация по МССК по прежнему требуется. Конечно, это не смертельно, но это однозначно повышает трудоемкость при формировании модели, утрачивая при этом преимущества, которые дает стандарт IFC.
2️⃣ Требования к технико-экономическим показателям (ТЭП) в XML. Несмотря на то, что в требованиях явно указывается, что ЦИМ АГР является «источником формирования ТЭП», связи между XML-схемой и элементами ЦИМ как таковой не усматривается. При этом мы все понимаем, что XML формат текстовый. Таким образом, все что необходимо для получения XML из ЦИМ можно получать из ЦИМ. А в данном случае мы получаем два разорванных источника данных, которые могут просто друг другу не соответствовать.
💁🏻♂️Лучше бы задали требования к ЦИМ АГР в части ТЭП и сами выгружали из них нужные ТЭП. Тогда бы и источник не дублировался, и нагрузка на разработчика была бы ниже. Хорошо, что есть умельцы, которые делают бесплатные сервисы для формирования такой XMLки. Но исходную проблему это всё же не решает.
😒Возвращаясь выше, мне эта ситуация с пользовательскими свойствами напоминает Оруэлловский новояз. Ведь метафорически, стандарт IFC это единый «язык», который можно дополнять, так скажем «диалектами», т.е. свойствами, которых не хватает. Но тотальное игнорирование системных параметров приводит именно к такому неутешительному сравнению…
#информационнаясреда