Duplicate type marks, bad?

[patricks]

When we do door types and schedules, we often show a single door TYPE for say a solid door, half glass, full glass, etc. And so that one type can apply to any size solid door, etc. and one should refer to the schedule for the size.

So what that means is that I often have doors of the same type but various sizes with the same type mark. Of course it gives me the little warning which I ignore, and it all schedules correctly, so is there anything bad or any drawbacks from having doors of different family types (sizes) with the same type mark?

[eldad]

If you can make sense out of your schedule that's all that matter, though I avoid doing it the way you do, door suppliers or installers are more likely to make mistakes...
I tag doors per rooms, that way my door number also includes my room number, if i need to delete or add doors, it won'y effect the door order... much easier to manage and all is clear, you can add an instance door type and change each door...

[Tom Dorner]

Ah...a great philosophical discussion on how architects using Revit in 2006 like to try and conform a fully normalized database to 1960's hand drafting techniques <sarcasm off>

I fight this same battle myself daily and it is a tough one. I have a database background and the problem with the technique you are using and the principals of our firm like as well is that it violates what is called database normalization. A fully normalized database has no duplicate information anywhere within its structure. When you use the "type mark" to indicate an "A" and door type "A" is a 1-3/4" SC Wood door 3'-0" wide by 7'-0" high and you also use the same "A" to mean a 1-3/4" SC Wood door 3'-0" wide by 8'-0" high Revit sees the two duplicate "types". In Revit the two doors should be distinct type marks as they are both unique which is what makes a type in Revit.

I use the analogy that if we architects were a retailer and wanted to track the sales of mens pants we would only say "Dockers type A" see schedule for colors, and sizes. In this example of pants what makes a "type" in the retailers database is the unique combination of "Brand+Style+Color+Size(WxL)" In any of the four columns of Brand,Style, Color and Size you can have many duplicates. However it is the unique combination of the four things that makes a specific item or "type" and there can only be one "type" in the database.

In Revit you can ignore the duplicate type marks warning, but there are caveats to doing so. In your current project you will probably suffer no ill effects as your schedule will work as you point out. If you explored an ODBC export to MS Access though you will see a different story as only one of the "types" can exist in the exported database. If you want to start to think about how your firm can start to participate in an integrated construction process with a contractor who uses Timberline for estimating and relies on Revit for quantity data it is best IMHO to get control of the duplicate type marks situation now before you get too far down the road to easily change.

I'm still working out the details on how to handle it in the firm I work at. It is a huge re-education process to get people out of a bad hand drafting days carry-over. I'm thinking of doing a lunch time session using the pants example in a MS Access database. Once I can get people to see the problem there, maybe it will help them understand that the same principle applies to doors in Revit.

Until then, it may be best to create a new shared parameter for your doors that is a simple text field called "door panel type". Revit won't complain about duplicates in this field and it buys some time to tackle the real problem of re-educating users, PA's and Principals.

Hope this rambling post helps somewhat.

[sbrown]

What if you used instance parameters in the door family, then it would be "true". ONE door type, with various instance parameters.

[Tom Dorner]

What if you used instance parameters in the door family, then it would be "true". ONE door type, with various instance parameters.
Still violates the database normalization rule. Using the pants example again you would only have "Dockers, Flat Front, Mocha" in your database and not the "size". Assuming there are 36 different size combinations of Flat Front Dockers your database has 36 potential duplicate types.

It is the unique combination of all common characteristics that makes a type of something. If all I know is that I have 23 doors that are 3'-0"x7'-0" but there are a mix of different frames and door panels within those 23 doors that can't be identified in a database via a "primary key"* then I'm going to have nothing but trouble mapping doors out of the Revit database to other databases.

* Databases require a primary key which is a unique number, or alpha or alpa-numeric combination to uniquely identify a "type" of something. Back in our retail example that unique primary key is the SKU number. When you bring a pair of pants to the cashier in a store they scan that SKU number in in the bar code which tells them what they just sold and looks the price up in their master database via that unique SKU number. Think of doors being brought up to a cashier like at your local Home Depot. They have a different SKU numbers for a 2'-8 x 6'-8" vs. a 3'-0" x 6'-8" entry door of the same brand and style. There are different prices too.

Hopefully I can get around to writing about this in my BLOG one of these days as it is an important subject to understand.

[dbaldacchino]

For us, the type mark describes whether the door has a lite and if it does, whether it's a narrow lite, half lite or full glass, and where it is located in relation to the door top, bottom and side edges. If a full glass wood door has 6" side rails, that constitutes a door type. For a similar aluminum full glass door, we use the same type mark and in our key we show the door with a set of dimensions for a wood door and another set of dims for an aluminum door.That's for standard doors of course, but custom configurations would have their unique type marks, dims and notes too. The important thing is the dimensioning to establish the relation of anything on the door to it's edges....for instance you dimension to one edge of the door and the top side. If a door is 8' and another is 7', then the lite has always the same relation to the top and side edges. Everything else is an instance parameter, with the type mark being reported from the type properties. The "Mark" is the door name, which corresponds to the room name. In our schedule, we end up with a door name, it's height and width, material, frame material, fire rating and it's type mark, which describes how it looks in elevation. This way, we can easily and globally change one door type in our key/legend and you wouldn't change anything else. Our door type families are built in this manner so we can create or change our types quickly. In most projects, this covers 100% of the doors, while in others we would need to create custom types (and thus, families).

[patricks]

If you can make sense out of your schedule that's all that matter, though I avoid doing it the way you do, door suppliers or installers are more likely to make mistakes...
I tag doors per rooms, that way my door number also includes my room number, if i need to delete or add doors, it won'y effect the door order... much easier to manage and all is clear, you can add an instance door type and change each door...

I also tag doors with room numbers followed by a dash and an instance number, that just makes sense. ;)

100-1, 100-2, 100-3 if there are 3 doors going into room 100.