BC002-STN02-ACCA

[michelangelo-acca]

This pull request contains the first version of the STN02 IFC file from ACCA.

We know that some details are missing, which are:

• Referents for the Horizontal Segments
• Referents for the Vertical Segments

But we would like to have an early feedback, so we require a review, in particular regarding:

• Is the station "jump" concept correctly implemented?

If yes, we can proceed to update the model with the missing Referents and update it to IFC4X3_ADD2 if required.

P.S.: we have been told to ignore the bSI Validation Service error for now, as it seems to be their problem (?).

[evandroAlfieri]

@michelangelo-acca just on the Validation Service part: I think the error you're getting is given by a problem with the previous version of the IFC schema. If you change your file to IFC4X3_ADD2 you'll see it's already valid.

[apinzenoehler]

@michelangelo-acca just on the Validation Service part: I think the error you're getting is given by a problem with the previous version of the IFC schema. If you change your file to IFC4X3_ADD2 you'll see it's already valid.

Hmmm ....

I tested it as proposed (replacing IFC4X3_ADD1 with IFC4X3_ADD2 ). Surprisingly the bSI validation service did not show any schema errors.

According to my understanding of the differences between IFC4X3_ADD1 and IFC4X3_ADD2 I would expect schema errors.

Entity definitions like

1488 = IFCCURVESEGMENT(.CONTSAMEGRADIENTSAMECURVATURE., #1491, IFCNONNEGATIVELENGTHMEASURE(0.), IFCNONNEGATIVELENGTHMEASURE(387.723276296965), #1492);

should look differently in IFC4X3_ADD2

1488 = IFCCURVESEGMENT(.CONTSAMEGRADIENTSAMECURVATURE., #1491, IFCLENGTHMEASURE(0.), IFCLENGTHMEASURE(387.723276296965), #1492);

Consequently a file with an IFC4X3_ADD2 schema tag and with IfcNonNegativeLengthMeasure in IfcCurveMeasureSelect types should raise an error. Maybe you can double check this behavior.

OLD: TYPE IfcCurveMeasureSelect = SELECT (IfcNonNegativeLengthMeasure ,IfcParameterValue); END_TYPE;

NEW: TYPE IfcCurveMeasureSelect = SELECT (IfcLengthMeasure ,IfcParameterValue); END_TYPE;

[evandroAlfieri]

@apinzenoehler you are right. I focused on the CurveDim where rule and not seen that indeed there's a more evident schema error. We're working to fix the VS as we speak. Thanks for the heads up

[aothms]

There was indeed an issue with validation on the latest ADD2 schema. This is resolved now in the v0.5.6 deployment of the server. Sorry for the confusion caused.

[michelangelo-acca]

Hi @apinzenoehler, thanks for the review. AFAIK there will be dedicated sessions on the stationing topic in the IF4.x meetings, so we will wait for those aswell to update the IFC model further!

[michelangelo-acca]

Not sure where to ask, so I will try here:

in the model, the Signals are Linearly Placed along the Alignment. They also have a "semantic" IfcRelPositions association with such Alignment. Same for IfcReferent(s) used for Stationing.

Checkers are happy, but is this how it is meant to be, or should the Signals be Linearly Placed along the Alignment but have a IfcRelPosition relationship with an IfcReferent which in turn is IfcRelPositioned against the Alignment, or something similar?

Not sure if the question is clear...basically how do we know the stationing of the Signal? Do we have to explicitly put it in the file, or find it based on the available Referents used for Stationing?

[evandroAlfieri]

positioning, especially with regards to alignment, is one of the less defined and documented part of the new IFC 4.3. May be easy to solve, but it's just not documented. Open questions, including the one you asked above, were raised in one of the last session of the IFC Implementers Forum, linked here. Probably at that time, nobody was implementing this and the feedback was mainly silence.

Let's have a call dedicated to this topic with the other vendors dealing with it. I'll ask in the Slack channel. Thanks for raising again the attention on this topic

[clfey]

@evandroAlfieri @michelangelo-acca @apinzenoehler @eihov

Could we schedule an ad-hoc Teams meeting next week on this topic? We would like to align, ACCAss, Géorail's and our understanding of these concepts. I must involve Eirik Hovind on our side.

How about Tuesday 11 June somewhere between 1030 and 1300? Evandro calls for meeting.

[evandroAlfieri]

An ad-hoc, online call is definitely needed. But since this topic was already discussed, this time I'd like to call for a meeting only when we have some example files to talk about. Can be small files (even better) and don't have to be 100% correct, that's what the meeting will be about. So, this time: no files, no meeting.

How many examples can we count on? @michelangelo-acca I assume you have one. @eihov ? Maybe also @marcinpszczolka @jmirtsch ?

[michelangelo-acca]

An ad-hoc, online call is definitely needed. But since this topic was already discussed, this time I'd like to call for a meeting only when we have some example files to talk about. Can be small files (even better) and don't have to be 100% correct, that's what the meeting will be about. So, this time: no files, no meeting.

How many examples can we count on? @michelangelo-acca I assume you have one. @eihov ? Maybe also @marcinpszczolka @jmirtsch ?

We have the example in this pull request which we can update to the latest schema and rules (it seems that now the bSI validator says that IfcReferent(s) should not be contained in spatial structures)...I am personally available for a call most of the days...