IfcCurveDim does not contain code for IfcSpiral

[aothms]

@SergejMuhic @PeterRdf

What would be the suitable definition? Is it Position.Dim or sth else?

[SergejMuhic]

Aw, good catch. This makes sense. Spirals are bound to planes but can be positioned in 3D of course. I agree.

[SergejMuhic]

Additional proposal after testing. Make IfcSpiral.Position mandatory. See linked 548 by @pjanck.

[peterrdf]

I am okay to make IfcSpiral.Position mandatory, still would also be okay with the implicit rule already available that in the context of an IfcCurveSegment the IfcSpiral.Position is mandatory while we keep IfcSpiral as it is.

[SergejMuhic]

Like this:

WHERE PositionOnSpiralExists: IF 'IFCSPIRAL' IN TYPEOF(ParentCurve) THEN EXISTS(ParentCurve\IfcSpiral.Position;

on IfcCurveSegment?

I must say, I would prefer making Position mandatory.

[aothms]

Like this:

WHERE PositionOnSpiralExists: IF 'IFCSPIRAL' IN TYPEOF(ParentCurve) THEN EXISTS(ParentCurve\IfcSpiral.Position;

Quick note that this is not allowed. Where clauses can only take expressions, not statements (such if_stmt). So we'd have to rephrase that to

NOT 'IFC4X3_SOMETHING.IFCSPIRAL' IN TYPEOF(SELF.ParentCurve) OR EXISTS(SELF.ParentCurve\IfcSpiral.Position);

(need to review parenthesis as well, express is a bit picky on them).

I'm not so sure abt the usage of SELF, we don't have it on all of our clauses, but the standard says:

Domain rules (WHERE clause)

...

Rules and restrictions:

...

b) The keyword self (see 14.5) shall appear at least once in each domain rule ...

---

So to summarize we have the options (I tried to order them based on decreasing "safeness"):

1. Return indeterminate in IfcCurveDim when IfcSpiral.Position is NIL
2. Return 2 (?) in IfcCurveDim when IfcSpiral.Position is NIL
3. Make IfcSpiral.Position non-optional in the context of IfcCurveSegment
4. Make IfcSpiral.Position non-optional

I'm fine with all four options, you are the experts here, we will be making some similar schema changes anyway (#576).

[pjanck]

My vote goes for

Make IfcSpiral.Position non-optional in the context of IfcCurveSegment

I believe your proposal is almost complete, only missing parenthesis (looking at example of CorrectTypeAssigned):

WHERE PositionOnSpiralExists:  (NOT ('_SCHEMAIDENTIFIER_.IFCSPIRAL' IN TYPEOF(SELF.ParentCurve))) OR EXISTS(SELF.ParentCurve\IfcSpiral.Position);

[SergejMuhic]

Quick note that this is not allowed. Where clauses can only take expressions, not statements (such if_stmt). So we'd have to rephrase that to

Yep, my bad. Was thinking in function terms first, then I added WHERE.

[aothms]

@TLiebich this would be a good time to make your preference if any explicit

@peterrdf you said:

would also be okay with the implicit rule already available that in the context of an IfcCurveSegment the IfcSpiral.Position

Does this mean you prefer option option 3? I didn't find that "implicit rule already available".

@SergejMuhic I count you under option 4?

[peterrdf]

I am in favor of option3, but of course also okay with option 4

[TLiebich]

+1 for option 3 (still explicit but avoiding a schema change)

[SergejMuhic]

@SergejMuhic I count you under option 4?

Definitely. If we are changing something like this, I would say make it consistent with the rest of the schema. Implementation will suffer one way or another as IfcSpiral was used in IfcCurveSegment 100% of the time in existing IFC4X3 files.

It was a nice idea with IfcSpiral being a bit different but it does not work as intended.

EDIT: With option 3 we are not fixing the problem. A sole IfcSpiral can still throw an exception with IfcCurveDim.

[BenzclyZhang]

Is there resolution for this issue? The Validatoin Service still generates issues regarding the IfcCurveDim function and IfcSpiral. I prefer Option 4, I guess schema change is not really a problem now?

[aothms]

EDIT: With option 3 we are not fixing the problem. A sole IfcSpiral can still throw an exception with IfcCurveDim.

We can also combine my options 2 and 3 from above. So:

1.    Return indeterminate in IfcCurveDim when IfcSpiral.Position is NIL
2. > Return 2 (?) in IfcCurveDim when IfcSpiral.Position is NIL
3. > Make IfcSpiral.Position non-optional in the context of IfcCurveSegment
4.    Make IfcSpiral.Position non-optional

It ultimately depends on the conditions on by which IfcCurveDim is evaluated though. Sure, an implementer could call IfcCurveDim(SomeSpiral) directly in his own code, so it's best if the semantics are complete, but in regular schema usage I don't see a case where IfcCurveDim is evaluated on an IfcSpiral without the context of an IfcCurveSegment, because it wouldn't be a top level item in a IfcShapeRepresentation.

At this stage I really prefer making as few attribute type changes as possible, because they will affect code generation and variable types in statically typed languages, therefore probably in implementers having to adapt their code.

[TLiebich]

what is the reason, that Position at IfcSpiral is optional? Other parameterized curves, like all conics have Position mandatory. When I look into the subtype IfcClothoid (and corresponding clothoid in STEP P42) it seems to me, that Position is essential - i.e. cannot be NIL. I also don't see any description to explain a default, in case of Position being NIL.

So I would also argue for option 4 (if I don't miss anything here). Contrary to my previous statement we have now a new situation where we accept minor schema changes for the ISO FDIS - so this one could be added.

[SergejMuhic]

what is the reason, that Position at IfcSpiral is optional? Other parameterized curves, like all conics have Position mandatory.

Exactly. It was a lapsus in the design. We should correct it. The only reason I can give is that I always thought of it as in the context of IfcCurveSegment. But there is also IfcTrimmedCurve and then there are functions relying on the attribute. So, let's not fool ourselves, there is only one alternative really.

but in regular schema usage I don't see a case where IfcCurveDim is evaluated on an IfcSpiral without the context of an IfcCurveSegment,

We could argue the same for IfcLine and it still has a mandatory Pnt attribute.

[aothms]

Ok option 4 is now by far the most favourite, it's also the easiest to apply so I'm happy :)