when exporting data to Speckle (with Frontend-2) from Civil3d (2022) we encounter grayed “propertySets” arrays. I’ve found a possible reason within the frontend’s code where non-primitive arrays are not inspected recursively.
I guess that the reason is somewhere in the Civil 3D plugin. Other plugins (like Revit) and even IFC import store propertysets and properties as objects (i.e. inside “parameters” or on the base object’s level)
Is there any reason known, why Civil 3D stores property sets in this way? Is there any known conflict to other plugins, if the property sets would be stored in the same way like all other plugins do?
For context, we currently do not have a standardized approach to sending parameters, property sets, attributes, and etc from our various connectors. Civil3D is sending PropertySets as List<Dictionary<string, object>> .
We’re looking to build better cross-application parameter handling eventually, and this would apply to some of our existing properties such as:
Rhino user strings: [“userStrings”] = Base of keyvalue pairs
GIS feature attributes: [“attributes”] = Base of dynamic props
Revit parameters: [“parameters”] = Base of Revit.Parameter
Civil3d part data: [“partData”] = List<DataField >
Structural and Archicad props
It seems the new frontend doesn’t traverse Lists by default, in the meantime I can switch the Civil3D properties to be sent as a Base to align with the other connectors
this would be great. Storing custom property sets as Base would also align with IFC Imports.
Cross-application property handling is quite difficult since you have to distinguish “parameters” and “generic properties”. A parameter is bound to behaviour of the specific application, while a generic property only represents semantic data of domain knowledge. Each application does this separation by its own. Therefore it would require Speckle to provide a way to specify and store property/parameter definitions across applications. This would be a real game changer and lifts Speckle from model repository only to something model spec driven.
Hi @clrkng these updates to Civil 3d Connector are great.
Although not directly related to the above, testing the dev connector I’m getting a Bug with the BaseCurve on pipes. Which seems to be defaulting to [(0,0,0), (0,0,1)] for all Pipes.
We are using this base curve to recreate our network in Revit.
there’s another issue with custom property sets. The name of the pset isn’t properly set to the Speckle’s pset. Additionally, the former connector seems to reset pset names while receiving data to some generic values (i.e. “Speckle …”) which causes problems. The current fix doesn’t even import any data (due to the change of pset type to base object).
I’ve fixed it and would create a PR against dev. Should I open a bug report before?
@bekraft good catch on the receiving psets bug, that fix should definitely go in asap
We’re pausing improvements on our 2.x connectors in favor of focusing on 3.x, so the pset name change is out of scope for the upcoming release. Your point is noted however, to date Civil3D is mostly a sending connector so the receive functionality is quite limited, and a lot of elements will be revisited for the 3.x version.
If you don’t mind submitting a pr with only the receiving base property set fix (without the name changes), I’ll review & merge asap. Happy to ping you for better property set conversions in 3.x as well, when we get around to it!
Ok. Actually, the way psets are named is crucial. Otherwise the connector isn’t able to figure out which pset has to be changed. The currently used name of psets in the connector of Civil3D is not correct anyway.
We’re trying to wrap up 2.20 testing now, so I’ve made a pr from your report: the property set name has been changed to use the definition name, though the rest of the receive behavior in creating a new definition with the Speckle name will remain the same.
If you’d like to keep up with the v3 connectors, there’s a basic Civil3d implementation in place in our new repo: GitHub - specklesystems/speckle-sharp-connectors: Speckle Connectors V3
We aren’t supporting the v2 update receive behavior in any v3 connector, and won’t enable receiving in Civil3D until our supported workflows have been clarified - I’ll circle back to property sets when this is done!
Ok. Means that I have to provide a fix internally for our team working with Civil3D until v3 is released.
A bit off-topic for this thread: Do you have any insights as to when v3 is about to be released? Since we work at Inros Lackner on a internal model property specification platform which relies on Speckle, I’ m keen to know more about the v3 plans (especially on property handling). Is there any feedback channel / involement planned for contributors/implementers?
So, last: If you’re saying that the update receive behavior isn’t supported anymore in v3 - what does this mean? - Updating existing platform work models from Speckle is not supported anymore?
A MVP version of the v3 Connectors for Rhino, AutoCAD, Revit, Sketchup, and ArcGIS will be released in September. Civil3D will not be included in this first release because we need to define internally which workflows we would like to support, to make sure we can support them well.
I’d love to learn more about your implementation with Speckle at Inros Lackner for this purpose, if you’re available for a quick interview (will pm)!
Re: update mode, the v2 connectors did not implement updating behavior consistently or reliably, so we have simplified the behavior in the connectors for the MVP versions. v3 connectors will also come with some nice additional features for change tracking in your application models.
Hi @clrkng! Sure we can have a quick call. I’m available from 3pm (2pm London?). Currently we are in a more conceptual stage and start to develop and use things where Speckle would play a central role. It would be great to talk to you.
