LIP001 - Assert that IfcLinearPlacement.PlacementRelTo is the same IfcLocalPlacement as used to place the IfcLinearPositioningElement (same for grid placement)

[RickBrice]

If I understand CT 4.1.7.4.2 Product Linear Placement correctly, IfcLinearPlacement.PlacementRelTo is the same IfcLocalPlacement as used to place the IfcLinearPositioningElement.

At the end of the attached file, three linear placements are defined.
#279 IfcLinearPlacement.PlacementRelTo = #22 which is the same placement for #248 IfcAlignment.ObjectPlacement - This placement should be correct

#287 IfcLinearPlacement.PlacementRelTo is a unique IfcLocalPlacement with the same values as #22 but is a different placement - This seems to violate the CT but passes the validation service checks.

#295 IfcLinearPlacement.PlacementRelTo is also a unique IfcLocalPlacement but with different values than #22 - This seems to violate the CT as well but passes the validation service checks.

FHWA_Bridge_Geometry_Alignment_Example.ifc.txt

[aothms]

Should we update the concept graph so that the IfcLocalPlacement also has an incoming edge from the IfcLinearPositioningElement? Previously this was not possible in mvdXML, but nowadays we can render this.

Concept templates are currently not used though in the validation service.

The main reason for that is a lack of understanding what concept templates really mean formally. So the process we have been following now is to recode these kind of templates into a more precise definition of Gherkin + Python.

So maybe this is a good moment to think about what such a precise rule would look like. The same kind of rule should also be written for IfcGridPlacement, which is conceptually similar, placing relative to the geometry of another product.

Another question is whether the Alignment itself needs to be present or whether it is also ok to position just along the alignment curve without it being referenced in an alignment product. For Grid this is slightly different because we have IfcGridAxis that sit in between the placement, representation item and containing product.

[RickBrice]

Should we update the concept graph so that the IfcLocalPlacement also has an incoming edge from the IfcLinearPositioningElement?

Isn't there one already?

Concept templates are currently not used though in the validation service

Maybe it's my inexperience, but I see the validation service as validating IFC files against the schema. The Concept Templates are part of the schema so they matter. I don't really care how the requirements of the schema are described - by EXPRESS rule, by WHERE rule, by graphical depiction, by formal or informal agreements - at the end of the day a "valid" file conforms to all the requirements. That's just my uneducated opinion.

Another question is whether the Alignment itself needs to be present or whether it is also ok to position just along the alignment curve without it being referenced in an alignment product.

I think there are use cases for positioning along an alignment curve without it being referenced by an alignment product. One that comes to mind is placing a linear element such as a traffic railing on a bridge deck. The geometry can be placed with an IfcOffsetCurveByDistances which is dependent on an alignment curve. The offset curve does not need to be referenced in an alignment product.

[aothms]

Isn't there one already?

Sorry. I was looking for this shape and somehow just didn't see it's literally the same...

The Concept Templates are part of the schema so they matter

Yes. We use the word specification for this, and schema solely for the EXPRESS constructs, but you're right the effect is the same.

What makes this hard to operate on is that it doesn't distinguish between optional and mandatory nodes, or offer cardinality restrictions in general. It also doesn't distinguish between selection (when is the template considered applicable) and requirements. And some templates are more advisory where others are normative, but this distinction is not communicated.

You could read this as:

• Every product should have an IfcLinearPlacement
• Every linear positioning element should have an IfcLabel
• ...

The concept templates enumerate possibilities, not requirements.

It is a line of thinking worth continuing. Instead of saying concept templates impose requirements on the model, we could argue, for every instance in the model we need to be able to map it to a concept template, but the problem with that is that the templates are not exhaustive (custom property sets would become invalid?) and it's also not a nice error reporting experience to the user. "The following instance was not mapped to a template". Instead of "For instance X, linear placement is not valid because of Y".

So this in short is the background to where we're at with the validation service. I do hope that the things converge better. I'm already making plans to embed constraints from gherkin into the rendering of the templates. I'm also interested in exploring ways to distinguish between applicability and requirement nodes in the template, but both of these are a considerable effort and there is still some trauma in the bSI community regarding inventing our own wheels for things like MVD, so that is also why for the VS we stick to more imperative solutions to get results quickly and then refine, as opposed to spending 2 years in isolation for a new more expressive, formal and operable concept graph modelling standard.

[RickBrice]

Thanks for the insight. The VS must be a daunting project.

The concept templates enumerate possibilities, not requirements

I'm coming to learn this through experience. Though in my mind, some CTs seem to express requirements. How is someone new to IFC supposed to know the difference?

I try to use the CT as a general guide and then find details and specifics in the element documentation.

My intention is only to be helpful, even if I'm sometimes incorrect.

[aothms]

I'm coming to learn this through experience. Though in my mind, some CTs seem to express requirements. How is someone new to IFC supposed to know the difference?

Very valid question, your guess is as good as mine. It's a slow process. bSI is moving from closed schema development, closed certification to a more open approach. So previously maybe it didn't matter so much if things weren't understandable, because the group that really interacted with the semantics of the schema was limited. Now bSI follows a more open process, which is I guess the easy part, open up some github repositories et al, but the hard part is externalizing all the internal implicit knowledge that was in this small group of people into a comprehensive and properly layered documentation.

[RickBrice]

Nothing complex is ever easy in the beginning. IFC is no exception. Those that are knowledgeable have been very generous with their time and willingness to teach a novice like me. Hopefully new comers, with a fresh look at the specifications, will actively contribute and participate in continuous improvement.

Close out this issue if you think there isn't any action to be taken.

[aothms]

I think the original issue is definitely valid and actionable. I've tagged and moved it to the rule repo so that it can be picked up.

[civilx64]

@evandroAlfieri I propose we rename this to LIP001 since it corresponds to the Functional Part for Linear Placement.

[evandroAlfieri]

Agree @civilx64
And feel free to propose a more concise title ;) You can integrate the current one in the description

[aothms]

It's the same rule for LinearPlacement as well as GridPlacement. I agree that from a vendor / end-user perspective these should be separately positioned under GDP and LIP (I would probably name them GPL and LPL so that's a bit more clear that they are both PLacement related - but forgive me my obsessive side tracks).

This basically means that same thing we observed in "gcert". We end up copy pasting a lot, but that's fine. With the feature file / implementation divide and "plain-text-first" nature we kind of allow our selves to copy paste feature files as it's a bit like a configuration / orchestration file.

[evandroAlfieri]

Good that we can assign multiple tags. So,

• let's use the generic one for the rule's code (i.e, OJP for object placement)
• then add LIP and GDP in the feature file, other than repeating OJP

@aothms I feel you on GPL and LPL, it was my first iteration too. Then, got stuck on the third subpart, Local Placement, being another LPL
Any other idea?

[aothms]

Good that we can assign multiple tags. So,

Not sure we should do this. I wasn't very clear. But I think it's better to have 1-many correspondence between rules and fparts. Also, the rule is a bit different in the selection, which is necessary for meaningfully process the passed part.

Given an IfcGridPlacement
Then magic from scott

Given an IfcLinearPlacement
Then magic from scott

Local Placement, being another LPL

Any other idea?

No 😢

[evandroAlfieri]

Two rules then, LIP001 and GDP001. I'll make the change in our backlog