Нарисовал на планшете. Удобно |
Если скоординированная информация о проекте является "умозрительной" моделью, то где же осознание важности картографирования этоймодели у наших российских бим-евангелистов?
Формально Бауск был прав. Как мне кажется.
18.12.2012. Добавлю несколько строк после письма Анастасии Морозовой. Мы наслышаны о множестве платформ, интергрированных в единое целое программными методами, и вроде это и есть та самая единая модель. Только не буквальная модель в одном файле, а структура моделей, связанных прямыми или не очень связями. И все же не могу назвать это моделью и вот почему. На мой взгляд, чтобы что-то стало моделью оно должно быть описано и задокументировано, а связи внутри модели проверены. А у нас связки между софтвером одного вендора не всегда работают.
Вот например, внутри расчетного пакета Autodesk Simulation CFD можно выбрать необходимую модель турбулентности: каппа-эпсилон, RNG и т.д., которая окажется подходящей для медленного потока или же вихря. Все четко - прямое воплощение фундаментальной науки.
В нашем случае настолько не устоявшиеся практики управления информацией о моделях, что даже страшновато. Здесь ты экпортируешь IFC, там связываешь табличные данные, а тут вообще строишь заново принципиальную геометрию, чтобы адекватно произвести расчет.
Более того, при сложной структуре связей (особенно если мы возьмем полноценный процесс жизненного цикла информации о здании) необходимы карты процесса, где весь процесс задокументирован.
Источник |
К слову: тема интеграции разнородных данных настолько популярна сейчас у молодежи, что классики российского бим-евангелизма представить не могут. Это прямо мания какая-то объединения всего и вся. Но пока лишь на уровне пользовательского API-энтузиазма.
В Колумбийском даже был модуль на тему такой интеграции.
Опять же я придираюсь к "единой" модели потому, что это некорректная характеристика действительности, упрощенная и вендорская. С "моделью" я согласиться могу, но никак не с "единой". Другое слово давайте использовать.
Кстати, у Истмана возникает что-то близкое к "единению" на стр.554 при проверке на коллизии. Но там употребляется слово "combined".
Грубо говоря, перед тем, как что-то определять, я бы проверил, насколько это все описывается, работает, взаимодействует.
А так - да, в основе BIM лежит стремящаяся к объединению (Single Source of Truth) модель.
Как-то так.
Женя, не дай Бог теперь тебе это объяснить Талапову... Объявит тебя противником BIM и начнет методично раскатывать в каждой публикации ))
ОтветитьУдалитьНе будет. Тут для меня весь вопрос упирается в корректность формулировок. На каком-то этапе необходимо очень аккуратно подходить к терминологии и быть чутким к иному мнению, тем более специалистов из смежных областей. Моя гипотеза проста: в англоязычном дискурсе нет определения "единой". По-русски "единая" модель звучит черезчур упрощенно. И она уже стала для людей новых своего рода знаменем - дескать у нас единая модель, или комплекс (на платформе комплекса Revit), а у вас не единая, вы не модные.
ОтветитьУдалитьточно
ОтветитьУдалитьНа самом деле, все все понимают, и идут к одному. Просто есть манипуляции, позерство,наукообразие
ОтветитьУдалитьЖеня, я думаю ты задаешь правильные вопросы. Мой развернутый ответ здесь (по-английски...сорри).
ОтветитьУдалитьhttp://beyondplm.com/2012/03/30/plm-and-the-whole-truth-problem/
In my view, web model is the only sustainable one these days. Just my opinion.
Олег
Олег, спасибо за ответ!
ОтветитьУдалитьПрочитал пост - очень актуальное сравнение PLM и BIM тенденций. Пока неясно, как данные могут быть интегрированы в облаке - как у Gehry Technologies в GTeam?
В любом случае, тема построения этой мифической единой модели пока не раскрыта. Все это происходит не на уровне проверенной технологии, а скорее в рамках общего подхода, где каждый связывает все необходимые данные в кучу своими методами.
Кстати, тема ассоциативных связей, которые были в Inforbix - интересный путь, так как множество данных в арх.строит.процессе оказываются не только геометрическими, но и текстовыми. Особенно в случае не проектных моделей (A+MEP+S), а именно эксплуатационных, моделей, где происходит программирование функции объекта (например, Trelligence).
Для меня самый большой вопрос - что из себя представляет современный проектный процесс, и лишь потом - как интегрировать отдельные процессы внутри него.
Я не очень знаком с деталями Ghery Tech and GTeam. Для меня, связи в первую очередь описывают семантику. А только после этого, можно говорить о том как технически связи определяються. Многие заняты поисками "типового процесса". Я сравниваю это с постройкой типовых домов - полезно в небольших количествах или важно в определенных аспектах. Например - как идентифицировать пользователей в этих процессах независимо от систем; как обеспечить прозрачность для различных устойств (десктоп, планшет, и т.д). Можно привести еще примеры. Однако, при всей важности процессов, они не определят семантику информации. -Олег
ОтветитьУдалитьТема же веба пока меня не убеждает, если честно. Если простые сервисы, типа дропбокса и гугла работают вполне себе ничего, то на примере Autodesk решений я не могу быть уверенным в их, так скажем, стабильности. Я бы сказал, что сейчас некоторые отраслевые процессы, будучи перенесенные в облако, находятся скорее в бете, в режиме отладки.
ОтветитьУдалитьBuzzsaw, если он не поменялся за этот год, неприятно удивил долгой загрузкой файлов, древним многословным интерфейсом и невозможностью сохранить на комьютере комментарии к файлам без привязки к самому приложению. Если подписка закончилась - все, твоя информация и ее "контекст" доступны только за деньги. Autodesk Docs - как-то работает с родным dwf, все остальные форматы вызывают проблемы. А сколько шумихи вокруг этого...
С Вашим приходом ситуация, надеюсь, будет меняться в более конструктивном направлении...
Спасибо за доверие, конечно :). Да, конечно, многие облачные продукты еще в "зачаточном состоянии". В тоже время, я уверен что "постоянное улучшение" (continue improvement) продуктов и сервисов. Buzzsaw, кстати, довольно старый продукт... Олег
ОтветитьУдалить