I just discovered the logic was removed that auto-populated a list for parameter values. This was an awesome feature and without it significantly changes the usefulness of the speckle model downstream.
I understand the complications of it being inconsistent between model versions but not being able to visual parameter differences efficiently is a huge step backwards.
For example field crews were using speckle to colorize foundation sizes to quickly understand excavation and formwork. This was a single filter previously that colorized by present values. Now if I select a numeric value it forces a range selection. To get the same look I have to manually create many filters and manually determine all the actual elevations Im using…introducing new elevations means I have to go back and manually create even more filters.
I can replicate that behavior in a PBI dashboard but thats not the environment I wish the field team to have to work in.
It would be extremely useful to have that behavior as an option in the visual.
Perhaps I’m missing an alternate approach that would make this equally efficient as the original behavior?
Yes I’ve looked into them and we do provide dashboards for other phases of the project but it would not be an acceptable solution for the field team.
We need a single source of truth for them to be able to view/comment/visualize.
Sadly it looks like the manual filter option has additional issues as its not just applying a color but rather excluding elements that dont meet the criteria. So for example if I have 4 filters to capture 4 different elevations and I republish with a 5 elevation…those items are invisible.
The old native behavior of colorizing automatically by dynamic metadata without additional setup was one of the best benefits of speckle for many use cases.
There’s several parameters/containers that are best visualized by color to inform planning. Its not always numerical but it absolutely is always dynamic. Things like concrete material strength, elevation at top/bottom, and pour sequence are all parameters that evolve over time. Its almost impossible to replicate similar visuals in the current web viewer.
Hi there! Could you possible show the issues you’re encountering with some screenshots? I don’t fully understand how the new viewer doesn’t allow you to do what you want.
In this sample the end result should be foundations colorized by top elevation. Instead of it being a dynamic value driven setting its forced to a range/scale which elminates the ability to discern values.
If you try to toggle to value not range you are limited to a single entry…so you would have to manually create a filter for every “known” elevation, and the downside if a new elevation is introduced it will not be visible until a new filter is added…so no dynamic behavior
Thanks for the example! And how do you then imagine a dynamic value driven setting to work here instead? We are happy to make tweaks to these filter options so you can achieve what you want – but it’s still not entirely clear to me what the solution is.
