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-118 — Welcome to buildingSMART-Tech.org
    the pattern start for the reference hatch line The datatype is in both cases an Cartesian point however one Cartesian point is sufficient to provide both the origin and the pattern start The following agreement is made PatternStart A Cartesian point which defines the offset of the reference hatch line from the origin of the virtual hatching coordinate system The origin is used for mapping the fill area style hatching onto an annotation fill area or surface The reference hatch line would then appear with this offset from the fill style target point In addition it may provide the start point for the curve style font pattern of the reference hatch line if the curve style is different to continuos If not given the reference hatch line goes through the origin of the virtual hatching coordinate system PointOfReferenceHatchLine The usage of the attribute PointOfReferenceHatchLine is deprecated the attribute PatternStart is used to provide both the point through which the reference hatch line goes and the start of the pattern sequence of that reference hatch line Previous CV 2x3 117 Next CV 2x3 119 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 118 IFC

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


  • #CV-2x3-119 — Welcome to buildingSMART-Tech.org
    at the element part level Description The IFC specification allows all subtypes of IfcBuildingElement and other to act as a container entity i e to be a decomposed element having parts This is expressed by an IfcRelAggregates relationship entity pointing to the container with RelatingObject and it referenced by the inverse attribute IsDecomposedBy An example is a roof containing two roof slabs IfcRoof RelatingObject IfcRelAggregates RelatedObjects IfcSlab PredefinedType ROOF The following agreement is made If the building element acts as a container i e has parts associated and those parts have own shape representations then the container shall have no shape representation addition 2011 03 10 initiator Coordination View V2 0 model view definition development The requirement only concerns the shape representation of the container with RepresentationIdentifier Body The container may have an own shape representation e g of RepresentationIdentifier Axis or Box even if the parts have the shape representation with RepresentationIdentifier Body Figure correct assignment of Body shape representation to parts only see also agreement CV 06 120 CV 06 121 Previous CV 2x3 118 Next CV 2x3 120 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 119 IFC Impl Guide

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

  • #CV-2x3-120 — Welcome to buildingSMART-Tech.org
    allows all subtypes of IfcBuildingElement and other to act as a container entity i e to be a decomposed element having parts This is expressed by an IfcRelAggregates relationship entity pointing to the container with RelatingObject and it referenced by the inverse attribute IsDecomposedBy An example is a roof containing two roof slabs IfcRoof RelatingObject IfcRelAggregates RelatedObjects IfcSlab PredefinedType ROOF The following agreement is made If the building element is a container then the material information IfcRelAssociatesMaterial IfcMaterial IfcMaterialLayerSet IfcMaterialLayerSetUsage shall only be assigned to the parts not to the container update 06 07 2011 agreement for the IFC2x3 Coordination View V2 0 The material information may either be provided at the decomposed parts of the element container or to the type of that part Taking the example from above If the building element is a container then the material information shall either be assigned to the parts here IfcSlab or to the type of the part here IfcSlabType referenced by IfcSlab IfcRelDefinesByType IfcSlabType see also agreement CV 06 119 CV 06 121 Previous CV 2x3 119 Next CV 2x3 121 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 120 IFC Impl Guide

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

  • #CV-2x3-121 — Welcome to buildingSMART-Tech.org
    been withdrawn with immediate effect The IFC2x3 Coordination View 2 0 compliant applications shall support a decomposition depths of more than one level NOTE In order to avoid potential endless recursions it is agreed to end import routines after the 9th level of decomposition See also agreements CV 06 119 CV 06 120 Outdated agreement The IFC specification allows all subtypes of IfcBuildingElement and other to act as a container entity i e to be a decomposed element having parts This is expressed by an IfcRelAggregates relationship entity pointing to the container with RelatingObject and it referenced by the inverse attribute IsDecomposedBy An example is a roof containing two roof slabs IfcRoof RelatingObject IfcRelAggregates RelatedObjects IfcSlab PredefinedType ROOF The following agreement is made The parts contained within an element container shall not be containers by themselves I e the decomposition hierarchy shall only have 1 level depth Example The roof slabs in the roof example above shall not be aggregated into rafters and claddings as this would be a 2 level deep decomposition Previous CV 2x3 120 Next CV 2x3 122 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 121 IFC Impl Guide

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

  • #CV-2x3-122 — Welcome to buildingSMART-Tech.org
    element should be related to the opening created in the voided element and not an arbitrary size of a subtraction body as in an CSG difference operation However in many cases these sizes of the opening element and the created void cannot be identical One example is the opening in a round wall where the opening body when extruded horizontally need to be bigger than the body of the round wall The following agreement has been made the size of the opening element should not exceed the bounding box of the voided element the receiving system may increase the opening extrusion depth by an acceptable epsilon value to avoid numerical problems with the faces NOTE added 04 11 2011 See also CV 2x3 112 about CSG being allowed for export in IFC2x3 Coordination View V2 0 In all cases where the opening does not represent an opening recess as a semantic object providing a passageway for people good light air fluids etc use CSG shape representation instead Previous CV 2x3 121 Next CV 2x3 123 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 122 IFC Impl Guide IFC Header Guide IFC4 impl guidance

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

  • #CV-2x3-123 — Welcome to buildingSMART-Tech.org
    the wall face or slab profile not misused as arbitrary cuttings Description The IfcOpeningElement is used to denote a semantic object being either an opening or a recess it should not be used in a general sense of a subtraction body such as in a CSG difference operation Therefore the IfcOpeningElement should not be used to create arbitrary clippings cut out or other features Example Illegal use of the IfcOpeningElement for an arbitrary clipping of the body of an IfcWallStandardCase The following agreement is made The IfcOpeningElement shall only be used for true openings and recesses created for a particular design intent Geometrically the IfcOpeningElement is constraint to be within the body of the voided element with the exception that the extrusion thickness may extend the thickness of the voided element see also agreement CV 06 122 For all other clippings cut outs etc the RepresentationType Clipping using subtype of IfcHalfSpaceSolid or Brep or CSG should be used Note see CV 2x3 112 for agreements on support for CSG on export and import Previous CV 2x3 122 Next CV 2x3 124 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 123 IFC Impl Guide

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

  • #CV-2x3-124 — Welcome to buildingSMART-Tech.org
    in the IFC specification In addition the following requirement has to be met instances of IfcWallStandardCase shall be extruded vertically i e the wall body extrusion direction shall be along the positive z axis of the local placement of the wall and along the global positive Z axis Previous CV 2x3 123 Next CV 2x3 125 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV

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

  • #CV-2x3-125 — Welcome to buildingSMART-Tech.org
    view date 05 May 2006 initiator ISG meeting Munich summary agreements on the limited subset of hatching style entities and attributes to be supported Description For the implementation of hatchings within the IFC2x3 extended coordination view the following agreements and limitations are made the supported hatchings are exported as model hatches the TargetScale attribute of the associated representation context provides the scale factor to convert the model hatch into a drafting hatch for the given target plot scale the support for IfcFillAreaStyle is restricted to IfcFillAreaStyle with FillStyles being IfcColour for background or solid colour and IfcFillAreaStyleHatching one zero one or two instances of IfcFillAreaStyleHatching are supported within FillStyles IfcFillAreaStyleTiles and IfcExternallyDefinedHatchStyle are not supported within IfcFillAreaStyleHatching the distance between two hatch lines is given by an IfcPositiveLengthMeasure not by IfcOneDirectionRepeatFactor IfcPointOfReferenceHatchLine is not supported see agreement CV 06 118 see also agreement CV 06 113 Previous CV 2x3 124 Next CV 2x3 126 Implementation get involved first steps and tools IFC2x3 impl guidance IFC Impl Agreements CV 2x3 125 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-125 (2016-02-11)
    Open archived version from archive



  •