There are a lot of cases – even if it is not entirely intentional when you migrate projects. This happens when content made in an earlier version of Archicad is opened in a newer version. These scenarios can include:
- simple copy-paste from your old projects
- hotlinking contents of an old inventory file to a project file (inserting typical units into your new project, for example)
- merging old projects into new ones
- or simply opening in a newer version with the actual intent of migration
What is common in those scenarios is that most likely the Classifications, linked Properties, Schedules, etc. will not always function as expected as the inserted content comes from a different world and will be unclassified.
Let’s see how this can be fixed relatively easily.
I have merged the content – a single unit file – from Archicad 22 to Archicad 23 which differs significantly with its Classifications.
The following method can also be used for setting the Classifications as well – it is also a common problem that some elements are not classified at all. The most convenient method to do these changes in bulk will be using Schedules.
Setting Classifications using Schedules
The Schedule has a very simple setup. As a criteria it can use All Types, or 3D Types. See the example below, All Types would include 2D drafting elements which cannot be classified anyways (see the Fill row below).
For the fields just show the basics, Element Type, Classification, Layer and Quantity for example.
Use the Merge Uniform Items checkbox, this way you can set multiple elements at once!
If some of the elements are classified already (like in the Column rows above) those will be separated nicely. A very simple, but effective trick.
We will use almost the same method for migrating the Classifications too.
Migrating Classifications
Let’s start with the simplest setup. I have two Classification systems, the earlier is more or less defined, the new one is mostly undefined. Basically anything I created in the new file natively is ok, imported elements are wrong.
I create a Schedule with All Types as a criteria and Element Type, the different Classifications and Quantity as fields.
Merge Uniform Items is on again.
Now my only task is to make sure that the second column has the same values as the first. Whether I can do it or not is a question though, in case of hotlinking the elements will be locked so I can’t set the classifications in the host file, only in the module or the module source itself (the inventory file). In that case I need to do a proper migration in the source or set the classifications if they are missing completely – same as in ‘Setting Classifications using Schedules’.
Assuming that the Classifications were correct in the old content, I may even exclude the Element Type from the Schedule which would allow more rows to merge, for example when I have different Element Types classified as one, such as Walls set as Columns besides regular Column-Columns. Taking off Element Type would spare the extra row in that case and show every Wall and Column classified as Columns together regardless of the original Element Types.
Fine-tuning the Schedules
In a real scenario the Schedule can be fairly slow due to the number of elements handled, so some further filtering would be great – for example to exclude elements which are classified correctly already. Even if in the beginning everything is wrong, this filtering will progressively reduce the number of shown elements, hence increasing the performance.
A quick solution can be to include only those elements in the Schedule that are classified in the old system (any values):
This works quite well, but the Walls are extras, since they match already, so we should preferably not see them either. This will not be configurable with the existing criteria, so we need to find another way.
How do we know if the Classifications are matching already and how to use that information as a filter? Let’s create a Property!
It is a simple True or False checkbox with an IF function, available for all Classifications. This will compare the Classification strings and will return TRUE if they match.
Let’s use it in our Schedules. The Matching Classifications property is added to the fields as well for reference only, but the main usage is as a criteria. Before going there, see that the Matching Classification property may have 4 values in the Schedules:
- <Undefined> if one of the Classifications is not set
- — if none of the Classifications are set
- True
- False
Ideally we should be looking for the all of those that are not True. Let’s reconfigure the criteria. We can’t use ‘not True’ as a condition so have to add the other criterias instead:
Or as an alternative:
The Schedule will look like this (the Walls are gone now):
Since the recent Archicad versions include more and more hierarchical tools (new Stairs, Railings, Columns and Beams), you may also want to exclude those from the list too – here it is only the Railings and the Columns and the Beams that are excluded:
Note that Stairs and/or Curtain Walls – as the very first hierarchical tool – may also be added as exclusions like that, however for the latter frames and panels will be handled differently than Stair/Railing/Column or Beam components/segments, so better not to add them.
The final Schedule – only those will be shown that need some corrections:
Conclusion
There are many ways to fine-tune the filtering, hopefully the above gave some ideas. A minor problem however is that the concept may not be fully part of a template, since the old Classification Systems can vary (AC20, 21-22, custom, etc) which we cannot prepare for, since those are not there in our templates by default. Except if we create a placeholder Classification System in our template.
Here is the default system in Archicad 23 (Archicad Classification – v 2.0) and a single item above it for the to-be-imported one, the Archicad Classification – 22. Set its Name as Archicad Classification and the Version as 22, the date doesn’t matter.
This placeholder allows us to add the Archicad Classification – 22 as a field in the template without having any elements using it. Any element in the schedule will be unclassified under that system, but that is perfectly fine as by default we would want everything in the current system, the v 2.0 only, while the placeholder is for the migration only.
If you hotlink the old content, the existing Archicad 22 elements will nicely come under this item.
As mentioned above, those linked elements and their Classifications will not be editable in the host and most be migrated in their original files.
In case of merging (File/Interoperability/Merge…) the old content into the new file you will be prompted that the placeholder system in the host will be spoiled by importing the external system – the emptiness would be replaced with an actual system -, which is exactly what we want since there is nothing to actually spoil – the placeholder is not used anywhere. We can proceed by clicking No:
The system will be nicely imported and will show up in the migration schedules correctly as well.
Hope the above help with cleaning up the models😊
