Custom User Data

[didimitrie]

Step 0:

• [x] I've read the contribution guidelines!

A lot of nice (read: core) functionality in speckle is enabled (in gh for now, and if @PaulPoinet would have finished his plugin, in rhino too /snide) by adding custom user data to objects. Specifically, this allows users (clients and humans alike) to ask questions to the API on the likes of can you please give me all the objects of type polyline with an area in the range of 4 to 10 or all objects with properties.likes>100.

In the world of rhinocommon we're struggling to handle this natively, via ArchivableDictionaries which you can set on any GeometryBase object (which makes it a pain in grasshopper).

The question is whether it's feasible for dynamo too. I've deleted the issue template, but one section is actually still valid:

Proposed solution:

• If possible, implement this as close to native as possible via an equivalent UserDictionary.
• If not, this could be added as a last step in the process before sending data, directly on a SpeckleObject. This entails two extra separate components, ToSpeckle and FromSpeckle, and then extra legwork to create dictionaries that then can be plopped in a SpeckleObject's properties field.

Extra Context

There is a plan to automatically populate the properties field of a SpeckleObject, upon conversion, with simple common sense stuff, like length, area, volume and later on things like centroid, bounding box, etc. or platform specific stuff like layer name, colour, etc.

There is a further plan to make custom object definitions into something like templates, ie light schema definitions that can be centralised on the speckle server and thereafter magically embedded as object creation tools on the various platforms (ie, automatically create a component that allows users to populate the properties of a line or polyline so that it can be transformed into a wall in archicad or something).

[teocomi]

AFAIK DesignScript elements don't have an equivalent UserDictionary, so the second proposed solution might be the way to go.

@mjkkirschner do you know if a Dictionary field on DesignScript elements for embedding custom meta data might ever be a thing?

[radumg]

don't know enough about them, but can the TraceData metadata things used in DynamoRevit help in this case ?

[alvpickmans]

Seems like there is no proper way to do this at the moment according to this post on the forum.

A work around could be following similar structure as the Display class? Something like:

    public class MetaObject
    {
        internal object item;
        internal Dictionary<string, object> meta;
    }

Just photoshoped as I am with dynamo 1.3 atm, but shows the concept

[didimitrie]

Reminder, If it's too much of a hassle, second option is still valid (attach extra data as a last step, directly on speckle objects). I was even thinking to implement this in grasshopper as "the way", so as to get rid of all the extra pain and have things more clean and clear.

What's the tradeoff curve in terms of feasibility, quickness to implement, future proof-ness and end user ease of use + communicating the solution to them?

My intuition tells me if we go for a workaround, we might tie ourselves into problems down the line. Or should we wait for dynamo to support this? Or for option two?

PS: Let's try and have future discussions in here rather than on slack, it's much better!

[mjkkirschner]

Dynamo geometry types do have a dictionary called “tags” - but not all objects in the vm have this property, only geo.

On Jul 10, 2018, at 7:24 AM, Dimitrie Stefanescu notifications@github.com wrote:

Reminder, If it's too much of a hassle, second option is still valid (attach extra data as a last step, directly on speckle objects). I was even thinking to implement this in grasshopper as "the way", so as to get rid of all the extra pain and have things more clean and clear.

What's the tradeoff curve in terms of feasibility, quickness to implement, future proof-ness and end user ease of use + communicating the solution to them?

My intuition tells me if we go for a workaround, we might tie ourselves into problems down the line. Or should we wait for dynamo to support this? Or for option two?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[didimitrie]

Dynamo geometry types do have a dictionary called “tags” - but not all objects in the vm have this property, only geo.

noob warning Can these tags support nested structures? I suspect not, going by the name. Nevertheless, this does sound like a good interim solution to me...

[alvpickmans]

but not all objects in the vm have this property, only geo.

Will there be a case where no geometric objects require custom data?

noob warning Can these tags support nested structures?

It seems that tags are dictionaries of type Dictionary<string, object>, so nested dictionaries should work (?)

[didimitrie]

Will there be a case where no geometric objects require custom data?

not really i guess. ideally yes - any speckle object can accept extra props, but this is not implemented in gh (we would need approach 2 to be able to do it)

It seems that tags are dictionaries of type Dictionary<string, object>, so nested dictionaries should work (?)

Then it's cool, we can have feature parity with gh!

[alvpickmans]

will have a play with it later on this week :+1:

[radumg]

Will there be a case where no geometric objects require custom data?

Maybe not in Dynamo, but there will be in Revit, where plenty of elements have no geometry but would still be highly useful to transfer, from Project Information object to weird ones like Levels, etc.

[alvpickmans]

@radumg good point, but I imagine that to be a longer discussion once SpeckleRevit gets up to speed.

@mjkkirschner I had a quick look at EntityTags and it seems that the only way to get values is by using LookupTag() method? Meaning keys/names need to be known in advance. I don't seem to see a way of getting all KeyValuePairs from the underlying dictionary.

[mjkkirschner]

I don't think one exists, I would probably use a pre generated key for all speckle - and nest your own dictionary under that.

[alvpickmans]

Of course. My only concern about this would be data loss if user adds tags via other node/package rather than speckle. I think Spring package also has nodes to set/read tags. If this is the case, when serialized in Speckle any possible tag not created with SpeckleDynamo won't be sent.

[didimitrie]

Would it then not be easier to use the Spring ReadTag and SetTag node then, and just implement the conversion handling in the DynamoConverter then?