How to set the data of each component of a stream?

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.:

  • Data that represent business secrets,
  • data that are not required in the respective project phase,

So how can data be excluded from export depending on the component?

Best regards


1 Like

Hi @rolfarchi! Interesting request you’ve got for us - we always assumed the more data, the better :smile:

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?).

1 Like

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:

  1. only provide the attributes/information that are required for other stakeholders at the respective point in time in the planning process.
  2. only provide information that is bindingly defined at the respective point in time in the planning process (e.g. compressive strength class of a wall material); attributes that are not yet bindingly defined may contain default values (= incorrect information) that are changed in the further course of planning.

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:

  1. the structural engineer is interested in density and strength.
  2. the MEP engineer needs the thermal conductivity.

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



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


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.

1 Like

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


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.

Hallo Jonathon,

please excuse my late reply.

We define the parameters to be passed for each element type (radiator, pipe …).

In Revit it looks like this:


The parameters are written to the components as configured.


I hope the principle is understandable.

Best regards