Hello everyone,
by default, all data defined in the Connector of a selected element (e.g. a wall) is transferred.
This is not always useful or wanted.
Not all data of a component should be transferred e.g.:
So how can data be excluded from export depending on the component?
Best regards
Archi
Hi @rolfarchi! Interesting request you’ve got for us - we always assumed the more data, the better 
I understand this is possibly an important feature that could be added - you currently can’t exclude parameters from being exported out.
Both @AlanRynne and myself (probably the whole team too!) are very curious on the business secrets part - we haven’t encountered this usecase yet, so it would help a lot if you can give us more insights. We’ve been spending our past years coding mostly, so we might be out of touch with industry practices…
Once we know more/understand the problem better, we can see how we go about implementing it (extra conversion settings?).
Hi Dimitrie,
it is basically about the interesting topic Level Of Information Need (LOIN) e.g. according to standard DIN EN 17412-1.
The principle:
In a very early planning phase, especially geometric and structural (level, room …) information is required.
In middle planning phases the geometry (if necessary with higher detailing) and some (finally defined) attributes.
In a late planning phase the geometry and possibly a high number of attributes.
Each attribute increases the amount of data to be exchanged. Attributes that are not required (which are attached en masse to the components by CAD systems) slow down the data exchange.
The information content of a component is actually also dependent on the requirements of the recipient:
There is already an extensive standardization on the subject of LOIN, which I think would also be a good reference for Speckle.
Maybe a small community survey can make the need visible?
Best regards
Archi
Thanks @rolfarchi it is always helpful to hear a broader context for a request.
TLDR; This isn’t currently possible or strongly requested for active collaboration that most are using Speckle for right now But for formal data exchange, it is something we will think harder about.
Your question has sparked lively discussion concerning LOIN and deliverables vs data in flux. The standards focus on the perspective or milestones (What, by whom, and when). Confidently, the data properties of the Speckle model are not a limiting factor in the technical speed of exchange but
slows down the exchange
can speak validly to the effort of recipients to parse the information provided.
Other discussions raised recently in the Speckle Community relate to the ability to filter, on Receipt, already published data on an element basis. Filtering elements on Publish can be managed with focussed commits to branches/streams.
If I catch your intent rightly, your concern is instead about properties and not elements but the ability to filter on publishing rather than receiving.
If I could push you to elaborate further on some specifics with me, are you focusing on day-to-day data sharing or using Speckle to encapsulate a data-exchange deliverable? Your original inquiry was about data security or parameters. I’d be keen to hear what your existing workflows are to counter that when working within multiplayer projects. (MVDs aside, it isn’t quickly done with file exchange).
Further thoughts: Speckle platform APIs already support this; in theory, You could host code that processes each commit pushed to a stream, “cleans” it in various forms, and post custom commits to separate branches used by the MEP, Structural Engineer, or Client. However, this requires some heavy lifting. Bring your own code, as it were.
Hi @jonathon,
first a question for understanding:
Speckle is a platform for developers that only provides a limited selection of tools/possibilities for users, so it is an “SAP” for the construction industry, so to speak?
I come from the IFC faction and see Speckle as the fast-growing alternative to the IFC standard.
I’m sure almost the entire AEC industry is hoping for this: "So, what can you do with IFC that you can’t do with Speckle? In the long term, Speckle’s aim is to change the industry in such a manner that the answer would be “nothing”.
It’s about the daily exchange of data: architect - MEP engineer - statistician - building physicist …
Even if Speckle is not the limiting speed factor from a purely technical point of view: in my opinion, data that is not required is useless data.
The point is to filter properties of elements before publishing, rather than after receiving. Elements could easily be filtered by the respective CAD software before sending.
In a project, multiplayers of one company (e.g. different ARUP teams) can certainly exchange all data (properties) without hesitation.
In the case of multiplayers from different companies, properties can allow conclusions to be drawn about the technology used.
In the OpenBIM process, too, it is generally not desirable to disclose one’s own technology (competitive advantage …). Therefore, no company will actually publish its native, unprocessed CAD models without a compelling reason (contractual obligation …), but rather massively “clean up” these models before publishing them.
Best regards
Archi
Understood. We hear you.
Currently, there is no equivalent to the ability to define an MVD for IFC with current Speckle Connectors.
It is possible to in-flight process a commit to reproduce it. At this point, this is a Bring-Your-Own-Code answer. Indeed, food for thought; is something I will try to develop as a proof-of-concept. If you’d be open to offering feedback.
If you can give insight into how you are managing this filtering other than by crafting your IFC exports from each software for each exchange with each collaborator, that would also help.
It seems I was out of date in my terminology. Bespoke MVDs for IFC are no longer part of the recommendation for defining exchange specifications.
As I look into this more, I’m not sure it really covers the scope of your original question. IDS is to define what information exchange should have (and subsequently validate it) and not how to restrict to include only what it states.
I believe this is still the closest thing I can find which is parallel to what you wanted, but I am open to suggestions for how you currently manage the property-mask issue with existing tools.
We like trail-blazing with Speckle but not into Sackgassen.
Hi @jonathon,
here is a little interim information: for example, you can use this system for Ifc.
More information will follow in the next few days.
Best regards
Archi
Right. This is what IDS is supposed to standardise.
This is another thing we’ve raised as a scoping feature - filter on receive. I’ve looked at BIMQ previously and it is similar to Speckle in that authors publish everything to it and then recipients get a View of that data. It’s a little ways off from your first suggestion, but certainly something we can look at.
