Duncan Lithgow
2012-05-27, 12:42 AM
We're about to start using Detail Components in our details (they've been very Detail Line heavy so far) and obviously we see a need to organize them. It looks like we're going with a material based system of under 10 folders (material based as opposed to based on wall details, floor details, roof details for example). I have two questions
1. What do people here think about organizing based on materials?
2. What about naming the Detail Components themselves?
My thoughts on organizing Detail Components is rather split
By Material: If we organize by material we risk never being able to make useful Detail Components with more than one material, or at least if we make them we start creating confusion about where they go and where they can be found. Am I being silly? Should a Detail Component always be at such a detailed level that which material is primary is blindingly obvious?
By Function: Seems like this would be silly as the same material can have many functions.
By Building Component: This is the only way of organizing which in Denmark where I work has a standard. It's called SfB, has been around for ages and divides things up into sitework, primary elements (wall, floor), completion elements (door, window) and surface elements (floorboards, tiles). I think it's a fine system and there are not so many many numbers that you go silly in the head. Max three digits. But again here we hit the problem that the same thing can be used in more than one place. For example a concrete sill could be the same under a window and door.
Naming the Detail Components themselves
The direction at the office is for "natural names", naming them what you'd call them. I see this as a trap because the names will get too long. For example "Aluminum profile for horizontal connection between brickwork and concrete". Which will be listed happily in the folder of things made of Aluminum, or should that be Metal... Things would be better if it was named in some structure of importance like "profile_aluminum_horizontal_brick_concrete" and the natural name could be in the description parameter.
Another problems with this approach is that once listed on a server the actual address will be horrible "Aluminum%20profile%20for%20horizontal%20connection%20between%20brickwork%20and%20concrete" and even worse once we start using the three danish characters not typically supported by URLs.
Despite my reservations I'm tempted to suggest we just follow Autodesks own organizing principles with the 16 divisions they use for Detail Components. I assume the sub divisions are using omniclasses (but I haven't checked). What does your office use?
1. What do people here think about organizing based on materials?
2. What about naming the Detail Components themselves?
My thoughts on organizing Detail Components is rather split
By Material: If we organize by material we risk never being able to make useful Detail Components with more than one material, or at least if we make them we start creating confusion about where they go and where they can be found. Am I being silly? Should a Detail Component always be at such a detailed level that which material is primary is blindingly obvious?
By Function: Seems like this would be silly as the same material can have many functions.
By Building Component: This is the only way of organizing which in Denmark where I work has a standard. It's called SfB, has been around for ages and divides things up into sitework, primary elements (wall, floor), completion elements (door, window) and surface elements (floorboards, tiles). I think it's a fine system and there are not so many many numbers that you go silly in the head. Max three digits. But again here we hit the problem that the same thing can be used in more than one place. For example a concrete sill could be the same under a window and door.
Naming the Detail Components themselves
The direction at the office is for "natural names", naming them what you'd call them. I see this as a trap because the names will get too long. For example "Aluminum profile for horizontal connection between brickwork and concrete". Which will be listed happily in the folder of things made of Aluminum, or should that be Metal... Things would be better if it was named in some structure of importance like "profile_aluminum_horizontal_brick_concrete" and the natural name could be in the description parameter.
Another problems with this approach is that once listed on a server the actual address will be horrible "Aluminum%20profile%20for%20horizontal%20connection%20between%20brickwork%20and%20concrete" and even worse once we start using the three danish characters not typically supported by URLs.
Despite my reservations I'm tempted to suggest we just follow Autodesks own organizing principles with the 16 divisions they use for Detail Components. I assume the sub divisions are using omniclasses (but I haven't checked). What does your office use?