search

buildingSMART / NextGen-IFC

61 stars 4 forks source link

Precison definition should be improved #60

Open I-Sokolov opened 4 years ago

I-Sokolov commented 4 years ago

We need more accurate definition for precision. Precision for directions/points and properties are different things. I would suggest: 1) include precision into each unit definition reather than project context 2) always use relative precision. Absolute looks easier and everybody starts with this... but you can not measure building height and bolt diameter with same precision, absolute tolerance for directions has no sense

bekraft commented 4 years ago

Precision in IFC is really a good point of enhancement. But it doesn‘t depend on the unit type. It more a problem of the topological type (i.e. IfcLengthMeasure). Precision should be an absolute value (relative to what?).

An open question for me is how to handle precision for non-geometrical entities i.e. user defined properties wrapping length values.

I-Sokolov commented 4 years ago

To be exact. I uderstand relative/absolute precision as upper bound for relative/absolure error. If you specify the precision value in IFC file you guaranty that error is not exceed the value.

Definition for erros are https://mathworld.wolfram.com/RelativeError.html https://mathworld.wolfram.com/AbsoluteError.html

Floating point arithmetic (as well of nature of physical measurments) force us to use relative precision. Absolute precision looks easier to use but lead to confusions.

bekraft commented 4 years ago

Precision and error are definitions from two different worlds. Error is a term in statistics. The original definition of precision in the IFC is meant as epsilon value or tolerance value to compensate for numerical accuracy in different geometrical modelling environments. The IFC states that

It is a double value (REAL), typically in 1E-5 to 1E-8 range, that indicates the tolerance under which two given points are still assumed to be identical.

See IfcGeometricRepresentationContext

I still don‘t have a clue, how a geometry kernel should deal with relative error while assembling the given geometry model.

The meaning shouldn‘t be changed since the problem is still the same. But precision should be stated with more distinction to the embedded kind of geometry. Currently it only deals with point-to-point tolerances. It also should give hints about edge-edge and face-face tolerances. Most environments have multiple tolerances.

I also totally agree with you, that as-built models should state an relative and/or absolute error (since they are observations of real systems). But that’s another story...

NickNisbet commented 4 years ago

Ifc4x3 has a proposed pset_uncertainty (accuracy) to allow any existing entities to be labelled with descriptive and linear properties for shape/position uncertainty.

This arose from considerations of geotechnical modelling but is equally applicable to survey and as-built entities.

Consideration of Container crane tracks Has led us to also propose pset_tolerance for the specification of future products.

Between these two, the information is there for sharing and bim applications can do the maths to relate them together.

Sent whilst away from my desk.

Regards,

Nick.

Nicholas Nisbet FRSA MA(Cantab) DipArch(UNL)
Fellow: Royal Society of Arts Fellow: buildingSMART International & UKI Chapter Director: AEC3 UK Ltd Web: http://www.aec3.com E-mail: nn@aec3.com Direct: +44 (0) 1494 714 933
Mobile: +44 (0) 781 616 8554
Skype: nicholasnisbet Registered Address: 46 St Margaret's Grove, Great Kingshill, High Wycombe, Bucks, HP15 6HP, UK

Vice-Chair: buildingSMART UK Chapter Convenor: buildingSMART Regulatory Room

** Confidentiality Notice **. This e-mail and any file(s) transmitted with it, is intended for the exclusive use by the person(s) mentioned above as recipient(s). This e-mail may contain confidential information and/or information protected by intellectual property rights or other rights. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and delete the original and any copies of this e-mail and any printouts immediately from your system and destroy all copies of it.

On 10 Jul 2020, at 22:27, Bernold Kraft notifications@github.com wrote:

 Precision and error are definitions from two different worlds. Error is a term in statistics. The original definition of precision in the IFC is meant as epsilon value or tolerance value to compensate for numerical accuracy in different geometrical modelling environments. The IFC states that

It is a double value (REAL), typically in 1E-5 to 1E-8 range, that indicates the tolerance under which two given points are still assumed to be identical.

See IfcGeometricRepresentationContext

I still don‘t have a clue, how a geometry kernel should deal with relative error while assembling the given geometry model.

The meaning shouldn‘t be changed since the problem is still the same. But precision should be stated with more distinction to the embedded kind of geometry. Currently it only deals with point-to-point tolerances. It also should give hints about edge-edge and face-face tolerances. Most environments have multiple tolerances.

I also totally agree with you, that as-built models should state an relative and/or absolute error (since they are observations of real systems). But that’s another story...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

NickNisbet commented 4 years ago

Bear in mind that any numeric property including lengths can be defined as IfcPropertyBoundedValue which has

UpperBoundValue and LowerBoundValue and SetPointValue .

Nick Nisbet

I-Sokolov commented 3 years ago

Nick, not for IfcCartesianPoint

Bekraft,

the tolerance under which two given points.

This is not exact definition. It can be