Numeric precision

[atomczak]

I see the current examples have varying numeric precision:

• six:
  https://github.com/buildingSMART/IFC5-development/blob/828ee54fcfa56db3c2ca9c55d1e505f5532e3dcd/examples/Hello%20Wall/hello-wall.ifcx#L1457C15-L1457C23
• seven:
  https://github.com/buildingSMART/IFC5-development/blob/828ee54fcfa56db3c2ca9c55d1e505f5532e3dcd/examples/Hello%20Wall/hello-wall.ifcx#L1185C12-L1185C24
• or even scientific notation:
  

  IFC5-development/examples/Hello Wall/hello-wall.ifcx

  Line 1458 in 828ee54

  -2.3841858e-08,

• In some examples, I also see 12-digit precision (that's 1/50th of a hydrogen atom), significantly increasing the file size

It would be good to establish a general number precision for IFCX. To start with, how about 6 digits after the comma? For length, that's 1 millionth of a meter - micrometre, which is a 1/50th of a human hair diameter. More than needed for AEC purposes, but enough to not have issues with rounded object geometry or conversion loss. Because we agreed to use the metric system for length (and SI for most of the quantity kinds), even if the project is in metres, the precision would remain.

Less than the agreed precision should also be allowed, for example, full numbers or single digits:

IFC5-development/examples/Hello Wall/hello-wall.ifcx

Line 1056 in 828ee54

0.1,

Alternatively, we could establish separate rounding per quantity kinds, for example, four digits for length (0.0001 m - thickness of a coarse hair), but seven digits for angles (for example, geographic latitude).

TODO:

• add the agreed solution to the documentation

[aothms]

Alternatively, we could establish separate rounding per quantity kinds, for example, four digits for length

This has been discussed as part of the IDS project. One issue is that with SI units for volume or area without prefix this does not work in all cases, such as square meters for cable cross section e.g 0.000001 $m^2$ vs square meters for land area e.g 10000000.000000 $m^2$. So there we have opted for absolute + relative precision.

But I think we have a great starting point with our schema-based property definitions to make this a little bit richer. I've been meaning to come up with a proposal and implementation for this, but how about something like this.

| prop.ifcx |

"bsi::ifc::prop::CableCrossSectionArea": {
  "value": {
    "dataType": "Real",
    "quantityKind": "Area"
  }
}

| model.ifcx |

@import prop.ifcx

schemas: {
  "bsi::ifc::prop::CableCrossSectionArea": {
    "value": {
      "unit": {
        "name": "sqmm",
        "si_equivalent": 1e-06,
        "tolerance": ...
      }
    }
  }
},
data: [ ... ]

So, schema specifies quantityKind, data layers can further specify units (respecting quantityKind). Unit is just a string with an SI-equivalent so complexity is bounded by one scalar multiplication to support units.

Why I like this:

• Units fully optional on write: you could still use as is, don't specify a unit, model uses SI unit for quantityKind in schema
• Implementation complexity is minimal, you have the SI equivalent (not sure if we need an enum for names si_equivalent is all that matters), we could also add symbols or whatever so that presentation in viewer is easy
• Retains full freedom like we have now in IFC4 for measure-less units, e.g "hamburgers_per_inch" (courtesy of @tomvandig I think), because we have nothing now for Counts and Ratios.
• Retains flexibility in how to handle this in implementation, you can pre-apply unit conversion pre-composition (viewer only renders SI) or you can "box" values as measure-with-unit-pairs and retain those during composition (viewer uses locally defined unit which can be different based on originating layer).
• Efficient, uses the existing schema-based definitions so no linear increase with number of prop instances.