Geometry of geotechnical stratum

[Olivier-Berrier]

What is the recommended geometry fot IfcGeotechnicalStratum ?

I attach 2 screenshots : 1) the shape representation is a surface (IfcTriangulatedFaceSet) 2) the shape representation is a volume (IfcFacedtedBRep + IfcClosedShell).

I assume both are correct, but which one is better ?

[aothms]

I'm not a domain expert, but to get the discussion going I'd ask the following questions:

• Is it meaningful to perform boolean operations on this (for excavations perhaps) -> brep
• Is it meaningful to calculate volumes -> brep

But I also understand the appeal of just the surfaces as it is more efficient and might visualize a bit better (layering is more clear and no overlapping surfaces). Plus, the side faces needed to create a bounded volume, in reality do not exist.

Perhaps it's possible to come up with a harmonized representation of both, either as:

• IfcTriangulatedIrregularNetwork by supplying per-triangle flags we can tag the side faces, but still have a closed volume that can participate in (volumetric) boolean ops. (IfcTriangulatedIrregularNetwork is a subtype of IfcTriangulatedFaceSet).

Edit: I don't understand some of the restrictive usage constraints (one unique Z component, not closed) for TINs in IFC though, that might be a problem.

• A CompositeSolid. As such you would explicitly model the connection between the shells by having each intermediate layer consist of the same faces, but oriented in opposing direction. This doesn't really exist in IFC, we have IfcOrientedEdge, but not IfcOrientedFace (our step friends are lucky https://www.steptools.com/stds/stp_aim/html/t_oriented_face.html). This would require strata to share the same placement, because otherwise you can't share geometric items.

My vote would go for 1. Which corresponds to your option 1, but using the subtype to be able to explicitly flag the side areas.

[JanErikHoel]

I've no strong opinions about this, but this is how we define terrain in the exported IFC-files from Quadri/Novapoint today:

23 = IFCGEOTECHNICALSTRATUM('0yKw1rX3D5KxeHaDKsXVQE', #6, 'Ground Surface 1', $, $, #22, #27, $, .SOLID.);

24 = IFCTRIANGULATEDFACESET(#25, $, $, ((1, 2, 3), (4, 5, 6), (7, 6, 8), (6, 7, 9), (10, 11, 12), (13, 14, 15), (14, 13, 16), (17, 16,

25 = IFCCARTESIANPOINTLIST3D(((9

26 = IFCSHAPEREPRESENTATION(#15, 'Surface', 'SurfaceModel', (#24));

27 = IFCPRODUCTDEFINITIONSHAPE($, $, (#26));

28 = IFCPRESENTATIONLAYERASSIGNMENT('Ground Surface 1', $, (#26), $);

29 = IFCSITE('13V$k3uofDF8dVyRCokGkn', #6, 'Default Site', 'Description of Site', $, $, $, $, .ELEMENT., (10, 28, 53), (59, 54, 35), 20.9999215895414, $, $);

30 = IFCGEOMODEL('3Bld0VjuDEnA6RcrzdD3Z7', #6, 'Default Geomodel Name', 'Description of GeoModel', $, $, $, $);

31 = IFCRELAGGREGATES('0ZFuUSBYbADg2aHkS9_0PN', #6, $, $, #30, (#23));

32 = IFCRELAGGREGATES('2rygnXEObDoA70EBtjUozd', #6, $, $, #19, (#29));

33 = IFCRELCONTAINEDINSPATIALSTRUCTURE('0rmOCinEr2AB$OAFCuLbEx', #6, $, $, (#30), #19);

[JanErikHoel]

I would recommend to talk to the IFC4.4 schema extension team to discuss this, like Sergej or Lars Wikstrøm e.g.. The topic of better defining terrain, geology and geotechnics are core parts of the IFC4.4 schema extension work.

[jwouellette]

Note that IfcFacetedBrep is NOT within the current "DRAFT" scope of the AbRV. IfcTessellatedItem is however.

As discussed in the bSI IFC4.x IF, I see the following options for site/terrain representation:

Each case has different requirements, but both should be kosher under the AbRV. Is it possible to have software UIs accommodate any/all of these, according to the user requirements for a project or project delivery standard?