Clases de la Fundación de la Industria. Breve introducción

Introduccion

En relación con la política del Partido y el Gobierno , hay un cambio activo en la legislación para introducir la tecnología BIM - Modelado de información de construcción. En la continuación de la línea Party, consideraremos el formato de presentación abierta BIM - IFC (Industry Foundation Classes).


La historia de IFC comienza en 1995 (de hecho, en el verano de 1993 [1] ), cuando Autodesk Corporation y un grupo de "camaradas" organizaron un acuerdo de cartel para desarrollar un formato de intercambio para varios sistemas CAD para el diseño de edificios. Un año después, los camaradas llegaron a la conclusión de que este formato debería ser abierto y desarrollado por una organización con membresía abierta, ya que la Alianza Internacional para la Interoperabilidad apareció en 1996. Más tarde, en 2008, la organización pasó a llamarse buildingSMART, para mayor glamour.

Los desarrolladores de IFC no tenían una imaginación rica y no tuvieron la oportunidad de aplicarlo: se establecieron plazos muy modestos y la tarea parecía muy global. Por lo tanto, tomaron el formato STEP (Estándar para el intercambio de datos del modelo del Producto), o más bien el Protocolo de aplicación 225: Elementos de construcción como base. Debo decir que alrededor de STEP se ha creado una infraestructura rica en forma de un montón de especificaciones en el estado de las normas ISO. Esta infraestructura se basa en el lenguaje de modelado de datos EXPRESS y su encarnación gráfica EXPRESS-G; este lenguaje fue desarrollado para la conveniencia de generar código automáticamente en varios lenguajes de programación.

El desarrollo de IFC comenzó en septiembre de 1995, IFC 1.0 se publicó en junio de 1996, la versión final fue en enero de 1997. De hecho, el objetivo de la primera versión de IFC era demostrar la posibilidad misma de alcanzar el objetivo, varias compañías presentaron sus demostraciones de exportación / importación en este formato.

En noviembre de 1997, se lanzó la siguiente versión, 1.5, pero un intento de implementarla rápidamente reveló muchos errores que requerían el desarrollo de una versión fija 1.5.1, que se introdujo en paralelo con el desarrollo de la versión 2.0, que se introdujo en marzo de 1999.

Todas estas versiones ahora están en desuso.

La versión 2.1 se lanzó en noviembre de 2000. Esta es la versión más antigua para la que hay documentación disponible. Más tarde se publicó como ISO / PAS 16739: 2005.

Ahora la versión más común (que la mayoría de los programas entienden) es IFC 2.3.

Software

Para leer IFC, un editor de texto con resaltado de sintaxis es útil, por ejemplo, usé n ++ y código vs con mi torpe configuración de sintaxis IFC.

Pero otra herramienta necesaria será un programa capaz de visualizar gráficos en IFC. Ahora hay muchos espectadores para esto e incluso gratuitos; personalmente, prefiero XbimXplorer del proyecto xBIM . También utilicé Revit, pero debo decir que Revit puro no es muy amigable con IFC: ni siquiera es capaz de leer el archivo que creó (sí, Revit de Autodesk no sabe cómo trabajar con el formato inventado por Autodesk: esta es la tarjeta de presentación de Autodesk Pero simplemente no inventaron Revit, sino que lo compraron, como de costumbre, pero no tiene un complemento incorrecto para esto: IFC para Revit (mientras escribía el artículo, encontró varios errores, habrá que arreglarlo cuando haya tiempo ...)

Debo decir que el formato IFC es tan confuso que ningún programa lo maneja correctamente, cada uno lo hace a su manera. Entonces XbimXplorer ignora los gráficos 2D y algunos errores de sintaxis.

Descripción

El formato IFC existe en tres formas: IFC-SPF (.ifc), IFC-XML (.ifcXML), IFC-ZIP (.ifcZIP)
IFC-SPF es un formato de texto definido en ISO 10303-21; de hecho, es un archivo STEP
IFC-XML es un formato XML definido en ISO 10303-28 ("STEP-XML")
IFC-ZIP : un archivo zip que puede contener .ifc o .ifcXML

La estructura del archivo IFC-SPF se describe en ISO 10303-21 (hay GOST ISO 10303-21-2002) en notación Wirth. Este es un archivo de texto que usa solo caracteres con códigos en el rango 32-126 (la tercera edición permite el uso de caracteres con códigos 127-255, pero no se recomienda, por compatibilidad)
Los comentarios de varias líneas están marcados con pares de caracteres / * * /

Hay varias formas de escribir caracteres en una codificación diferente

Grabar ISO 8859 :
Directiva \ S \ - el código de caracteres después de la directiva indica el código de caracteres en la tabla ISO 8859-1
Directiva \ P * \: aquí, en lugar de *, debe haber una letra latina mayúscula, indica el número de la tabla ISO 8859 que se usa para la directiva \ S \, A significa ISO 8859-1, B significa ISO 8859-2, etc.

Grabar ISO 10646 :
Directiva \ X \: la directiva va seguida de un número hexadecimal de dos dígitos que indica un carácter en el rango de U + 0000 a U + 00FF
Directivas \ X2 \ * \ X0 \ y \ X4 \ * \ X0 \ - aquí en lugar de * hay una secuencia de números hexadecimales de dos dígitos (X2) o cuatro dígitos (X4) que denotan los caracteres correspondientes

Hola mundo => \ X2 \ 041F04400438043204350442 \ X0 \, \ X2 \ 041C04380440 \ X0 \!

Longitud máxima de cadena sin procesar: 32769 bytes

Estructura del archivo: el archivo comienza con la línea ISO-10303-21; y termina con la línea END-ISO-10303-21; aunque todavía puede haber una sección de firma SIGNATURE_SECTION, pero no consideraré esta opción.
Entre estas líneas debe haber una sección de encabezado HEADER_SECTION, después puede haber secciones ANCHOR_SECTION y / o REFERENCE_SECTION, así como una o más DATA_SECTION (en IFC solo hay una)

HEADER_SECTION: la estructura de la sección de encabezado de IFC solo permite tres elementos en esta sección: FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA

ENTITY file_description;
description : LIST [1:?] OF STRING (256) ;
implementation_level : STRING (256) ;
END_ENTITY;

Opción mínima:
FILE_DESCRIPTION (('ViewDefinition [CoordinationView_V2.0]'), '2; 1');
El contenido de la descripción es muy importante para IFC: enumera los complementos ViewDefinition utilizados, el contenido de requisito de Exchange y las opciones Opción [2] , pero solo se requiere el elemento ViewDefinition
El nivel de implementación consta de dos dígitos, el primero indica la edición de ISO-10303-21 (hay tres), el segundo es el modo de compatibilidad (hay dos), descrito en la cláusula 4.3 de ISO-10303-21. Para IFC, el nivel de implementación siempre importa: 2; 1

Otra opcion:
FILE_DESCRIPTION (('ViewDefinition [CoordinationView_V2.0, QuantityTakeOffAddOnView]', 'ExchangeRequirement [Structural]'), '2; 1');

ENTITY file_name;
name : STRING (256) ;
time_stamp : time_stamp_text ;
author : LIST [ 1 : ? ] OF STRING (256) ;
organization : LIST [ 1 : ? ] OF STRING (256) ;
preprocessor_version : STRING (256) ;
originating_system : STRING (256) ;
authorization : STRING (256) ;
END_ENTITY;

Todos los valores pueden dejarse en blanco. Nombre de archivo, marca de tiempo, autor, organización, versión del preprocesador, programa de autoría, autorización.

ENTITY file_schema;
schema_identifiers : LIST [1:?] OF UNIQUE schema_name;
END_ENTITY;

El nombre del esquema que describe el contenido de la sección de datos (consulte la columna Identificador en la tabla anterior)

La sección de datos comienza con la palabra clave DATA; y termina con ENDSEC; El contenido de esta sección es una secuencia de entidades de la siguiente sintaxis:
# <entidad índice> = <nombre de entidad> (<lista de atributos>);
Las posibles entidades y sus parámetros se describen en el gráfico IFC.

Archivo IFC vacío:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [CoordinationView_V2.0]'),'2;1');
FILE_NAME('','',(''),(''),'','','');
FILE_SCHEMA(('IFC2X3'));
ENDSEC;
DATA;
ENDSEC;
END-ISO-10303-21;

Sección de datos

El elemento raíz de IFC es IfcProject . Aquí es necesario decir cómo se forma la lista de atributos, que es necesaria para crear la entidad, en primer lugar, la entidad puede tener sus propios atributos y, en segundo lugar, puede heredarlos del antepasado, se especifica el orden de los atributos, desde el antepasado hasta el descendiente. Para IfcProject, la cadena de herencia será la siguiente: IfcRoot => IfcObjectDefinition => IfcObject => IfcProject.

IFCPROJECT(<GlobalId>,<OwnerHistory>,<>,<>,<ObjectType>, <LongName>,<Phase>, (<RepresentationContexts>),<UnitsInContext>);

Ahora, para crear un IfcProject, necesitamos establecer los valores para todos los atributos. El primer atributo heredado de IfcRoot - GlobalId, tiene el valor IfcGloballyUniqueId. Este es un tipo simple: una cadena con una longitud de 22 caracteres, debe escribir un GUID o UUID único en ellos, de modo que un número de 128 bits se inserte en 22 caracteres; hay un algoritmo especial publicado en el sitio web buildingSMART [3] . El siguiente atributo OwnerHistory se establece en IfcOwnerHistory. Este elemento responde a las preguntas: quién, cómo y cuándo se creó este elemento IFC, de hecho, para casi todos los objetos en IFC, su autor se puede indicar a través de este elemento. Para completar este atributo, puede crear un elemento "en el lugar", pero es mejor hacerlo en otro lugar, y en el lugar solo consúltelo con un registro del formulario # <entidad índice>. El símbolo $ también significa un valor nulo, el símbolo * se usa si el descendiente asigna el valor al atributo del antepasado. Los valores de tipo enum se escriben entre dos puntos: .ELEMENT.

Un ejemplo de creación de IfcProject:
#1=IFCPROJECT('abcdefghijklmnopqrs101', #2, 'sample project', $, $, '','',$,$);
#2=IFCOWNERHISTORY(#3,#6,.READWRITE.,.ADDED.,87763554,#3,#6,87763554);
#3=IFCPERSONANDORGANIZATION(#4,#5,());
#4=IFCPERSON('Public','Jane','Q.',(),(),(),(),());
#5=IFCORGANIZATION($,'Architecture by Jane Q. Public, Inc.',$,(),());
#6=IFCAPPLICATION(#7,'Version 1.0','Building Architecture Toolkit','BAT1.0');
#7=IFCORGANIZATION($,'Creating Instance Software, Inc.',$,(),());

Los siguientes elementos <Name>, <Description>, <ObjectType>, <LongName>, <Phase> - opcional y texto (IfcLabel, IfcText) - descripción del proyecto para una persona

RepresentationContexts es una lista de espacios / contextos, la idea era que podríamos tener varios espacios / contextos, por ejemplo: un boceto, un proyecto y documentación de trabajo. Y diferentes objetos pueden tener diferentes representaciones en diferentes contextos. Por ejemplo, el muro en el boceto es solo una línea, en el proyecto ya tiene un grosor y en la documentación de trabajo consta de diferentes capas. Pero en IFC2x3 el concepto ha cambiado, los contextos de 'Boceto', 'Esquema', 'Diseño', 'Detalle' se cancelaron o se trasladaron a IfcGeometricRepresentationSubContext. Y la clase IfcRepresentationContext en sí se hizo abstracta, con un solo descendiente: IfcGeometricRepresentationContext, que puede ser volumétrico ContextType = 'Model', CoordinateSpaceDimension = 3, flat ContextType = 'Plan', CoordinateSpaceDimension = 2 y FIG sabe qué ContextType = 'NotDefined'.

IFCGEOMETRICREPRESENTATIONCONTEXT(<>,<>,< >,< - >,< >,< >)

UnitsInContext: un objeto IfcUnitAssignment que forma una lista de elementos IfcUnit con una descripción de las unidades del proyecto, es necesario para la importación adecuada; de lo contrario, el software usará su configuración predeterminada; en Revit, por ejemplo, hay pies (almacena todo en pies).

#2= IFCSIUNIT(*,.LENGTHUNIT.,.MILLI.,.METRE.);
#3= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#4= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#5= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#6= IFCUNITASSIGNMENT((#2,#3,#4,#5));


A partir del elemento raíz IfcProject, se forma un árbol de elementos, los descendientes del tipo IfcSpatialStructureElement (IfcBuilding (edificio), IfcBuildingStorey (piso), IfcSpace (espacio o habitación), IfcSite (sitio)). Pero estos elementos no están conectados directamente, sino a través de un elemento especial IfcRelAggregates, en una relación de uno a muchos.

IFCRELAGGREGATES(<GlobalId>, <OwnerHistory>, <>, <>, < >, (< >));

Estos elementos solo pueden conectarse en el siguiente orden: IfcSite => IfcBuilding => IfcBuildingStorey => IfcSpace, y los elementos del mismo tipo pueden conectarse, pero su atributo CompositionType debe tener un valor diferente y solo en un cierto orden COMPLEX => ELEMENT => PARTIAL

Estructura completa posible del proyecto:
IfcSite.COMPLEX => IfcSite.ELEMENT => IfcSite.PARTIAL => IfcBuilding.COMPLEX => IfcBuilding.ELEMENT => IfcBuilding.PARTIAL => IfcBuildingStorey.COMPLEX => IfcBuildingStoreyCIAL = PARTIRE> = IfcSpace.ELEMENT => IfcSpace.PARTIAL

archivo ifc

Aunque todos los elementos son opcionales, solo se requiere el orden de herencia
Se supone que está describiendo un Edificio, que consta de pisos de plantas y en los que existen espacios, debe mostrar el relieve del sitio existente en el que ingresa a su edificio

IFCSITE(<GlobalId>,<OwnerHistory>,<>,<>,<ObjectType>,<ObjectPlacement>,<Representation>,<LongName>,<CompositionType>,<RefLatitude>,<RefLongitude>,<RefElevation>,<LandTitleNumber>,<SiteAddress>);

El atributo Representación heredado de IfcProduct apunta a un objeto IfcProductRepresentation, tiene dos descendientes IfcProductDefinitionShape para describir la forma del objeto y IfcMaterialDefinitionRepresentation para describir el material (estilo de visualización), vinculan diferentes representaciones a través del atributo Representaciones.

IfcProductDefinitionShape(<>,<>,(<Representations>))
IfcMaterialDefinitionRepresentation(<>, <>,<Representations>),<RepresentedMaterial>)

IfcMaterialDefinitionRepresentation for Representations solo acepta IfcStyledRepresentation - descripciones de estilo
El atributo RepresentedMaterial proporciona una descripción textual del material del objeto.
IfcProductDefinitionShape for Representations solo acepta IfcShapeRepresentation o IfcTopologyRepresentation (IfcShapeModel)

IfcShapeRepresentation es la clase más importante en IFC porque es responsable de la representación geométrica de los objetos. Tipos de geometría disponibles: Curve2D (líneas planas), GeometricSet (puntos, líneas, superficies, 2d y 3d), SurfaceModel (superficies), SolidModel (cuerpos), tipos adicionales (BoundingBox, SectionedSpine, MappedRepresentation)

IFCSHAPEREPRESENTATION(<>,<RepresentationIdentifier>,< >,< >);

En el corazón de cualquier geometría está el elemento IfcCartesianPoint, solo un punto.
#13= IFCCARTESIANPOINT((0.,0.,0.));
#16= IFCCARTESIANPOINT((1.,0.,0.));
#22= IFCPOLYLINE((#13, #16));

#510= IFCBSPLINECURVEWITHKNOTS(3,(#511,#512,#513,#514,#511,#512,#513),.UNSPECIFIED.,.T.,.T.,(1,1,1,1,1,1,1,1,1,1,1),(-7.0,-6.0,-5.0,-4.0,-3.0,-2.0,-1.0,0.0,1.0,2.0,3.0),.UNSPECIFIED.);
#511= IFCCARTESIANPOINT((239.758213537139,192.193559404919,-83.9999999999991));
#512= IFCCARTESIANPOINT((0.0,275.591853484122,-83.9999999999991));
#513= IFCCARTESIANPOINT((-239.75821353295,192.193559404918,-83.9999999999991));
#514= IFCCARTESIANPOINT((0.0,-108.13323051355,-83.9999999999991));

#34= IFCSHAPEREPRESENTATION(#7,'Body','SweptSolid',(#35));
#35= IFCEXTRUDEDAREASOLID(#36,#8,#37,0.5);
#36= IFCRECTANGLEPROFILEDEF(.AREA.,$,#38,0.5,0.5);
#37= IFCDIRECTION((0.,0.,1.));
#38= IFCAXIS2PLACEMENT2D(#39,#9);
#7= IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,0.01,#8,#9);
#8= IFCAXIS2PLACEMENT3D(#10,$,$);
#9= IFCDIRECTION((0.,1.));
#39= IFCCARTESIANPOINT((0.,0.));

La geometría puede consistir simplemente en una lista de puntos, o puede tener una estructura compleja con un montón de parámetros y elementos secundarios.
Considere IfcExtrudedAreaSolid(<SweptArea>,<Position>,<ExtrudedDirection>,<Depth>)

Este es el cuerpo obtenido al extruir el contorno plano original SweptArea ubicado en el espacio de posición extruido en la dirección de ExtrudedDirection a la profundidad de ExtrudedDirection. El atributo SweptArea es de tipo IfcProfileDef: esta es una clase abstracta con una gran cantidad de descendientes "para todas las ocasiones", en este caso se IfcRectangleProfileDef(<ProfileType>,<ProfileName>,<Position>,<XDim>,<YDim>)

ProfileType: valor de enumeración de tipo de perfil de tipo IfcProfileTypeEnum (Valores: CURVA, ÁREA). El nombre opcional del perfil ProfileName, el posicionamiento de posición y el tamaño por coordenadas XY son XDim, YDim.


O el IfcFacetedBrep más complejo, consiste en un IfcClosedShell cerrado, que a su vez consiste en una lista de caras IfcFace, que consta de bordes IfcFaceBound, que se describen mediante bucles IfcLoop, que ya consisten en puntos IfcCartesianPoint. La representación de límites (brep) dicta muchas condiciones en su estructura, descritas en detalle en la documentación y literatura relacionada.

#57= IFCSHAPEREPRESENTATION(#7, 'Body', 'Brep', (#58));
#58= IFCFACETEDBREP(#59);
#59= IFCCLOSEDSHELL((#80, #81, #82, #83, #84, #85));

#60 = IFCCARTESIANPOINT((0.,0.,0.));
#61 = IFCCARTESIANPOINT((1.,0.,0.));
#62 = IFCCARTESIANPOINT((1.,1.,0.));
#63 = IFCCARTESIANPOINT((0.,1.,0.));
#64 = IFCCARTESIANPOINT((0.,0.,1.));
#65 = IFCCARTESIANPOINT((1.,0.,1.));
#66 = IFCCARTESIANPOINT((1.,1.,1.));
#67 = IFCCARTESIANPOINT((0.,1.,1.));

#68= IFCPOLYLOOP((#60, #61, #62, #63));
#69= IFCPOLYLOOP((#64, #65, #66, #67));
#70= IFCPOLYLOOP((#60, #61, #65, #64));
#71= IFCPOLYLOOP((#61, #62, #66, #65));
#72= IFCPOLYLOOP((#62, #63, #67, #66));
#73= IFCPOLYLOOP((#63, #60, #64, #67));

#74= IFCFACEOUTERBOUND(#68, .T.);
#75= IFCFACEOUTERBOUND(#69, .T.);
#76= IFCFACEOUTERBOUND(#70, .T.);
#77= IFCFACEOUTERBOUND(#71, .T.);
#78= IFCFACEOUTERBOUND(#72, .T.);
#79= IFCFACEOUTERBOUND(#73, .T.);

#80= IFCFACE((#74));
#81= IFCFACE((#75));
#82= IFCFACE((#76));
#83= IFCFACE((#77));
#84= IFCFACE((#78));
#85= IFCFACE((#79));




IfcAdvancedBrep ha aparecido en IFC4, cuyos bordes pueden describirse mediante curvas NURBS



Los objetos IfcSpatialStructureElement pueden tener su propia geometría, pero en general, los edificios consisten en otros objetos: paredes, pisos, techos, ventanas, puertas, etc. En IFC, todos estos objetos se describen mediante los objetos correspondientes: IfcWall, IfcSlab, IfcRoof, IfcWindow, IfcDoor - todos son descendientes de IfcProduct. Todos estos objetos pueden asociarse con el objeto IfcSpatialStructureElement correspondiente, a través del objeto especial IfcRelContainedInSpatialStructure



IFCRELCONTAINEDINSPATIALSTRUCTURE(<GlobalId>,<OwnerHistory>,<>,<>, (<RelatedElements>),<RelatingStructure>)

Para paredes de espesor constante, es habitual usar IfcWallStandardCase (considerado obsoleto en IFC4), para otros casos usamos IfcWall. En el caso de IfcWallStandardCase, debe utilizar SweptSolid: extrusión del contorno de la pared a una altura determinada

IFCWALLSTANDARDCASE(<GlobalId>,<OwnerHistory>,<>,<>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>);

#8= IFCAXIS2PLACEMENT3D(#10,$,$);
#10= IFCCARTESIANPOINT((0.,0.,0.));
#13= IFCLOCALPLACEMENT($,#8);
#22= IFCDIRECTION((0.,0.,1.));
#23= IFCAXIS2PLACEMENT2D(#24,#25);
#24= IFCCARTESIANPOINT((0.,0.));
#25= IFCDIRECTION((1.,0.));
#26= IFCWALLSTANDARDCASE('abcdefghijklmnopqrs107',$,'wall1',$,'',#13,#27,'');
#27= IFCPRODUCTDEFINITIONSHAPE($,$,(#28));
#28= IFCSHAPEREPRESENTATION(#7,'Body','SweptSolid',(#29));
#29= IFCEXTRUDEDAREASOLID(#30,#32,#22,1000.);
#30= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,100.,1000.);
#31= IFCCARTESIANPOINT((500.,0.,100.));
#32= IFCAXIS2PLACEMENT3D(#31,$,$);


La puerta está descrita por el objeto IfcDoor, se puede agregar a IfcRelContainedInSpatialStructure, pero este objeto no hace un "corte" en la pared por sí mismo



El objeto especial "IfcOpeningElement" es responsable del "corte", que está asociado con el objeto "padre" a través de IfcRelVoidsElement. En IfcOpeningElement, puede "insertar" una puerta utilizando el objeto IfcRelFillsElement. Con IfcOpeningElement puede hacer no solo agujeros pasantes, sino también huecos.





IFCDOOR(<GlobalId>,<OwnerHistory>,<>,<>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<OverallHeight>,<OverallWidth>)

IFCWINDOW(<GlobalId>,<OwnerHistory>,<>,<>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<OverallHeight>,<OverallWidth>)

Si el objeto cWindow es muy similar en uso, ifcDoor, OverallHeight, OverallWidth (dimensiones nominales, no puede especificar), estos valores se tomarán de la geometría

El objeto IfcRoof está implicado por un objeto complejo (debe describir todo el techo, para conectar a todos los niños con él), debe usar IfcRelAggregates. Pero al mismo tiempo, IfcRoof puede tener su propia geometría de representación.
IFCSLAB(<GlobalId>,<OwnerHistory>,<>,<>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<PredefinedType>);
IFCROOF(<GlobalId>,<OwnerHistory>,<>,<>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<IfcRoofTypeEnum>);

Escribiendo IFC

Ahora, armados con este conocimiento, trataremos de describir una casa simple, para empezar tomaremos un archivo IFC vacío, cuya descripción ya he proporcionado.

A continuación, debemos completar el contenido de la sección DATOS. El primer objeto requerido debe ser IFCPROJECT (aunque puede estar al final del archivo, pero solo debe serlo), también necesitamos IFCUNITASSIGNMENT, si queremos que los programas lean el modelo en las unidades de medida que tenemos en mente. También necesitaremos al menos un IFCGEOMETRICREPRESENTATIONCONTEXT; de lo contrario, no podremos agregar una descripción de la geometría.



Estructura de la casa








Para describir la puerta, usamos IFCFACETEDBREP y lo usamos para el elemento IFCOPENINGELEMENT en el que se inserta nuestra puerta. Usando diferentes IFCLOCALPLACEMENTs, podemos insertar la misma geometría en diferentes lugares y representar diferentes objetos; por ejemplo, podemos usar el mismo IFCFACETEDBREP para la ventana.




archivo terminado

Conclusión

Ahora, mi querido lector, puedes escribir la casa de tus sueños. Desafortunadamente, no consideré IfcMaterialDefinitionRepresentation, que fue rechazado por el estilo de visualización de objetos, no consideré IfcTopologyRepresentation. Realmente no entiendo para qué sirve y no sé cómo visualizarlo. No consideré las opciones de IFC y los conjuntos adicionales de propiedades. Pero de lo contrario, esta no sería una breve introducción.

El formato IFC contiene una gran cantidad de objetos, que se vuelven solo de una versión a otra. En el texto de especificación hay notas que no se reflejan en el esquema EXPRESS, pero que afectan fuertemente el procesamiento del archivo. Por lo tanto, es difícil implementar este formato sin haber leído cuidadosamente toda la documentación, pero esto no es posible para una persona, por lo tanto, no existe un programa, que lo lea de manera absolutamente correcta, cada uno tiene sus propias características. Y si en el caso de los programas de código abierto siempre existe la oportunidad de corregir los errores detectados, para los programas propietarios esto hace que sea imposible utilizar completamente el formato IFC.

El formato IFC no es absolutamente adecuado para almacenar información de la sección del plan general, pero actualmente hay un trabajo activo en esta sección, este trabajo debe completarse a fines de abril de 2020 y ser parte de IFC5. También ahora, se está trabajando en IFC Road, IFC Airport y IFC4precast (precast). IFC Bridge apareció en IFC4x2, para el cual se les ocurrió un objeto geométrico especial: IfcSectionedSolidHorizontal

Los cambios recientes en IFC lo acercan mucho a GML, incluso si ha aparecido IfcCoordinateReferenceSystem, una descripción del sistema de coordenadas geodésicas. Al mismo tiempo, IFC se centra en la descripción de las estructuras internas del objeto, y GML describe su representación externa. Pero la principal diferencia entre IFC es que es posible referirse a los mismos objetos en diferentes lugares: el mismo punto se puede usar en la descripción de la geometría de la pared y la ventana. En GML, cada objeto geométrico es completamente independiente.

Referencias
1) www.ibpsa.org/proceedings/BS1997/BS97_P125.pdf
2) standards.buildingsmart.org/documents/Implementation/ImplementationGuide_IFCHeaderData_Version_1.0.2.pdf
3) technical.buildingsmart.org/resources/ifcimplementationguidance/ifc-guid