I’m currently testing some automations with models sent using v3 of the Archicad connector.
I’m working with objects that have many properties, but I only need a few specific ones for my automations. I understand that property filtering by object type is being reviewed and that the data volume has already been reduced, which is great.
I was wondering if there are plans to allow me to filter which properties get translated to Speckle based on object type? This would help optimize the data I send and reduce unnecessary volume.
I’ve also encountered a challenge with certain properties that don’t seem possible to send. For example, with exterior windows, I have parameters for the glazed and opening areas. These are custom parametric windows with GDL properties, and the values are crucial for regulatory compliance checks in Spain. While I can translate them to IFC, I’m curious if it’s possible to write them directly into a Speckle object without going through IFC, or if I could use Python to achieve this.
Any insights on whether this is possible would be greatly appreciated!
Thanks for being active in the community, testing the v3 Archicad connector, and sharing great suggestions!
Improving property filtering and adding more items to data extraction are definitely on our radar, but we’re still discussing them internally. Currently, we extract user-defined properties for the following element types: Wall, Slab, Beam, Column, Roof, Shell, and Morph.
If your window properties are created via Archicad’s built-in Property Manager (as user-defined properties), we can easily extract them in a future release. If they are specific GDL parameters, it’s still possible, but it requires further discussion.
It would be helpful if you could share a simple file (without sensitive data) that includes all the properties you’d like to extract.
We’d also love to hear how you plan to use automation and integrate the Archicad connector into your daily workflow so we can consider these insights in our upcoming design meetings.
I’ve already checked all the user-defined properties extracted from the element types you mentioned, and everything looks great! However, I’d really like to access properties from zones, as I often use them for surface and data analysis.
I’ve attached a sample window to illustrate the kind of properties I’m referring to: Sample window.pln (8.9 MB)
The property I’d like to access is gs_list_glassarea.
This property is crucial for verifying compliance with urban regulations that require a minimum glass area per room. There’s also a minimum ventilation area requirement, but addressing that would require a more developed property of the same kind that I’m unfortunately not allowed to share. My plan is to:
Group windows by their respective zones (rooms), analyzing their proximity to zones.
Sum all the gs_list_glassarea values for each zone.
Divide the total glass area by the surface area of each zone.
Check if the result meets the required percentage of glass area per room.
Flag non-compliant zones and generate warning messages accordingly.
Without gs_list_glassarea, this calculation becomes significantly more complex. Analyzing geometry alone doesn’t always yield the real glass area, and ventilation area is even trickier—it’s dependent on the operable portion of the window, which can’t be extracted directly from the geometry.
I hope this explanation clarifies the request! Let me know if this is feasible.
Thanks for the detailed description—it really helped me understand your use case!
If the glass area property is not available as a user-defined property, there’s still a chance it exists as a built-in property. In that case, you won’t see it in Archicad’s UI, but we can still retrieve its value via the API. This means we should be able to extract it relatively easily and support your use case.
If it’s not available as a built-in property either, then we’ll need to read the GDL parameters. This is possible, but it raises a deeper design question that we need to discuss internally first.
I’ll check the window’s built-in properties and get back to you with an answer soon.
We can extract the width, height, and jamb width properties for each window, allowing you to calculate the glass surface area in your code like this: (height - 2 * jambWidth) * (width - 2 * jambWidth)
This provides a close approximation of the glass surface area and the solution aligns with our current data extraction design. Would this approach be helpful?
The gs_list_glassarea is a GDL parameter that requires a different retrieval method. Since each GDL element has unique parameters, extracting these is not in our short-term plans.
First of all, thank you very much for your response, and apologies for not getting back to you sooner—I’ve been caught up with other projects lately.
Regarding the proposed solution, I’m afraid it doesn’t quite meet our needs. The frame width that is extracted corresponds to the total window frame, but it doesn’t account for the frame of each individual sash (leaf). The glass surface area would actually be like this: (height - 2 * totalJambWidth - 2 * shashJambWidth ) * (width - 2 * totalJambWidth - 2 * shashJambWidth)
Additionally, the issue of identifying the openings of each sash in the window remains unresolved. Ideally, we would need a property that identifies each sash along with its opening type and its specific dimensions. I understand this might be as complex as accessing the GDL properties, especially since these values can vary depending on the element and project, but, can it be resolved accessing the IFCProperties instead?
When mapping to IFC in Archicad, we can access this type of information directly from the property tables, and this could be a viable workaround. I believe Speckle might be able to access these as well—depending on the predefined translator (and therefore the mapping) we are using, Archicad lists the corresponding properties.
What I’ve seen so far is, that the accessible IFC properties are very limited in the Property Manager API, but I’ll have a second look.
“When mapping to IFC in Archicad, we can access this type of information directly from the property tables” → do you mean that you set up an IFC translator that can access the needed info? If yes, please send me a screenshot of how you set it up / an IFC translator if possible!
That’s it! In Archicad it is possible to set up a custom IFC translator and export the properties in a cutomized way, and we use it often to add some specific info to new properties.
You can access the IFC translators available, as follows:
In the following window, there’s a bunch of import and export translators available. There, you can create a new export translator clicking on new... or use an already existing one:
I created a new Property Mapping option. To do so you can click on the three dots on the rigth or on Edit/Create a new predefinition. This will open the following window:
Over there you can edit the exporting properties as wanted. In this case first I clicked on IfcWindow entity. On the IFC properties column I added a new property inside Pset_WindowCommon called Area acristalada. Then I generated a new empty rule on the top right side of the window and inside the rule added the Área Acristalada Total from the Window. To do so I clicked on:
Over there I accessed to the window I added to the project form the object library and searched for the right variable in the available parameters column and added it by clicking in the >> Añadir >> button:
Thanks for the detailed and illustrated description — it really helps a lot!
I’ll set it up as you suggested and check it from the API side.
I think we should be able to solve this issue.
Based on your quick tutorial it was easy to add the property mapping, thanks again for that!
Archicad has different APIs for “default” and IFC properties, and currently we only extract data with the default Property Manager. (we also have a few IFC properties between these props, but not all of them)
I implemented a POC solution for your use-case and it’s possible to export what you need:
This implementation is rough, untested, and incomplete, so we won’t be shipping it as-is. Right now, our focus is on improving load times in Archicad, but we’ll revisit IFC property extraction in the coming weeks. I’ll ping you once we have a more solid solution.
