Morning musing...
It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.
C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.
Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.
I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.
For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."
Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.
This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.
I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.
It's my observation that there is a prevailing mostly ambivalent attitude toward the Copy/Monitor (C/M) features. I've said before that I think the order of the tabs in the Options dialog are based on the likelihood that we'll use them. Specifically they are listed left to right: Levels, Grids, Columns, Walls and Floors.
C/M isn't hard to use but once it is in play we've got some new rules and warnings to contend with. The process depends on us identifying the elements we want to live in the C/M system. I understand the logic of that choice. Revit asks us to tell it what is important enough to us to engage the system.
Perhaps we need a completely different way to attack the problem? One that doesn't require the advance work. One that is more a reaction to work as it is created and shared, that merely exists.
I wonder if it would be more betterer if we could run a Level or Grid check as a process. The application would compare elements and compile a report, observations and differences. It could be something we read afterward or presented in a dialog for immediate action.
For example, it could just start with: "Hey Steve, there are 27 grids in your model and 30 in theirs. You should look at them." Take it slightly deeper, "Hey Steve, there are three grids that share the same name but are not in the same location."
Does it matter that they used to be in the same location and they aren't now? The application would have to start storing records for past results to do that but it could be useful to determine when or how things got off track. The rules or conditions that are interesting need to be defined.
This sort of element review and comparison doesn't have to be limited to the five that Copy/Monitor were designed for originally (overlooking the MEP elements that have been added in some fashion). It still requires two or more elements though; mine, yours and theirs. The redundancy is annoying but it does provide us with flexibility within our own models.
I imagine much of what I'm describing (and more) is possible via the API and Dynamo. It just needs someone to decide it is an interesting enough thing to do.