Family Names check

The last two weeks we have been busy with a couple of things. One of them is the setup of the company structure and all kind of legal documents. Things for the chamber of commerce, accountants, notary and documents like SLA and SaaS agreements. Not the most fun things but very necessary, and once those kinds of things are rolling, they do provide some peace of mind.
On the dashboard, we have been busy with adding a family name check. A seemingly simple thing until you start diving into Revit a bit further. We are checking against the Dutch Revit standards called NLRS. A family name consists of 7 positions.

• <pos1> NLRS
• <pos2> Classification code
• <pos3> Abbreviation of the Family Category
• <pos4> Code for family placement

<pos1> Is a very straightforward check, do the first two letters exist in the table of country codes.
<pos2> Do the first the numbers of the assembly code match with this position.
<pos3> This position was slightly more challenging as the parameter at a family is called FamilyCategory and needs to be checked against a table with abbreviations and keeping in mind that different languages will have other abbreviations.
<pos4> This was a challenge as we needed to check several parameters to get a result, because depending on the value of a parameter, other parameters give different results. Explanation: The parameter FamilyPlacementType drives the host parameter and depending on that value, a parameter ‘workplane based’ might exist and have a value. The combination of all these values lead to what abbreviation needs to be used for position 4. @Jeremy Tammik thank you very much for your snooping tool addin for Revit. We ended up having to go through a whole lot of families for checking purposes.

The result is that we can now generate a table and mark per position if a family name is compliant with the standards.

This functionality right away pointed to a mistake on my side. I was looking at the results of a Revit file I had created, and the table was marking some of the families as incorrect while I thought they shouldn't be wrong. While I was talking about the results with Mark, we found out that I had made a mistake. The assembly code is, of course, a type parameter, and if your family has multiple types, you need to check every type of that family if you have set the assembly code correctly. As you might guess, I indeed had forgotten a type and the system marked it as wrong...

It's not easy being corrected by your own logic :)