Attribute Concept for an Archicad Practice Template

[GabrielGG]

Hello,

I've watched this video by @scottjm   and several others by @Nathan Hildebrandt  many times recently as I'm developing a concept for a new Archicad template for the practice where I currently work. I would like to ask for your opinion on our Attribute concept.

Here are the links to the video and a community article about it:

Video tutorial: Understanding Attributes and Attribute Pollution 

https://www.digital.skewed.com.au/media/webinars/archintensive-2023-dark-side-attribute-chaos

Thanks to @scottjm and @Nathan Hildebrandt for the content. I highly recommend everyone watch these videos and explore many others on the same YouTube channel. They are unvaluable.

To provide some context, the practice I'm working at has grown rapidly from approximately 20 to 100 employees. The current Archicad template is not suited to the size of our office or the number of projects we are handling, and it's difficult to scale. That's why we've decided to create a new template with a long-term perspective.

I call the concept "The Attribute Trap," and it's quite simple:

• The Archicad template in each country defines how to set up attributes in compliance with local regulations. We will adopt this approach for our practice's attribute system and remove all standard Archicad attributes.
  • I still need to test if there might be issues with the standard values of Archicad tools. If so, I will see if I can redefine these standard values for everyone in our practice. I'm also considering keeping the standard "line" and "hatch" attributes of Archicad, but testing is necessary.
• Our practice attributes will start at index 10,000, with all indexes before this number left empty. The practice indexes will run up to 20,000 (or another number that suits our practice's requirements). I chose 10,000 indexes for our standards because I like to think long-term.
• After index 20,000, the project-specific attributes will begin. These are created by the project team when no standard attributes are defined for a specific need or special workflow. To mark the start of these attributes, there will be an attribute at index 19,999 called "Start of Project Attributes" or something similar. This way, any manually created attribute will automatically be indexed after the last existing index.

What I aim to achieve with this concept:

• Any attributes from old projects or Archicad standards that are copied or hotlinked will be placed in the range of 0 to 9,999. We use indexes up to 2,000 for differentiating internal processes.
• Any workflow that creates new attributes in the first free indexes (such as Master GDLs, modules with conflicts, or improperly done IFC imports) will create those in the range of 0 to 9,999.
• In the future, when the template is in use, all project-specific attributes that might be copied will be placed in index 20,000+ with a gap to the existing project index number. If the project we are copying to has not created many attributes yet, or it will be placed in 0 to 9,999 if the attribute index already exists.

This approach makes it much easier to clean up attributes because you just need to sort them by index. One of my biggest challenges right now is managing the master GDLs that are infiltrating our practice through projects.

I still have some open questions to Test and address:

• What will happen to the standard parameters in the tools and library parts in Archicad, and how can I distribute the necessary changes throughout our practice? (Favorites are less attractive until they can be distributed "not manually" but "from the administrator for everyone" in the office.)
• The Attribute Library: I've reserved 10,000 indexes for our standards because I plan to have many predefined attributes. As we have a wide portfolio of project types, I tend to keep these in a separate file that is locally saved, read-only, and accessible to everyone in the office. This allows them to import what they need as I develop it in the background, adding attributes as we identify needs over time.

I am currently navigating through Archicad attribute theory, and I hope that if we implement this, time will show it to be a meaningful concept. However, before starting, it's always good to have some debate and gather different perspectives on it.

Thank you to everyone interested in this theoretical debate.

Gabriel

Operating system used: Windows 11

[Nathan Hildebrandt]

Removing the OOTB Attributes will cause more chaos in your practice than benefits. Personally I maintain the following OOTB attributes. 

• line types
• fills
• surfaces 

I keep the OOTB attributes for those but rename them to align with my naming strategy. The reason for keeping them is because all of the library parts from OOTB together with library parts you download reference these attributes. I played around with ideas like this back in Archicad 9 and quickly changed the way I worked when I realised I made life harder for people. 

I will have a look over your video but the issues I raise above truly need to be considered in building your template attributes. Because I rename the OOTB attributes it made sense for me to continue my attributes immediately after the OOTB ones. I don’t skip through to a fixed index number. I understand your theory behind it but I can guarantee in a practice of 100 team members you will find it incredibly hard to keep on top of everyone in every project. 

regards 

Nathan

[GabrielGG]

Thank you, @Nathan Hildebrandt 

I conducted a test using the following tools:

• Built-in checker for missing attributes in Archicad (accessible via the GDL bar)
• Archicad Schedules to list missing attributes in the View Map
• Simple XML Visual Table Editor to edit attributes and assign them the desired index (in my case, I added 9000 to the standard index number). I then deleted the standard attributes and replaced them with the newly indexed ones to ensure the system maintained proper tracking, and it worked.
• Visual Studio Code for editing LIBpack JSON files to modify the indexes of predefined values

The results are very promising, and I plan to continue testing. If we can streamline this process for each template migration in our practice, the benefits would be substantial. This approach would prevent unwanted attributes from mixing with project-specific ones at the index level.

You would allways know what attributes were imported without us wanting them in a very simple way.

Best regards,

Gabriel

[Nathan Hildebrandt]

One extra thought. Does your team ever download and use manufacturer content at all? Note that those objects will call out OOTB attributes as well, potentially then putting you in a position where they will have missing attributes when they are loaded. Keep up the test though. Well done.

Regards Nathan

[GabrielGG]

Thanks @Nathan Hildebrandt 

I have completed my "migration of standard Attributes to new indexes" test, and the results are excellent!

We are not using manufacturer contetns because they tend to mess up the Attributes and import Master-GDLs that create even more attributes. We mainly have Public contract and are Legally binded to produce make Product neatral Building-Specifications.

The sequence of actions during migration is crucial, but I managed to finish the process without any missing attributes in the report. While the report isn't perfect—occasionally listing problems inconsistently, like missing attributes in the "model View Options"—most issues are captured.

I would love for someone to attempt a similar migration. This concept challenges Graphisoft's guidelines but has significant potential to enhance control over attribute chaos. I believe it's a promising concept, but given the strong Graphisoft guidelines against it, it's challenging to make a decision based on a single test that will have consequences in our Practice during many Years. In my opinion, with recent improvements in attribute and library management in Archicad (still far from perfection!), this solution is worth considering.

Here are the steps I followed, in case anyone else wants to try:

Important Tools:

• Command "Check for Missing Attributes" in the GDL Bar (available from Archicad 27 onwards).
• XML Editor: To edit attributes. You should find your workflow; I use XiMpLe (a visual editor) to copy-paste to and from Excel, using standard formulas to modify indexes or attribute names.
• Visual Studio Code: To edit the mapping tables (JSON files) of the LIBpacks using Python scripts and relink all attributes to the new index numbers. This task cannot be done manually due to the JSON files containing 1.5 million lines of code.

Steps:

1. Migrate the Standard Archicad Template to use LIBpacks if you're testing with Archicad 28. Ensure the correct localization is set. During this step, for the AUT version, Archicad creates an unwanted attribute, a fill called "sj," when the Monolithic Library 28 is removed. It cannot be permanently deleted as it will reappear.
2. Check for Missing Attributes in the Standard Archicad Template (see Important Tools, the first one). This is the case with the AUT Template. Correct these first! The best method is to create an attribute in the index that is missing, then delete and replace it with another one to correct the error.

1. Export the Standard Attributes as XML. Based on this XML, create two XMLs and edit them as follows. Exceptions are attributes not changing (not relevant for the concept and they cause many problems while relinking the indexes):
   • Room Categories
   • MEP Systems
   • Operation Profiles
2. XML 01 Edit: Modify the names of the Standard Archicad Attributes while keeping the original indexes. You can add a suffix like "_S" for standard.
3. XML 02 Edit: Keep the original names and change the indexes. In my case, I added 9000 units (e.g., Index 132 becomes 9132). Identify which attributes cannot have their indexes changed. Open a Standard Archicad Template and delete the attributes. Those that cannot be deleted should never have their indexes changed. In the AUT template, these include:
   • Layer Index 01 - Archicad Layer
   • Line Index 01 - Continuous
   • Pen Set Index 14 - Arbeitseinstellungen
   • Fills with transparency and gradients (indexes 22, 23, 24, 64, 65, 140, 141)
4. Import both edited XMLs based on index numbers.
5. The Most Tedious Part: Delete all standard attributes (with "_S" at the end) and move the contents to those with the same name in the new index. This step must be done manually because Archicad will relink the index throughout the system, including the default settings for Archicad tools.
6. SAF Import: This will show missing attributes. Export these as XML and edit the index numbers to relink to the new indexes.
7. Modify the JSON Mapping Values to search for the new indexes. Since the JSON files contain mapping values for all countries, you will encounter errors because attributes from other countries are not present in your country's template. Treat these as exceptions and instruct your script on which index to use from your country's template. I encountered issues with USA and JPN doors, building materials, and fills.

If you have any detailed questions, feel free to ask.

I repeated the entire process at the end, and with the edited XMLs and Python scripts already prepared, I completed the attribute migration in 3 to 4 hours.

I will continue testing and preparing our template based on this concept. If I encounter any problems, I will post them here.

This might be of interest to anyone struggling with Master GDLs, unwanted attribute imports from IFCs or DWGs, and those working on split Archicad files with many modules (and potential for many attribute conflicts).

Thanks in advance

Gabriel