Get Solid for Linked Element with Duplicate Id

[Anonymous]

I'm running into a frustrating problem when trying to get a solid for an element that lives in a linked file. Right now I'm using the custom exporter to get all the elements in a 3d view and then using Revit's get_Geometry method on certain ones in order to do a type of overlap detection.

Solid solid = element.get_Geometry(opts).FirstOrDefault() as Solid;

This seems to work fine for anything in the current file, and it seems to work fine for most elements in linked files. But if the linked element happens to share an id with an element in the active file, then doing the above returns the solid information for the element in the active file instead. This is the case, even though the element is clearly the correct element.

In a sample file, I have a linked file with a wall that has the same id as a window in the active file. When I debug the code at the line above, even without getting the firstordefault or converting it to a solid, I can clearly see the element is a wall but the solid the method returns is for the window. It seems that Revit's method is just using the id alone.

I've tried changing the View value in the Options object fed into the method, but I don't have an active view for the linked document and no other view I could find made sense. I've also tried changing the ComputeReference value, just to try. It changed nothing.

I've gone looking online and in the forums for other ways to get at the solid information for a linked document. This link  (https://forums.autodesk.com/t5/revit-api-forum/linked-file-element-intersection-solid-geometry/m-p/7...) suggests there is a method with the line in the accepted answer:

Open the linked project Q and retrieve the solid Sb of B.

Sadly, I can find no more information about how to do that. Can anyone point me to a way to do that, or find some other way to work around the bug in get_Geometry?

[michael_weizmann]

That's true

[jeremy_tammik]

Ok. I asked the development team for you.

[jeremy_tammik]

Good news for you! The development team reply: we added this capability in the development branch of Revit for inclusion in the next major release:

•  API for filtering elements in a host view from a document associated with a specific linked instance. A new constructor for FilteredElementCollector takes the following arguments:
• const ADocument* hostDocument : The document that owns the view.
• ElementId viewId : The view id in the host document.
• ElementId linkId : The Revit link instance id in the host document.

Thank you for raising this question and for your patience while we make this functionality available to you.

[michael_weizmann]

Thank you Jeremy

[phan_thanhFXPSF]

@michael_weizmann 
Hi, I just encountered the same issue as you.

When the Revit link and the host model both have elements with the same ID, Revit retrieves the wrong geometry — it returns the element from the host model instead of the one from the linked model.

After removing the conflicting element from the host, the geometry is correct, so I don’t believe the issue is in the code logic.

Do you have any solution for this, preferably one that doesn’t involve removing the view from the options? I still need it.

[phan_thanhFXPSF]

Hi @jeremy_tammik , can you please check the issue again?

The FilteredElementCollector just helps us retrieve the linked element from the host view.

The real issue seems to be with Revit’s get_Geometry() method.

It returns the geometry of the element from the host model instead of the one from the linked model when both have the same element ID.

[TripleM-Dev.net]

Hi @michael_weizmann ,

From one of the posts it looked like the elements of multiple documents were put/processed together. If the ID is used as key then 2 elements with the same key will "overwrite" each other only leaving one, or on iteration the first matching id is used....would need to check the used code to determine this.

Split the processing up by document, then this shouldn't happen.

I have several large commands that also gets info from current document and (multiple) linked documents together.

I setup a seperate class (wrapper for document) that handles a single document (current, linked, other open document no matter), for each document to eval one instance is used to process a document. afterwards if I need elements combined, it's add a index to the Id's to id the correct document for further processing.

Never had a issue like this, and in testing I regulary used copies of the same document for interference check etc so had same id's

Also a custom class for a document is also handy if a transform needs to be applied to retrieved geometry.

- Michel

[phan_thanhFXPSF]

Hi @TripleM-Dev.net , thank you for the reply

Actually, I tested it with a very simple setup.

 ElementId revitLinkInstanceId = new ElementId(958745);
 ElementId linkedWallId = new ElementId(958843);

 RevitLinkInstance revitLinkInstance = doc.GetElement(revitLinkInstanceId) as RevitLinkInstance;
 Transform transform = revitLinkInstance.GetTotalTransform();

 ElementId revitLinkTypeId = revitLinkInstance.GetTypeId();

 Document linkedDoc = revitLinkInstance.GetLinkDocument();
 Element linkedWall = linkedDoc.GetElement(linkedWallId);

 using (Transaction transaction = new Transaction(doc, "Debug geometry"))
 {
     transaction.Start();

     var geometry = linkedWall.get_Geometry(new Options()
     {
         ComputeReferences = true,
         View = RevitApp.ActiveView,
     });

     var extractGeometry = new ExtractGeometry.ExtractGeometry(RevitApp.ActiveView).ExtractEdgesFromSymbolGeometry(geometry, Transform.Identity);

     List<ElementId> createdModelLine = new List<ElementId>();

     foreach (var lineGeometry in extractGeometry)
     {
         var line = lineGeometry.Line;
         var reference = lineGeometry.Reference;

         var startPoint = line.GetEndPoint(0);
         var endPoint = line.GetEndPoint(1);

         var transformStartPoint = transform.OfPoint(startPoint);
         var transformEndPoint = transform.OfPoint(endPoint);

         Line line1 = Line.CreateBound(transformStartPoint, transformEndPoint);

         var modelCurve = DebugGeometry.CreateModelCurve(doc, line1);

         createdModelLine.Add(modelCurve.Id);
     }

     RevitApp.Selection.SetElementIds(createdModelLine);

     transaction.Commit();
 }

I retrieved the exact linked element by ID and extracted its geometry.
In the code, I’m getting the correct linked document and even the correct linked wall element —
But the geometry still comes from the wrong element.

The issue is clearly with Revit’s get_Geometry() method — it returns the geometry of a different element from the host document, not the one from the linked model.

[TripleM-Dev.net]

You're mixing a Linked ElementId with the geometry option of the current view, maybe that's what going wrong.

I never apply the current view geom for linked model elements.

Also no idea what "ExtractGeometry" does, but it also gets the CurrentView as argument so could be something in there.

As stated earlies don't mix document references, keep them seperate and process only the endresults (like the resulting solid)

[phan_thanhFXPSF]

The ExtractGeometry method only retrieves lines from the GeometryElement.

I’m wondering if some element references, like center lines, require a View to be specified in the Options used for geometry extraction.

For example, with ducts - you can’t get the center line unless a view is included in the Options.

Thank you in advance

[TripleM-Dev.net]

Hi @phan_thanhFXPSF ,

Don't know about that specific element, but using the Host model's view for a linked element doesn't sound ok.

Could be Revit then uses a element with the same id in the host model.

Maybe in the Newer API's of R2025?