tópico Re: Problema com Qto_CoveringBaseQuantities.GrossArea para IfcCovering / CLADDING em Dados de projeto e BIM

Problema com Qto_CoveringBaseQuantities.GrossArea para IfcCovering / CLADDING

viniciusdlr — Fri, 21 Aug 2026 19:56:07 GMT

Identifiquei um possível problema no cálculo das IFC Base Quantities do Archicad para elementos IfcCovering classificados como CLADDING.

Testei o mesmo caso no Archicad 28 e 29, e o comportamento se repete.

No arquivo do Archicad 29, o IfcCovering possui:

PredefinedType = CLADDING
Geometria: 3,00 × 3,60 × 0,035 m
Width = 0,035 m
GrossArea = 0,105 m²
NetArea = 0,105 m²

O valor exportado de GrossArea corresponde exatamente a:

3,00 × 0,035 = 0,105 m²

Porém, de acordo com a definição do IFC4 para Qto_CoveringBaseQuantities, GrossArea é a soma das áreas do covering facing the space.

Para um revestimento vertical (CLADDING), eu esperaria:

3,00 × 3,60 = 10,80 m²

Interessantemente, no mesmo arquivo, um IfcCovering classificado como FLOORING possui:

GrossArea = 10,80 m²

ou seja, o Archicad calcula corretamente a área da superfície nesse caso.
Isso parece indicar que, para CLADDING, o exportador está utilizando a área da base/seção (Length × Width), em vez da área da superfície revestida.

Alguém sabe se esse comportamento é intencional ou se existe alguma configuração do IFC Translator para alterar esse cálculo?

Referência IFC4:
Qto_CoveringBaseQuantities.GrossArea — “Sum of all gross areas of the covering facing the space.”

Arquivos de teste: Archicad 28 e Archicad 29.

Re: Problema com Qto_CoveringBaseQuantities.GrossArea para IfcCovering / CLADDING

Rogerio M — Fri, 21 Aug 2026 20:56:15 GMT

Boa tarde, Vinicius,
Entendo que o IFC espera ordens de dimensões definidas pelo tipo de classificação que é inputado no elemento. Assim, o Cladding, que é esperado um tipo de revestimento vertical espera a ordem comprimento (X) * altura (Z) * Espessura (Y). Para o Flooring, que é esperado um elemento horizontal, a ordem é comprimento (X) * largura (Y) * Espessura (Z). Isso resultaria justamente no comportamento que você verificou, a multiplicação será X*Z (cladding) ou X*Y (flooring) para definir a área.
Se for possível alterar as classificações dos elementos, esse problema deve cessar. Outra opção, talvez criar psets personalizados com as dimensões pode ser um caminho, sendo necessário criar regras no bimcollab ou outro software para calcular a partir do pset.

Re: Problema com Qto_CoveringBaseQuantities.GrossArea para IfcCovering / CLADDING

viniciusdlr — Mon, 24 Aug 2026 13:08:32 GMT

Bom dia, Rogerio,

No caso preciso atender a requisitos de um mandate e essa informação é solicitada e utilizada para orçamento. Entendo que o archicad utiliza o parâmetro de área para o preenchimento desse campo sendo que poderia utilizar qualquer campo de área de superfície para o correto preenchimento.

Re: Problema com Qto_CoveringBaseQuantities.GrossArea para IfcCovering / CLADDING

Rita Gurjao — Thu, 03 Sep 2026 15:51:31 GMT

Olá, @viniciusdlr

Tudo bem?

Obrigada por ter aberto um ticket sobre este caso, para que o suporte pudesse investigar se havia algum problema técnico, como parecia ser. Gostaria de compartilhar aqui na comunidade a resposta que recebemos, para ajudar outros usuários que possam passar pela mesma situação.

Os desenvolvedores analisaram o caso e confirmaram uma inconsistência, já registrada internamente como DEF-24391, caso queira consultar o andamento posteriormente. Foi identificado que, atualmente, o Archicad calcula a área de projeção (footprint area) do revestimento, em vez do valor definido pela especificação IFC Sum of all gross areas of the covering facing the space.

Você pode consultar essa definição diretamente na documentação oficial do IFC Qto_CoveringBaseQuantities.

Como solução alternativa, foi recomendado exportar as quantidades nativas do Archicad por meio de Conversão de Dados > Selecionar Dados do Archicad para Exportação > Parâmetros do Elemento > Dados do tipo Quantidade. No entanto, essa alternativa pode alterar o fluxo de trabalho atual de vocês e, no momento, não são conhecidas outras soluções alternativas. Reforço que a questão já está registrada com a equipe de desenvolvimento para uma futura correção.

Espero ter ajudado.