Geotech borehole

[JoostGevaert]

Geotech borehole examples and a way to attach CRS's to IFC 5 objects.

This is the PR for adding geotechnical boreholes and Coordinate Reference Systems to IFC 5. Examples for geological models have also been prepared, but some issues were encountered when trying to submit those to git, as explained below.

Geology Model examples

I've also created Geology Model examples, but the meshes for these geology models are too large: > greater than 50 MB and some even larger than 100 MB. This is because those meshes are generated by Leapfrog Works, which makes very inefficient meshes.

What shall we do with those examples?

Besides, the boreholes are related to the geological model. The idea was to indicate this relationship in a similar way to how the space boundaries a are related to the spaces in the HelloWall example. However, in the case of boreholes and geological layers, there are multiple boreholes that are related to a single geological layer, because multiple boreholes together dictate the shape of a geological layer. Therefore I thought a structure like this could be an option:

"attributes": {
   "ifc5:groundInvestigation": {
    "relatedElement": [
      {"ref": ... },
      {"ref": ... },
      {"ref": ... }
      ]
    }
  }

What do you think?

Bonus question: Is it possible to create meshes with more than 3 vertices per polygon?

In USD meshes have a
"faceVertexCounts": face_vertex_counts
This is not possible in the current viewer, right?
This will be valid IFC 5?

[berlotti]

really nice!

[aothms]

Awesome!

which makes very inefficient meshes.

Let's find a way to reduce that. Did you try decimating them in Blender and export to USD? Feel free to send them my way if you get stuck

Therefore I thought a structure like this could be an option... [json snippet]

This is a fairly fundamental question. I think for now this suffices, but USD has a lot more tools to influence how composition operates on lists. I think later we might decide that it's not 1 component with list 3, but maybe 3 components with each a list append operation. So that you can much more easily compartmentalize and collaboratively author data - other layers could keep appending.

In USD meshes have a "faceVertexCounts": face_vertex_counts This is not possible in the current viewer, right? This will be valid IFC 5?

Correct. The current viewer cannot triangulate. IFC4 currently has a polygonal faceset which is almost the equivalent of faceVertexCounts, but it can also have inner bounds of faces, so is even more involved. My vote would be for not allowing polygonal faces, because: (a) if you don't have inner bounds you still don't get that far in an AEC context because of openings (b) it opens up a modestly sized can of worms on face planarity (c) it increases implementation complexity of the reader, if you can author data you can probably triangulate because anyway you render it to the user, but if you read data, like our minimal example viewer, triangulation is (well-understood, but) somewhat of a pain.

[aothms]

name is a bit of a misnomer. It looks like we're converging towards that this needs to be a GUID when it's located on a top level.

If we want, we can still create meaningful resource names for universally understood concepts, like:

>>> 'N' + uuid.uuid5(uuid.NAMESPACE_OID, 'urn:ogc:def:crs::EPS::2193').hex
'Na1e75073fa385923a7bc89f7c6ab1338'

I don't know if that's a good or a bad idea.

[atomczak]

is it mainly to avoid duplicates or else? I find freetext/urn identifiers more attractive than obfuscate GUIDs. But end-user shouldn't really see that anyway.

[aothms]

Under the assumption of distributed authoring, using globally unique ids is the easiest way of preventing unwanted collisions. Leaving this up to the user, it can be a guid or a human readable name is not what I would recommend. I would enforce a consistent structure.

My question is more along the lines of: what if, even when authoring in a distributed fashion, you know certain things are identical by definition (like, a CRS identified by some epsg code) is there then a value in purposefully not created unique ids, but kind of like universe-wide singletons following a guid structure.

But I think top-level guids is a given, whether there could be special guids is up for discussion, but there is little upside to it.

[JoostGevaert]

To me the name concept and GUID's are not quite clear indeed. For example, why don't the materials in the hello-wall.ifcx example get a GUID?

I indeed used a non-GUID name for the CRS object, because I think CRS objects - when they describe a CRS that is registered at an authority like the EPSG - should always be the same. The

Nonetheless, I'm open to generating a GUID of course. I like the idea of generating a GUID for a registered CRS based on namespace + Uniform Resource Name.

[aothms]

why don't the materials in the hello-wall.ifcx example get a GUID?

Valid question, but the materials are just plain USD materials ported to JSON, we still need to figure out how we want that to work in IFC5.

[aothms]

Suggested change

	"ISO": "ISO 19162:2019",
	"ISO": "ISO 19162:2019",
	"name": "urn:ogc:def:crs:EPSG::2193",

name would then be a property in the attributes, not sure if it needs the full urn

[aothms]

So now we associate the CRS with individual objects as meta-data.

But I think we can make it a little bit more challenging for ourselves.

Let's say we want to be able to bring two datasets together that use different CRS'es. Geographic ones is probably out of the question because there is no way we can implement that as an affine transformation, so let's say two projected crs'es.

I think I would propose the following as an investigation:

• We use Site as let's say the spatial root node
• Site inherits from our CRS-entity that is defined in a separate layer
• The CRS-entity not only has the WKT literal, but also an xform matrix that translates the coordinates from the CRS into 'something universal'.
  • Something universal could be some cartesian space that works for both the CRS'es in our particular project
  • Could also be ECEF? That's what Cesium uses. Now that they got acquired maybe there are some bSI members that extra care about this... But imagine how cool this is, based on WKT, generate the local-to-ECEF transform and you have the data on the globe. The amount of effort that is still required these days to get that reliably to work is embarrassing.

[JoostGevaert]

Hi,

Thanks for this awesome discussion!

@aothms, I've sent you a message on WhatsApp to regarding the geology model meshes.

[atomczak]

Nice example! Some minor comments that could be resolved later on. I suggest to keep the Speckle conversion script outside this repo.

[atomczak]

Do we have to add a new type "crs"? Why not use existing types like "UsdGeom:Xform"? Similarly, we don't define "type": "IfcWall".

[atomczak]

I like the simplicity of this UOM solution, but it's not clear what it applies to: "offset_x-z"? what about "rotation"? I think we will discuss it next week at GAoI, but we might need to complicate attribute values:

"offset_z": {"value": 0, "unit": "m"},
"rotation": {"value": 0, "unit": "rad"}

this would also allow adding more meta-data, like URIs and so on if needed.

[atomczak]

if those are just properties like for any other class, then probably "WKT-CRS" should be sth like: "ogc:1.2.4:wkt-crs:properties"

[atomczak]

(this comment is only valid if "crs" is not treated differently than other prims like IfcWall or IfcProject)

As I understand this, the ISO reference should be a metadata on the whole 'WKT-CRS' attribute, but right now, it's a flat list of independent attributes: 'ISO', 'wkt', 'authority_id' etc. In old IFC we would call those SingleValueProperties. I think better suited here would be some sort of key-value pair:

"attributes": {
    "namespace:ver:WKT-CRS": {
        "wkt-crs": {
             "wkt": "PROJCRS...",
             "ISO": "ISO 19162:2019",
             "name": "NZGD2000 / New ...",
             "authority_id": "EPSG:2193"
             }
        }
    }

[aothms]

Also, we should make an effort (at some point) to update the schema for any additions https://github.com/buildingSMART/IFC5-development/blob/main/schema/main.tsp