Extend keys component mixes values

[vladimir.ondejcik]

what am i missing?, keys, values are mixed and assigned wrong.

[AlanRynne]

Hi @vladimir.ondejcik!

The Extend Speckle Object by Key Value has some weird data matching logic (made by me so I’m to blame here…) which is caused by the fact that, for each object you want to extend, you can provide more than one key/value, and the values could be items or lists…

We normally don’t recommend using this one unless you’re trying to generate dynamically a new bunch of key/values that are different per object (not just the values, but also the keys).

In your particular example, you’re adding the same keys on all objects, so I’d suggest using the Extend Speckle Object node, which has dynamic inputs and will behave as expected

As for the Extend speckle object by key value. For each object you want to extend there must be:

• Each object must be in it’s own branch
• A list of keys in the same dataPath as the object is in
• A set of value/s for each key, which should be in a dataPath that contains an extra number at the end representing the index of the key in the keys input.

I’m currently quite busy with the new release we’re testing, but I’ll try to come up with an example file for how to use the Key Value one sometime this week.

Meanwhile, I hope the Extend Speckle Object node would do the trick for you

[vladimir.ondejcik]

thank you for help, i will test your instructions

[vladimir.ondejcik]

Hi again, this should match your path description, but still wrong result

[JoostGevaert]

Hi @AlanRynne!

I’m also struggling with this topic. Both with the ESO K/V and the ordinary K/V Speckle components behave very weirdly.

The way you describe that these components should work, i.e.

• each object must be in it’s own branch,
• a list of keys in the same dataPath as the object is in,
• a set of value/s for each key, which should be in a dataPath that contains an extra number at the end representing the index of the key in the keys input,

makes total sense to me, but that is not how these components behave.

In the script linked to this post I divide a surface and restructure the data tree such that the first path index represents the row and the second path index represents the column in which each point is located. I then created a Point ID’s for each point which I then wanted to assign to the point geometry in a Speckle object, but struggled a lot with the K/V Speckle component.

I extensively investigated the behavior of the K/V Speckle component and made the following observations:

1. Without renumbering the Data Tree Paths the K/V Speckle component doesn’t work at all.
2. When renumbering the paths the data in the values on the left of the K/V component (see data viewer) doesn’t match the data in the e.g. Point ID key of the created Speckle objects, see red panel. I’d say the data in the red panel should have been as the data in the green panel (created using the normal CSO component)
3. There are duplicate Point ID’s all of a sudden. That should ofc not be possible.

¿What The Heck?
This is the weirdest thing of all: when you reconnect one of the Renumber Paths components to the K/V component, the content of the red panel changes. That mean that the K/V component doesn’t always return the same output given the same input. Very strange…

I’m looking forward to your reply @AlanRynne!

Session 04 Speckle.gh (24.5 KB)
Speckle stream

[AlanRynne]

Hi @JoostGevaert,

this is… concerning! WTH indeed…
I’ll have a look tomorrow first thing and try to wrap my head around and hopefully get back to you with some answers.

Thanks for reporting this in such detail, and including files! I’m sure it will be most helpful to reproduce

[JoostGevaert]

Hey @AlanRynne & others in this thread,

Happy new year!

Any updates on the K/V Speckle component bugs mentioned above?

[thomas_bush]

Hi,

I have been struggling with the same issue. Are any updates expected with this soon? Defining K:V attributes and attaching them to objects is really important to connected workflows I think.

Tom

[AlanRynne]

We haven’t had the bandwidth to come up with a fix for this yet. In essence, what is happening is that we’re bending GH rules of data matching in order to support item values and list values. Which has turned out to be quite a bad idea, and not something easy to fix.

This is rather low on my priority list right now, as you can still define your own Speckle object properties with either:

• The Create Speckle Object or Extend Speckle Object nodes, for cases where the key’s are fixed (i.e all objects created have the same property names), and each key can have item or list access independently.
• Using a Python/C# script to create whatever objects you need with dynamically generated keys. Giving you total control over the data matching. Grasshopper | Speckle Docs

[thomas_bush]

Thanks @AlanRynne - I managed to get it to work with your pointers and some of the insights from this thread.

I needed a variable amount of K/V properties (number/names will differ based on input). But each value is only an item in my case.

I couldn’t get the K/V components (create by K/V or extend by KV) to work, so wrote a simple python replacment based on Alan’s link.

The overall process seems to be to convert the geometry to a Base speckle object (don’t use ‘Create Speckle Object’), and then extend with another Base object containing just K/Vs. (In my example, the conversion to base speckle object for the geometry is happening when it is plugged into the Extend Speckle Object Component).

Hope this is useful for someone in the future as it took me a bit of working out. I’ve uploaded the grasshopper file too. I’m afraid I can’t share the stream URL as it’s on our companies server.

Add_Custom_KVs.gh (19.1 KB)

[JdB (Jeroen de Bruijn)]

@AlanRynne do you think it would be good to formalize such a work around in an official GH Speckle component? Internally there is quite some interest in this because it allows people to manage the meta data associated with the geometry in a much easier way.

[AlanRynne]

Technically, yes. I’m hoping to do some research on this for the next release cycle (starting next week).

Having a solution that only works for item values is a doable compromise. I’ve been thinking that this could be coupled with GH_Groups to have support for lists and nested lists.

This would enable a simple solution that would not require our own data matching implementation on the component solution.

i.e. If you want to attach a list value, it should be grouped first, and we’ll do the work of swapping groups (and nested groups) with it’s corresponding list equivalents.

Would this be an acceptable workaround @JdB @thomas_bush @JoostGevaert ? Implementing this would be rather straightforward (flw)

EDIT: Now that I think about it, this would be a great way to output deeply nested lists on the Expand Speckle Object node too…

[JdB (Jeroen de Bruijn)]

@AlanRynne

Would this be an acceptable workaround?

Tagging @Mariela_Tsopanova as well

[AlanRynne]

Hi all!

I would like to make some time to tackle this on our incoming release cycle. Would my proposed strategy of using GH_Groups to enable setting list values work for all?

This would mean that, by default, the new K/V node will work by only setting items (i.e. inputs would be 1 object, 1 list of keys, 1 list of values), which seems to be the overwhelming majority of usecases reported. Cross referencing this would follow GH rules strictly (as we wont be overriding anything).

It will be created as a brand new component, and the old one flagged as OLD with the ability to auto upgrade your nodes, so no disruption to your existing GH scripts would happen automatically.

[thomas_bush]

Hi @AlanRynne - I’m not entirely sure what you mean by GH_Groups, but I think each Key should only have one item or object. Before, I’ve serialised a list of values to a string, and then deserialised later. If GH_Groups can acheive similar logic, then that would be good.

The input list of keys and values (whatever those ‘values’ actually are) should match in terms of tree structure / list length, or else it should throw an error I think.

Not sure if this is useful or not.

[AlanRynne]

What I meant by GH_Group was exactly that, a component that would get a list as an input and wrap it as a single item.

This way the K/V components can just be item based (as suggested), and if they encounter this group it will assign the list instead.

I already have an MVP for this, which seems to work quite well, it essence it would be similar to the serialising trick you’re referring to, but would come as an extra Speckle component.

Originally i wanted to use the Group component that is native in Grasshopper, but that one just accepts geometry objects.

I’ll prepare some screenshots throughout the day and share them. I may also release a test version next week with these changes so they can be tested by all of you ASAP.

[thomas_bush]

I’d never come across the group component before, and couldn’t immediately think of another use case. Here’s some more in case anyone is interested What is the purpose of the "Group" component? - Grasshopper

[JoostGevaert]

Hey @AlanRynne,

I’d be very happy with the solution you are proposing
Using the native GH group component, and / or a new component to group data and then making the K/V component accept a single value for each key could be the ultimate solution, not just a workaround in my opinion.

[AlanRynne]

Well I’m very glad you like it… because it’s already in our latest development branch!

feat(GH): New K/V components and Speckle Group for list support

I haven’t updated the docs to reflect this, but they’ll be done before our next release.

[AlanRynne]

If anybody want’s to give this a try before our stable release in a couple of weeks, the nodes are already available in our 2.13.0-alpha1 release we did last Friday