Afaik, (Revit) parameters are only uploaded to Speckle, if they carry any value. (Not sure if this is the same for userStrings?) Instead of uploading (possibly) hundreds of parameters without content, I guess this makes sense.
But wanting to handle/modify parameter values through an external app, I would have to know, which parameters actually exists in the original (Revit) model (per category) … so which parameters would be available to actually write into.
Is there a strategy for that? Thoughts?
Am I even correct? … I am assuming, the connector wouldn’t create/assign any existing Revit shared parameters as project parameters to the categories back in Revit, if the cloud model/parameter updater object contains any corresponding parameter values for some elements of that category? I assume it’s just ignoring the parameters, which the connector can’t find in die target model?
Currently, I am going through the entire model to find the parameters, which do have a value for at least one element. And then I can assume, that this parameter is available for the entire category/collection.
But I am trying to avoid assumptions …
Also, I would still miss the parameters, which haven’t been filled out in Revit for any element at all.
Changing this is relatively simple but could add quite a bit of noise.
And likewise, any incoming (shared or not) parameters that do not already exist on an element are skipped during receive. This would be more complicated for us to support.
Could you tells us a bit more about what you’re building? It would help us get the bigger picture, and there might be some other ideas we can suggest.
Sure.
I am currently developing a web app to view/modify parameter values of an uploaded Revit model. Similar to the ParameterPanther, but with some more functionality.
Therefore the app would have to know, which parameters are available in the original source model (Revit in that case) and could be edited.
In between I am filtering the parameters down to our company’s shared parameters, but this is just an additional step and shouldn’t concern the above topic.
I understand, that uploading empty parameters also can’t be the solution. And it should be a general solution. So I don’t really have one.
I’m not sure if that would be too specific for Revit, but might it make sense to add collection-wide parameter definitions (like project parameters in Revit) to the collection’s data property? That way, those (potentially many) parameters just have to be saved once and not for every single element (except it would have a value).
Then, you could also start thinking about just referencing/detaching it’s definition inside the element’s parameters, which would even save memory … but also would make things more complex to deal with. And I assume you have some reasons why you haven’t done this already.
On the other side, Revit doesn’t have parameters just for a single element (in contrast to userStrings in Rhino). So if I would like to edit parameter values for multiple elements in any kind of table, I need to know the logic of the model context and have to leave the per-element-level.
For example, the system parameter in Revit is called “stage.” In Revit, it naturally exists for each element (in this case, for rooms), but in Speckle, such a parameter is not present for rooms. I have also encountered similar issues with project parameters. They exist in Revit but are missing in Speckle.
Thanks for the explanation! It helped us a lot and @AlanRynne had a brilliant idea:
In the Revit connector, we have an option to just send the Types in the existing document, we could make sure all parameters are added there so that:
we’re not “polluting” elements sent in the traditional way
you’ll be able to map and know the full list of parameters for a specific element
The only downside would be that, since the “Project Information” selection filter cannot be combined with the others, it would require sending twice (for now).
I have double-checked the export, and here’s what I found. There are stages for the geometry related to walls, but when it comes to rooms, there are none for any type of export. What would you advise?
Thank you very much! This will be very helpful as my current work is heavily focused on rooms. I would also like to draw attention to two other things:
It’s aesthetic - in the parameter names, their ID is written instead of their actual names, and it seems to be random. Some have names, while others have IDs.
Some project parameters are also not being exported to Speckle. Specifically, the project parameters assigned to rooms. If necessary, I can prepare a Revit file and send it to you for testing purposes.
That would be perfect - you have my email if you want to share it privately.
In the meantime - I’m going to check if the randomness is something thrown up by the server Frontend service or if the underlying data is written that way.
We would be in support for sending all the data about an element even if the value is empty. As said, the ability to modify or watch a parameter value even if null is important to a lot of workflows. Consider model audits or compliance checking. We are not for making those opinions on the data before it gets extracted.
Can there be a config setting that would allow a company to choose to either send all the parameters regardless of value or not?
Hey @teocomi … sounds like an interesting approach.
Would be interesting to see, how the parameter logic/scopes from Revit can be represented as JSON.
But that would also mean, an app would have to search (and hope) for a previous commit, which contains the types … and hoping again … the types are still the same as in the model I actually want to process. Right?
To be honest, I’m a little sceptic, if that would be a fail-proof solution.
If the types would (always) be sent within the same commit as the model, it’s a different case. And this should work then… but they shouldn’t be separated.
