Комментарии 5
Автор умолчал о принципиальной проблеме сводящей количество вариантов к одному: второй подход означает что в среде данных их то как раз и нет, ибо ни чертежи ни тем более спецификации через ifc не передать. В итоге среда данных превращается в файловую помойку уровня Яндекс диска, а файлы которые тоннами туда запихивают все кому не лень никакой взаимосвязи между собой не имеют. Докажи мне что чертежи которые у тебя в "среде данных" вобще из этой модели?
проблему, описанную вами, должна решать не среда общих данных, а регламенты работ (бизнес-процессов).
То есть можно использовать СОД как "помойку", загружая все подряд без привязки, а можно загружать и хранить в заранее описанном порядке. Например, загружать одновременно два варианта отображения одного и того же файла: 3D-файл в формате ifc и в исходном формате (rvt, nwd step и т.д.).
Опять мечты теоретиков: ни один регламент никогда не описывает актуальную ситуацию по проекту, я готов поспорить на десятку что ты такой проект показать не сможешь, ибо в каждом первом бардак зарождается уже на старте и похер какой там регламент, а к середине бардак достигает масштабов, когда никто неспособен найти произвольно нужные ему документ среди пары сотен тысяч содержащихся в системе, кроме тех которые он загружал сам и с которыми работает постоянно. Люди смысл одного и того же слова даже однозначно понять не могут, а ты хочешь сказать на проекте где работают сотни а иногда и большее число людей возможно ситуация когда они ВСЕ будут однозначно трактовать что куда класть? Это розовое детство какое-то. Тут не могут договориться делить выделять ли отдельно документы прошедшие экспертизу и согласовывать их по второму разу, или забить на них совсем и дорабатывать то, что в парарель развивалось пока сидели в экспертизе. Но суть моего возражения была даже не в этом: хоть упорядоченная, хоть нет - помойка остается помойкой, потому что с данными она работать не умеет. С файлами в которых эти данные содержатся и то откровенно хреново, а самими данными вобще никак. При этом ты называешь это средой общих ДАННЫХ, что неверно в корне.
отдельно по поводу "файловой помойки" напишу.
сейчас все большую популярность получает "Озеро данных". Можно эту методику использовать в работе. В таком варианте файловая помойка никого не беспокоит и создается сознательно, а упорядочивается информация уже после, в момент когда нужно работать с какими-то конкретными данными.
Не уверен, что это применимо к стандартным строительным проектам, но в будущем это окажет влияние на нашу работу. Это я к тому, что прогресс неизбежен и движется вообще независимо от нашего желания.
В принципе, думаю, концепция "Озера данных" напрямую связана с тем, как современный человек хранит данные у себя на компьютере. Молодежь все больше НЕ упорядочивают данные по папкам, а пользуются поиском для нахождения нужного файла и работают с ним.
А потом быстро переходят когда найти файл становится невозможно и проще его заново скачать или набрать. Знаем, об это и говорю. Пока ты мыслишь файлами никакого прогресса не будет. Ты когда в ревите работаешь у тебя внутри ен файлы хранятся, а данные модели. И это работает. А СОД состоящий из файлов не работает. Все равно что вотсап в котором нельзя набирать сообщения, а можно только отправлять ранее подготовленные pdf.
Технология и методология работы с 3D-моделями в среде общих данных строительного проекта