A small step to parameterizing IFC?

1

It would seem like it would be very helpful to have techniques like the following in IFC.

  • #148= IFCBUILDINGSTOREY(‘2Xg7c1A415nR_KbA9qpXi$’,#42,‘Level 1’,,'Level:Story Level',#146,,‘Level 1’,.ELEMENT.,0.);
  • #154= IFCBUILDINGSTOREY(‘2Xg7c1A415nR_KbA9qp4ns’,#42,‘Level 2’,,'Level:Story Level',#153,,‘Level 2’,.ELEMENT.,12.);
    • #219= IFCWALLSTANDARDCASE(‘3aOFpwRCn36Pv_D8U$GBBQ’,#42,‘Basic Wall:Testy Wall Type:153022’,$,‘Basic Wall:Testy Wall Type’,#183,#213,‘153022’);
      • #213= IFCPRODUCTDEFINITIONSHAPE(,,(#188,#210));
        • #210= IFCSHAPEREPRESENTATION(#125,‘Body’,‘SweptSolid’,(#200));
          • #200= IFCEXTRUDEDAREASOLID(#198,#199,#20,#154.elevation - #148.elevation);
            • #198= IFCRECTANGLEPROFILEDEF(.AREA.,$,#197,5.25,0.5);

In this instance, the importing application could retain the height of the wall as a function of the difference between the 2nd and 1st floor elevations, which in this case equals 12ft (or meters, if that’s the unit in the IFC file)

A small step to parameterizing IFC?

2

A small step for mankind a giant leap for software.

The issue is the the SPF grammar (the rules for a valid .ifc file) is very elegant but minimal. You have (from the 2016) version for untyped_parameter (the attribute value we’re talking about here):

UNTYPED_PARAMETER  = "$" | INTEGER | REAL | STRING | RHS_OCCURENCE_NAME
                     | ENUMERATION | BINARY | LIST .

So nothing like an equation. So the spf grammar you can wrap it as a string (but than you loose any information on the schema, all datatypes are strings then, no more positive constraints, so you loose a lot of expressiveness in the schema).

So isn’t there something for that? Of course there is an ISO standard for everything. In this case for example 10303-50 Mathematical Constructs if I’m not mistaken, but there isn’t any connection between IFC and this ISO standard. And on a schema level it would mean that every number needs to be encoded as a select of (REAL, function_expression). In short, STEP is just not equipped to embed constraints on such a deep syntactic level.

I think for that reason the examples from @jonm makes sense: encoding the constraints (IfcMetric) in additional definitions outside of the normal attribute values. There are issues that come from that as well, it’s not straightforward to just refer to an arbitrary attribute value (there isn’t a select of everything in the schema; there isn’t a foolproof way to refer to elements in sets either).

In that sense I think your syntax makes quite a bit of sense actually. But you’ll have to find another way to encode it (as a string probably or some other meta-schema / structure) and store it somewhere else (property set, IfcMetric / separate file / linked data) and also supply a true numeric value for the extrusion depth as it is not optional.

1 Like
3

I don’t know that I agree with that particular example. I’d rather the parametrics be at a higher level rather than at the geometry level. The wall should be constrained to the levels, I think. Of course, geometry-level would also be OK, but maybe not as powerful.

4

What if was to be prefab and needs to be recycled? :slight_smile: