Great stuff!
@gleeuwdrent: interesting to have a look at this.
1 Like
Featurelines as mentioned earlier, Alignments is a must. I see it in the same category as Featureline
I think it’s interesting to bring pipe networks/pressure pipe networks data to Speckle. Especially if you work with with non-precast structures. Extend exchange to hydraulic calculations, Structural detailing of a Manhole to Revit and structural calculations to calculations software.
Also what can C3D retrieve back from other programs, then I think elements from other software to blocks. Example piles to blocks or v.v. Linear elements like railing to a 3D polyline or solids export.
4 Likes
Would there be some way to manage shared coordinates through Speckle? Revit has lots of trouble with this when encountering many different (legitimate) things surveyors do in AutoCAD or Civil3D files.
I would see this being implemented as a transformation that is performed on geometry as it’s streamed to one platform or another. So each stream would have to store a transformation relative to a known point that is coordinated between each of the files. This is probably a lot of thinking for a pretty narrow use case, but for architects at least this is a big unsolved problem.
1 Like
This is definitely a common pain point, glad you brought it up Nick! Pinning this as an issue when we move towards developing project management features after the beta. We could potentially store an origin point on a project / team level so that the correct transformation matrix can be automatically applied to all child streams 
3 Likes
Quick intermission to say that, currently, transformations relative to Revit’s Base point are applied when receiving and sending. Not sure how AutoCAD deals with it, but we should definitely align 
Adding Solids with propertysets to connector functionality is urgent as well.
When you want to communicate on other software, e.g. Revit or Rhino, but also navisworks solids are the main medium for communication.
Why to the revit project basepoint and not the Internal Origin?
With that justification, we’ll see if we can bump solids up and support them sooner! Will keep you updated on this thread 
2 Likes
Hi @Dickels112 , we’re applying transformations relative to the Revit project basepoint as we’ve found that would produce the most predictable results when collaborating with other software sice that’s what is used by surveyors etc.
I do see use cases where the internal origin could be preferable, but hopefully they are limited!
Did we get this wrong, or is this a deal breaker for you?
At some point we could have a setting letting people decide which one to use, but for now we’d like to keep things simple…
Sorry for the late reply.
(speaking from Civil Engineering standpoint):
The problem with Project basepoint and internal origin is that the project basepoint is meant to be used in the same way as a “UCS” in AutoCAD, while the Internal Origin is actually used to calculate all coordinate positions in the model from. this means everything, including the geometry extents is defined by the internal origin. not the project basepoint. The project basepoint also allows you to rotate model geometry with regards to “project north”, so by default this can give problems with recalculating/repositioning geometry. For me, when transferring geometry from Civil3D to Revit, I use the relative position to the interal origin because of the flexible meaning of the project basepoint itself.
With regards to survey: this is what the survey point is actually meant for, but no-one is using it in that way.
1 Like
I suspect that the best solution to the c3d/revit basepoint issue is to by default use the internal origin, while including the base point and survey point in project information. These variables could be stored in a stream’s globals branch, and included as a toggle option for receive operations to handle geometry transformations - that way we aren’t biasing towards users who care about the base point vs users who care about the survey or internal origin.
Implementation of this could be difficult at the moment, but I’m curious to hear what others think 
3 Likes
Hi @clrkng, we are starting to look at this as well. I agree that we should separate consideration of 1. what data we send and 2. what transformations the connectors apply by default.
Given that the base point and survey point may change as a project is developed (it shouldn’t but, let be realistic 
), it may be better to tag them on the base commit object rather than the stream globals.
1 Like
I’ve spoken to some colleagues, and we try to keep the Internal Origin and Base point aligned, so exporting relative to the internal origin makes sense.
Here are some workflows we are thinking about:
- Revit → GIS: If the stream contains the Survey point, the receiving connector should be able to directly place the model in the right spot.
- Rhino → GIS: so it turns out you can geo-locate Rhino models! Who knew? This is similar to the Revit → GIS case.
- Microstation / Civil3D → GIS: These ones are a bit tricky, because road and rail alignments are big enough to generate projection errors if we aren’t careful. The sending connectors would have to send the Coordinate Reference System (e.g. EPSG code), which would be easily understood by GIS applications.
- Microstation / Civil3D ⟷ Revit: There would have to be some mediation between the two different mechanisms for georeferencing (CRS vs. Survey Point), but I suppose if we’ve sorted out the first three items, this wouldn’t be too hard.
One other concept to consider is Revit’s Shared Coordinates. My understanding is that Autodesk gave up on getting people to properly geo-locate their models and developed the Shared Coordinate system to allow manual determination of the transform between two specific files. Perhaps Speckle could do something similar: when importing a stream, allow users to set the insertion point, and then retain that information for future imports. It’s not as ideologically pure as properly geo-locating each stream, but it lines up nicely with what people know and expect today.
2 Likes
@daviddekoning your understanding about Autodesk is correct, though if you set-up your templates correctly, the information is almost always automatically positionned over correctly (except for IFC files), with no manual work.
This is the key. It’s the situations where someone (usually from a company outside yours) provides a file that isn’t set up right where shared coordinates provides a safety valve. I agree that most of the time, proper set up deals with the issue correctly.
So I tried to load in solids through the speckle alpha connector, and it works! (whoow). One. major. downside.
It is positioned in revit on absolute coordinates in relation to the project basepoint… So my solids appear now around 400k too far from the internal origin. This is why it is important to use Shared coordinates or shared sites to position to. Is there a workaround known?
@Dickels112
I am working on this currently! Drafting up an option in the new Desktop UI to allow users to select which project point they want to receive objects in relation to.
This is gonna be a big change as it depends on some Transform work, so it may take 1-2 sprints to iron out! You can track the issue here
3 Likes
@clrkng Thanks a lot! currently i am just incoorporating a geometry.translate respectively to the absolute coordinates of the internal origin. Works like a charm! One optimization that can be done is for uploading complex solids. Can we incoorporate some sort of analytic where it checks solids for ‘size’ (not geometric, but memory size) and notify the user when a solid will take a long time to upload? (and maybe also give them the option not tot down/upload said solid) now my upload will just hang untill i remove the stream from my connector.
2 Likes
Ah yes this can be its own thread actually, feel free to start one! Being able to filter which objects to receive per commit is something we’ve discussed before and I agree it would be super useful to have!
1 Like