There is a suggestion, not mine, further up this thread that Speckle might be usable as a coordinate system hub. To me this is an attractive prospect, that potentially does away with a lot of the issues of the user setting it up wrong, or not at all.
Is there any scope that instead of speckle trying to rectify one apps setup against another, it might be better to offer to turn the problem inside out and have the user pull coordinate setup, with appropriate context complexities, which are lower for building and higher for infra into whatever authoring software they are using.
Could you expand on what you mean by âCoordinate Setupâ, I can instantly think of many things it could mean.
Youâll find there are numerous other discussions/streams of consciousness here in the community about coordinates as Speckle supports software with assorted capabilities and across our users with Macro to Micro endeavours. Our recent work in the GIS space has been to attach custom CRS on send/receive, And also with Revit to optionally use similarly defined coordinates as the reference for spatial remapping. Rather than Speckle fixing/rectifying anything.
Certainly, it is something I have wrestled with in my embryonic third-party Navisworks Connector (still nearing alpha) - It is a world of no right answers.
âIt is a world of no right answers.â - yes I know your pain there. And apologies, if as a newbie I am not up to speed, I have searched a bit for similar topics.
It may be that I have a measured survey related bias here, and Iâll note that I have no experience of Rhino or Civil3D and how they work, but better experience of Revit, AutoCAD and Microstation. In practical terms I am talking about the near project start process of deciding and documenting the reference points for applications that need modelling to be in a local high accuracy coordinate system which references a global one.
I think its much simpler is a building context, because generally scale factor and projection errors can be ignored in a way that it simply canât for big linear infra.
My suggestion is that if the knowledge of each applications behvious sits inside speckle then in platform may be a better place to administer the management and distribution to outside the applications themselves. The reason I speculate about this is that people often know the application they are using well, but not
In the same way that speckle has a wall in its object model that references applications walls, a location reference, which could be characterised as a survey station could be a starting point and prompt with what the extent of say Revit or Rhinos solids modelling area.
ps. donât get me started on feature coded data from survey packages. So much valuable information in them that gets flattened and lost in DWGs!
This makes sense. Implementation of something like this, or addressing it, is an ongoing discussion and something that can in theory be supported - adding your context is helpful. Thanks.
I know you very well, but please feel free to introduce yourself. Having a broad range of domain experience is spectacularly useful to the Community and us.
Hello,
It would be very helpful to have the option to disable the prefix âstream[ branch @ commit id ]â being added to Layer Names and Block Names when receiving to Civil3D. Many clients have strict naming conventions, and while the layers and blocks can be renamed. Currently each layer and block would have to be renamed after each commit.
Another behaviour, that for me doesnât match with for typical drawing productions, is objects (lines, curves, meshes, etc) are being received with their properties like Color and Linetype set to specific values (e.g. colour 0,0,0 or Continuous) inherited from their layers as opposed to being set to âByLayerâ as they were in originating software (Rhino in my case).
With the latest release 2.11, the prefix shouldnât be added for layer or block names when receiving in update mode - I can see that this could be useful option for create mode as well though, so we can consider adding the option as a setting.
Another behaviour, that for me doesnât match with for typical drawing productions, is objects (lines, curves, meshes, etc) are being received with their properties like Color and Linetype set to specific values (e.g. colour 0,0,0 or Continuous) inherited from their layers as opposed to being set to âByLayerâ as they were in originating software (Rhino in my case).
This behavior will definitely be implemented when we add better Layer support and start sending layers with materials and display styles attached - weâll make sure to update object display inheritance when we get around to that
Having a broad range of domain experience is spectacularly useful to the Community and us.