In the current online specification for IfcPile, IfcPile.ConstructionType is “informally” listed as deprecated, but IfcPileConstructionEnum itself is NOT indicated as deprecated.
Is this an error either way?
While the use of IfcRelAssociatesMaterial is documented as the “preferred” method, is IfcPileConstructionEnum still “allowed”? The documentation seems too wishy-washy.
From the US Bridge perspective, IfcPileConstructionEnum is still very useful, even alongside the IfcRelAssociatesMateral.
We need official clarification and subsequent correction of the documentation to move forward with our exchange standard efforts.
@artur_tomczak Any chance on that? or, at least, some sort of prioritization while communicating which is the priority place to address this, that, etc… depending on the request scope, etc. ?
Very interesting find @jwouellette. I question the wisdom in deprecating ConstructionType, at least for concrete piles. IfcMaterial will tell you if a pile is concrete (or some other material), but it doesn’t tell you if it is cast-in-place concrete, precast concrete, precast/pretensioned concrete. That seems to be the job of IfcPile.ConstructionType and the IfcPileConstructionEnum.
This is just one of many I keep finding when going through the Exchange Requirement and IDS development for our BIM for Bridges and Structures projects. So, so many simple issues that are unnecessary…
Thanks for reporting this. It seems one of the many not-very-consistent deprecation notes of IFC 4. Nothing was added/modified regarding these entities by IFC 4.3.
And I tend to agree with Rick. Method and material are different things. I would not follow the note and use IfcMaterial to specify the material and, if needed, a property to indicate the construction method. Make it easy for everybody and do not use material profile set
@Evandro I believe the clarification we want is whether IfcPile.ConstructionType and IfcPileConstructionEnum are truly deprecated or not… @Rick_Brice did NOT suggest using a new custom property to indicated construction method.
But you can connect the appropriate Forums (Discourse) to the corresponding GitHub repo… can you not? From my admin days, I recall that there is an official mechanism to do it, we just didn’t hook it up before control changed over.
I see. Yes, the attribute ConstructionType was deprecated by IFC 4. I think they simply forgot to add the deprecation note to the respective enumeration.
Just FYI, the IFC Validation Service already checks for these deprecations. And IfcPile.ConstructionType is covered by that check. And since IfcPileConstructionEnum can only be referenced by that attribute (as per schema) its use anywhere else would trigger a schema violation.
link particular GitHub issues and pull requests to Discourse topics. But this is manual, almost same as copy-pasting the link.
embed GitHub content inside forum discussions, similar copy-pasting .
notifications about new GitHub activity in specific categories - don’t see a need, users can set up notifications themselves
automatically create new topics or posts in Discourse when an issue, PR, or discussion is created.
But what for? I think it’s easier to use GitHub for proposing actual changes and posting issues (rather technical), and forum for broader discussions, and mainly for users (less technical).
PS @daviddelven, we are gradually improving our official website and try to add all the relevant links. There are direct links to github repositories and when applicable to forum threads. Does that answer your need? I don’t think a document or separate ‘site map’ page would help. Of course, to prevent the confusion we should only have one place, which would probably mean - limiting the use of the forum in favour of github. Or do you have any other idea?
Hi @artur_tomczak. I agree that GitHub and Forums might have different user targets. What you are doing adding direct links to Github to centralize where to point out it is necessary, for sure. But i.m.o. it is also necessary to communicate it deliberately. Just modifying links is not enough nowadays. It is a communication issue, rather than a technical one.
Yes, the audiences for GitHub and Discourse (Forums) may be different, but we could argue there is significant overlap. This is mainly due to how end user concerns (usage, implementation, deployment, etc.) affect or are affected by the technical standards and implementations. So, there are opportunities to directly connect some Forums Topics with some bSI GitHub repos.
GitHub is not appropriate for the least technical users. Discourse is better for general conversations and discussions about establishing consensus on how things should work from the industry POV. But those conversations matter and should impact the technical side, as well as getting insight as to how the technical work impacts end user implementation and deployment.
GitHub is fine for the more-to-most technical users, but discussions should be about technical implementation and not use case practices or needs. The idea of connecting the two is to enable both sides to participate in a more synchronized manner, rather than being completely separate.
The Forums (Discourse) has a broader scope of discussions, but sometimes a particular Topic needs better reference to the relevant GitHub repos and discussions.
I could not agree more with @jwouellette on all this👆🏻
If there is a need for further discussion, maybe we should open a new topic elsewhere, far from the IfcPileConstruction (although referencing it, as the triggering thread).
Indeed we’re polluting the original thread. Plus, we all agree. As @jwouellette explained “Discourse is better for general conversations and discussions”, while GitHub is a code repository to which people can contribute by proposing changes and identifying issues. And when the latter is done, there is always the possibility to link back to a Discourse thread. All this is already in place.
If there are still questions on why the two exists and how they complement each others, you all have my email. Let’s keep this thread clean please.
