Por que meus elementos viram "proxy" no IFC?

Uma parede que o IFC não sabe que é parede não serve pra nada.

O projetista modela uma parede no software nativo. Atribui material, espessura, função estrutural, resistência ao fogo. Exporta para IFC. No viewer, a parede aparece — geometria intacta, posição correta, aparência idêntica. Mas quando o coordenador filtra por IfcWall, ela não está lá. Quando o orçamentista extrai quantitativos de paredes, ela escapa. Quando o IDS verifica se toda IfcWall tem Pset_WallCommon preenchido, ela nem entra na regra. A parede virou IfcBuildingElementProxy — o balde genérico do IFC para tudo que o exportador não soube classificar.

IfcBuildingElementProxy existe no schema IFC (ISO 16739-1:2024, IFC4x3) como entidade de último recurso. Não é erro do formato. É a confissão do exportador de que não encontrou mapeamento entre a categoria do modelo nativo e uma entidade IFC tipada. Cada software de autoria mantém um tradutor interno que decide: esta categoria vai para IfcWall, aquela para IfcSlab, esta outra para IfcBeam. Quando a categoria é customizada, importada de biblioteca de terceiro, ou simplesmente não prevista no mapeamento default, o tradutor faz a única coisa que pode: despeja em proxy.

O problema é que proxy não carrega semântica. IfcWall sabe que é parede — permite filtro por tipo, herda Property Sets canônicos (Pset_WallCommon), participa de quantitativos específicos (IfcElementQuantity para área, comprimento, volume de parede), entra em regras de clash com lógica de tolerância por tipo. IfcBuildingElementProxy não sabe o que é — é geometria com GUID, sem identidade funcional. Filtrar, quantificar, verificar e coordenar sobre proxy é operar no escuro.

A solução não é eliminar IfcBuildingElementProxy do schema — ele tem uso legítimo para objetos genuinamente sem tipo definido. A solução é garantir que nenhum elemento que tenha entidade IFC tipada correspondente (IfcWall, IfcDoor, IfcBeam, IfcSlab, IfcColumn, entre outras) saia como proxy por falha de mapeamento. Isso exige configuração explícita do preset de exportação e verificação pós-export antes de a entrega subir ao CDE.

1. 1

   Filtro por tipo retorna lista incompleta · ao filtrar IfcWall no viewer federado, paredes modeladas não aparecem — estão escondidas como IfcBuildingElementProxy.

2. 2

   Quantitativo de paredes ou lajes não fecha · a extração automática por entidade tipada soma menos do que o modelo tem, porque os proxies escapam da contagem.

3. 3

   IDS passa sem acusar falha onde deveria · a regra exige Pset_WallCommon em toda IfcWall, mas os proxies não são IfcWall — a regra não os alcança e o erro fica invisível.

4. 4

   Viewer mostra geometria sem identidade · o objeto aparece na tela, tem forma de parede, mas ao selecionar a entidade reportada é IfcBuildingElementProxy.

5. 5

   Coordenação ignora elementos relevantes · regras de clash configuradas por tipo (IfcBeam vs IfcDoor) não capturam elementos que deveriam participar mas estão como proxy.

6. 6

   Categorias customizadas do nativo sem correspondência · famílias criadas fora do template padrão do software saem como proxy porque o exportador não tem mapeamento para elas.

1. 1

   Mapeamento de exportação no default de fábrica · o exportador IFC do software usa a tabela padrão, que cobre categorias nativas mas ignora categorias customizadas do projeto.

2. 2

   Categoria criada fora do template institucional · o projetista criou uma família ou categoria ad hoc que não existe na tabela de mapeamento — o exportador não sabe para onde mandar.

3. 3

   Biblioteca de terceiro sem mapeamento IFC · famílias compradas ou baixadas vêm com categorias proprietárias que o tradutor não reconhece.

4. 4

   Preset de exportação não revisado por projeto · o mesmo preset genérico é usado em todos os projetos, sem ajuste às categorias específicas de cada um.

5. 5

   Ausência de verificação pós-export · ninguém abre o IFC gerado para conferir se as entidades exportadas correspondem ao que foi modelado — o proxy passa despercebido.

6. 6

   Confusão entre aparência e identidade · o projetista vê a geometria no viewer e assume que está correto; não confere a entidade IFC atribuída a cada objeto.

1. 1

   Filtro e consulta que perdem elementos · toda operação baseada em entidade tipada (filtrar IfcWall, listar IfcColumn) ignora os proxies. O resultado parece completo mas não é.

2. 2

   Quantitativo errado para menos · extração automática por tipo soma apenas o que está tipado. Paredes-proxy, vigas-proxy, lajes-proxy ficam de fora — o orçamento nasce incompleto.

3. 3

   IDS que não protege · regras IDS aplicadas a entidades tipadas não alcançam proxies. Um proxy sem Pset_WallCommon não falha na verificação — simplesmente não é avaliado.

4. 4

   Coordenação degradada · clash detection por tipo não captura interferências envolvendo proxies. A parede-proxy cruza a viga e ninguém vê.

5. 5

   Handover empobrecido · no FM, o sistema de gestão de ativos filtra por tipo de elemento. Proxy não entra em nenhum filtro — o ativo desaparece do inventário.

6. 6

   Retrabalho de reclassificação · descobrir proxies tarde obriga re-export, re-upload e re-verificação. Quanto mais avançado o projeto, maior o custo.

Curto prazo (30 dias):

1. Levantar os proxies atuais. Abrir o IFC do projeto no viewer, listar todo IfcBuildingElementProxy, e classificar cada um: é proxy legítimo (objeto sem tipo definido) ou é falha de mapeamento (parede, viga, laje, coluna que deveria ter entidade tipada)?

2. Corrigir o preset de exportação. Para cada proxy que é falha de mapeamento, adicionar a correspondência correta na tabela do exportador: categoria nativa X vai para entidade IFC Y.

3. Re-exportar e verificar. Gerar novo IFC com o preset corrigido, listar os proxies remanescentes e confirmar que só restam os legítimos.

Medio prazo (60-90 dias):

4. Versionar o preset de exportação. Colocar o arquivo de mapeamento sob controle de versão, com changelog, para que toda disciplina use o mesmo preset atualizado.

5. Auditar bibliotecas de família. Conferir se cada família em uso no projeto tem mapeamento IFC correto, antes de a modelagem avançar com categorias que o exportador não reconhece.

6. Automatizar a verificação anti-proxy. Incluir regra IDS ou script de checagem que reprova IfcBuildingElementProxy com ObjectType de entidade tipada, como etapa obrigatoria antes do upload ao CDE.

1. 1

   Mapeamento no kickoff, nao na vespera · o preset de exportação IFC de cada disciplina é configurado e testado antes da modelagem avançar, com cada categoria customizada mapeada.

2. 2

   Bibliotecas auditadas antes de produção · toda família de terceiro ou categoria nova passa por verificação de mapeamento IFC antes de entrar no template do projeto.

3. 3

   Verificação pós-export como rotina · antes de subir ao CDE, o autor abre o IFC em viewer neutro e confere se as entidades exportadas correspondem ao que foi modelado.

4. 4

   Regra anti-proxy no IDS do projeto · o IDS do projeto inclui regra que reprova IfcBuildingElementProxy com ObjectType sugestivo de entidade tipada.

5. 5

   Preset versionado e compartilhado · o arquivo de mapeamento é artefato do projeto sob controle de versão, usado por todas as disciplinas.

• ISO 16739-1:2024 (IFC4x3)Industry Foundation Classes (IFC). Define IfcBuildingElementProxy como entidade genérica de último recurso e as entidades tipadas (IfcWall, IfcDoor, IfcBeam, IfcSlab, IfcColumn) que carregam semântica, Property Sets canônicos e quantitativos específicos. Proxy é confissão de que o mapeamento falhou, não limitação do formato.
• ABNT NBR ISO 19650-2:2022Fase de entrega. §5.6.3 exige verificação da garantia da qualidade antes da troca — inclui conferir que cada elemento foi exportado com a entidade IFC correta, não como proxy genérico.
• buildingSMART IDS (ISO 29481-3)Information Delivery Specification. Permite criar regra que identifica IfcBuildingElementProxy cujo ObjectType sugere entidade tipada, reprovando o proxy indevido de forma automatizada.
• ABNT NBR ISO 19650-1:2022Conceitos e princípios. Exige que a informação trocada seja confiável e verificável — elemento que chega como proxy perde identidade funcional e compromete a confiabilidade da troca.