archive-org.com » ORG » B » BUILDINGSMART-TECH.ORG

Total: 393

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • #CV-2x3-150 — Welcome to buildingSMART-Tech.org
    view date 24 Jun 2008 initiator ISG meeting in Amsterdam summary agreement on how to split an opening between two walls e g in a staircase Description If an opening is inserted into two walls that join vertically as in a staircase the following transformations have to be made for IFC export the opening is split into two openings each of them is assigned to one wall the IFC export has 2 instances of IfcOpeningElement if the opening has a window as the filling the whole window is assigned to one opening not split usually the lower opening the IFC export has 1 instance of IfcWindow NOTE In case of parametric definition of the window shape the IfcWindow has to have an IfcShapeRepresentation with RepresentationIdentifier Profile since the profile of the window is not equal to the profile of the opening See also CV 2x3 103 Previous CV 2x3 149 Next CV 2x3 151 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 150 IFC Impl Guide IFC Header Guide IFC4 impl guidance Implementer s community accompanying documents frequently asked questions Implementations Search Advanced Search IFC Dev Blog IFC Dev Blog More Registration This

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-150 (2016-02-11)
    Open archived version from archive


  • #CV-2x3-151 — Welcome to buildingSMART-Tech.org
    between first level and second level number CV 06 151 based on IFC2x3 effects extended coordination view date 24 Jun 2008 initiator ISG meeting in Amsterdam summary Agreement on how to differentiate space boundaries between first level and second level Description The instances of IfcRelSpaceBoundary should be differentiated by the Name attribute for first level space boundaries set Name 1stLevel e g 250 IFCRELSPACEBOUNDARY 3nzLNSko1B7gq78r6E6aVI 5 1stLevel 46 67 252 PHYSICAL NOTDEFINED for second level space boundaries set Name 2ndLevel 250 IFCRELSPACEBOUNDARY 3nzLNSko1B7gq78r6E6aVI 5 2ndLevel 46 67 252 PHYSICAL NOTDEFINED In addition check the IFC Header Implementation Guide to set the addon View definition to either SpaceBoundary1stLevelAddOnView or SpaceBoundary2ndLevelAddOnView It should be exported as FILE DESCRIPTION ViewDefinition CoordinationView SpaceBoundary1stLevelAddOnView 2 1 FILE DESCRIPTION ViewDefinition CoordinationView SpaceBoundary2ndLevelAddOnView 2 1 Previous CV 2x3 150 Next CV 2x3 152 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 151 IFC Impl Guide IFC Header Guide IFC4 impl guidance Implementer s community accompanying documents frequently asked questions Implementations Search Advanced Search IFC Dev Blog IFC Dev Blog More Registration This site contains content which is only available to registered users To get access to the content you must

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-151 (2016-02-11)
    Open archived version from archive

  • #CV-2x3-152 — Welcome to buildingSMART-Tech.org
    all spaces shall have a body shape representation number CV 06 152 based on IFC2x3 effects extended coordination view date 24 Jun 2008 initiator ISG meeting in Amsterdam summary agreement that all spaces shall have a body shape representation Description For all spaces that have a volume in the sending application it is required to export a Body space representation with either SweptSolid Clipping or Brep geometry Optional but recommended the export should also include an FootPrint space representation with either Curve2D or GeometricCurveSet geometry The additional agreements have been made If the Body space representation Brep then a FootPrint shape representation is required It is not sufficient and legal to only export the space boundaries and to skip the Body shape representation Previous CV 2x3 151 Next CV 2x3 153 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 152 IFC Impl Guide IFC Header Guide IFC4 impl guidance Implementer s community accompanying documents frequently asked questions Implementations Search Advanced Search IFC Dev Blog IFC Dev Blog More Registration This site contains content which is only available to registered users To get access to the content you must be a registered user Please

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-152 (2016-02-11)
    Open archived version from archive

  • #CV-2x3-153 — Welcome to buildingSMART-Tech.org
    agreement that virtual elements should could be ignored on import number CV 06 153 based on IFC2x3 effects extended coordination view date 24 Jun 2008 initiator ISG meeting in Amsterdam summary agreement that virtual elements should could be ignored on import Description Virtual elements are often exported to define the topology between two spaces with no separating wall or slab in between Those virtual elements are then generated during export On import into CAD they are normally discarded and reestablished when an IFC file is exported again Therefore not importing IfcVirtualElement into a CAD BIM application shall not be reported as an error in a log file it would confuse the user as it shows an error where there is no error Previous CV 2x3 152 Next CV 2x3 154 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 153 IFC Impl Guide IFC Header Guide IFC4 impl guidance Implementer s community accompanying documents frequently asked questions Implementations Search Advanced Search IFC Dev Blog IFC Dev Blog More Registration This site contains content which is only available to registered users To get access to the content you must be a registered user Please log

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-153 (2016-02-11)
    Open archived version from archive

  • #CV-2x3-154 — Welcome to buildingSMART-Tech.org
    on the compression mechanism for ifcZIP Description All ifcZIP files are written using the pkzip compression There shall be only a single ifc file or only a single ifcXML file in the main directory of the ifcZIP i e zip file Therefore the same compression mechanism shall be used for ifc and ifcXML files NOTE Later agreements may propose a sub directory structure for linked documents texture files etc update based on ISG meeting Munich 23 Oct 2008 All ifcZIP files are written using the PKZip 2 04g compression that limits the zip support to exclude encryption unicode support and usage of deflate64 mechanism This compression is compatible with the Windows Compressed Folders winzip info zip and zlib The ifcZIP file extension can be associated with any IFC compatible software that decompresses the ifcZIP file before import The ifcZIP extension shall be associated with the official buildingSMART logo for ifcZIP files Previous CV 2x3 153 Next CV 2x3 155 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 154 IFC Impl Guide IFC Header Guide IFC4 impl guidance Implementer s community accompanying documents frequently asked questions Implementations Search Advanced Search IFC Dev Blog IFC

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-154 (2016-02-11)
    Open archived version from archive

  • #CV-2x3-155 — Welcome to buildingSMART-Tech.org
    creating 1stLevel space boundaries Creation of space boundaries based on element type Building elements one space boundary type physical is created for each surface to the adjacent space No inner loops to be created for openings in the building element Doors and windows one space boundary type physical is created The space boundary is not cut out of the wall space boundary see above so wall and door window space boundary are overlapping The opening element into which the door window is inserted is not considered shall not have an own space boundary Openings that are not filled with door window one space boundary type virtual is created The space boundary is not cut out of the wall space boundary see above so wall and opening space boundary are overlapping NOTE It currently violates WR1 at IfcRelSpaceBoundary it is an accepted exception and will be fixed in next IFC version Geometry type of the IfcRelSapceBoundary ConnectionGeometry for straight walls IfcSurfaceOfLinearExtrusion or IfcCurveBoundedPlane for round walls prismatic IfcSurfaceOfLinearExtrusion under a sloped roof IfcFaceBasedSurfaceModel Previous CV 2x3 154 Next CV 2x3 156 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 155 IFC Impl Guide IFC

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-155 (2016-02-11)
    Open archived version from archive

  • #CV-2x3-156 — Welcome to buildingSMART-Tech.org
    NOTE if the wall have different assignments to CAD presentation layer e g one per each wall material layer it is the task of the sending application to decide about the main CAD presentation layer optionally individual wall slab or plate material layers can have an additional assignment to CAD presentation layer different per material layer when using the IfcMaterialDefinitionRepresentation assignment addition 20 03 2011 initiator Coordination View Version 2 0 model view definition The original agreement has been extended to all elements having shape representation the word wall has been replaced by element in the agreement text above For all subtypes of IfcElement with the exception of IfcFeatureElement subtypes and IfcVirtualElement that have a representation provided by one or many IfcShapeRepresentation s the following requirement applies for all IfcShapeRepresentation with the RepresentationIdentifier Body the inverse relation LayerAssignments to IfcPresentationLayerAssignment shall be provided for all other IfcShapeRepresentation having an RepresentationIdentifier not equal to Body the inverse relation LayerAssignments to IfcPresentationLayerAssignment may be provided but it is not required addition 03 05 2011 initiator Coordination View Version 2 0 model view definition The following clarification has been added the IfcPresentationLayerAssignment for the Body representation and the other representations like Axis or FootPrint if assigned to a CAD presentation layer can be either the same CAD presentation layer or different onces if the subtype of IfcElement has aggregated parts and those parts have the Body shape representation then the parts are required to have an assignment to the CAD presentation layer See also Implementer Agreement CV 2x3 119 If the IfcElement representing the whole has an own shape representation required to be different to Body by CV 2x3 119 it maybe assigned to a CAD presentation layer but is not required to Previous CV 2x3 155 Next CV 2x3 157 Implementation get

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-156 (2016-02-11)
    Open archived version from archive

  • #CV-2x3-157 — Welcome to buildingSMART-Tech.org
    architectural structural design applications Such proposals for openings or provisions for voids are 3D bodies that indicated the required void for building service flow segments The voids are not yet subtractions of the building element wall slab but placeholders that have to be converted into real openings by the architect or structural designer It reflects a very common and highly important coordination task that should be supported by the coordination view The agreement includes any provision for void element should be exchanged as IfcBuildingElementProxy with ObjectType ProvisionForVoid It refers to a property set with Name Pset ProvisionForVoid The property set has the following properties defined Width The width horizontal extension in elevation of the provision for void only provided if the Shape property is set to rectangle IfcLengthMeasure Height The height vertical extension in elevation of the provision for void only provided if the Shape property is set to rectangle IfcLengthMeasure Diameter The diameter in elevation of the provision for void only provided if the Shape property is set to round IfcLengthMeasure Depth The depth or thickness of the provision for void IfcLengthMeasure Shape The shape form of the provision for void the minimum set of agreed values includes Rectangle Round and Undefined IfcLabel System The building service system that requires the provision for voids e g Air Conditioning Plumbing Electro etc IfcLabel A sample ifc file would include 33 IFCBUILDINGELEMENTPROXY 2JlkZSa vF3xOXqR OrxWi 5 any name any description ProvisionForVoid 36 111 ELEMENT 37 IFCRELDEFINESBYPROPERTIES 3DibaTRPH5NhSyVCFz19Aj 5 33 38 38 IFCPROPERTYSET 3nTXJcSDf55e44yDrj6mHj 5 Pset ProvisionForVoid 44 45 46 47 48 44 IFCPROPERTYSINGLEVALUE System IFCLABEL Waste Water System 45 IFCPROPERTYSINGLEVALUE Shape IFCLABEL Rectangular 46 IFCPROPERTYSINGLEVALUE Width IFCLENGTHMEASURE 300 0000 47 IFCPROPERTYSINGLEVALUE Height IFCLENGTHMEASURE 300 0000 48 IFCPROPERTYSINGLEVALUE Depth IFCLENGTHMEASURE 524 0000 Previous CV 2x3 156 Next CV 2x3 158 Implementation get

    Original URL path: http://www.buildingsmart-tech.org/implementation/ifc-implementation/ifc-impl-agreements/cv-2x3-157 (2016-02-11)
    Open archived version from archive



  •