StartDistAlong in IfcAlignmentHorizontal 4.3. rc2

in ifc4.3 rc 2 in IfcAlignmentHorizontal was present the StartDistAlong member( the value of the distance along at the start of the horizontal alignment).
But in the IfcAlignmentHorizontal of ifc4.3.0.2 version this member has disappeared.

Where can I set the start of the horizontal alignment in version 4.3.2.

Thanks in advance
Renzo Venut

In the official, one-and-only IFC 4.3 (aka, IFC, link here) the start of an horizontal alignment (IfcAlignmentHorizontal) is given by the start point of its first segment (IfcAlignmentHorizontalSegment.StartPoint).

See also IfcAlignmentHorizontalSegment - IFC4.3.2.0 Documentation

Hope this helps

Hi Evandro
thank you for your attention, IfcAlignmentHorizontalSegment.StartPoint of type IfcCartesianPoint is a point position, what we need is a distance, in previous 4.3. rc 2 this value was present in IfcAlignmentHorizontal.StartDistAlong of type IfcLengthMeasure, it’s a curvilinear abscissa, in the 4.3.2 has disappeared.

Renzo Venuti

I think this data (StartDistAlong) ended up in the property set Pset_Stationing.Station of the IfcReferent class.

I’m not if certain if setting the Start Distance for an Alignment has been finally standardised.
If it has been finalised, could someone post the final solution here.

For all our work a start chainage for an Alignment is critical.

Reading Lee’s comment I believe I gave a different interpretation to your question below.

Let me see if I got it now. By “start of the horizontal alignment” you’re not referring to the geometrical point, in the 3D space, where the alignment starts (which is obviously the cartesian point you mentioned).

You would like to know how to associate a stationing value (sometimes called mileage, kilo-point, pk, etc.) to the origin of the horizontal alignment curve. Did I get it right?

Example: km 12+900 or km 0+300. Is this what you’re after?

Where do I set this value?

For this you can:

  • Create a IfcReferent, of PredefinedType: STATION
  • Attach a Pset_Stationing to it, indicating the Station value
  • Provide further details on the referencing method or the formatting convention using respectively Pset_ReferentCommon and Pset_LinearReferencingMethod
  • Nest this referent into the related IfcAlignment, as the first of the list of referents, using IfcRelNests
  • Indicate that the referent is positioned according to such IfcAlignment, using IfcRelPositions

Hope this helps

I forgot to mention probably the most important part. On top of the above you can have the geometrical placement of such referent pointing to the correct BaseCurve and using LinearPlacement correctly. Ideally, the two parts (geometry and “semantic”) of the stationing shall make sense, aka be consistent - except tolerances and alignment “jumps”

Bottom line: it’s not the most straightforward part of the new IFC4.3. Surely we need more example files. So, if you decide to give this a try please get in touch

Thanks, we will implement this solution and then send you an ifc file

1 Like

Looking at the structure of IfcRelPositions members RelativePositioningElement and Related, deriving both IfcReferent and IfcAlignment from IfcProduct and IfcPositionElement, what is the relationship? RelativePositioningElement = IfcReferent and Releted = IfcAlignment ?

Spot on question.
If you look at the definition of IfcRelPositions it says:

“An IfcRelPositions relationship informs on the positioning dependency between a product and a positioning element.”

…but in this specific case, both IfcAlignment and IfcReferent are two types of positioning element.

Also, reading the description of the Product Relative Positioning template, this does not clearly state what to do in this case.

In conclusion, for this specific case, my opinion is that the IfcProduct subtype for such template is the IfcReferent, while the IfcPositioningElement subtype is the IfcAlignment. Meaning, the other way around then the one you suggested above. But that is just my interpretation for this specific case.

For sure documentation should be more clear on that.

I think you’re right