Min z value of geometry get wrong value because off reference planes or lines

I need to get the minimum z value of generic line based family in a project. I use python to get the geometry and then get the boundingbox to get the min z value. But not always I get the right value, I think this is because the reference planes of reference lines in the family are sometimes longer then the geometry itself. So when the reference planes or reference lines are longer then geometry in the family itself, I get a to low z value. In the screenshots I provided an example the lowest z value in project is -70, but python gives a value of -316.

My question is how can I get the right minimum z value

Extra information:
I use python to get the geometry instead of dynamo node geometry.element, because in this family there are voids that can overlap and the dynamo node can’t handle that, but revit api can.

Try filtering for solids only.

As far as I know the bounding box is always calculated in the canonical coordinates and it’s meant to to be a quick and approximate method of finding where the element is.
That alone can cause a different lowest Z point value than what you expect.
So I would go with what @Nick_Boyts said and go for the solids

How do I get the solids? I can get the geometry from the element, see screenshot. How do I get from the geometry instance to solids?

I’d start with Element.Solids and BoundingBox.ByGeometry.

The element.Solids in dynamo doesn’t work because in this instance some voids overlap. I know that the revit api doesn’t have this problem. So i need to know how to get the solid from an element via the revit api in python

Extra inforamtion:
I tried using the dynamo node Element.Solids within a python script and that also doesn’t work, I get the same error.

Are all your reference planes set to Weak References? I’m not having any issues with reference planes contributing to my bounding box (and you can see I have reference planes extending way beyond -1.5" and 24".)

This is in 2022.

Reference plans have no impact I am aware of on an element’s geometry or bounding box.

How do you know this? I can’t say I have seen any discrepancy between the geometry bounding box and the element bounding box in either method, so would love to see a reproducible case so that we can get it addressed. I have seen confusion stemming from the bounding box’s coordinates reporting from the internal origin instead of the expected coordinate system. Exporting the min and max point directly into the Dynamo and Revit environments (removing the conversion function and the data offset) should confirm things are working right. Sending back the bounding box and converting it to a cuboid should do the same.

If you do have a reproducible case post an RVT with just the instance in question and all associated geometric influencing elements so that it can be reviewed.


I found the problem. When reference lines in a family are set to weak reference or strong reference it counts as geometry. Setting it to not a reference it will not count as geometry. I added twee examples families one with reference lines set to weak reference and one with reference set to not a reference.

Is there a way to ignore the reference lines with weak references in the geometry? Because in other family I need the reference lines to make an anguler dimension.

I also added the a simple python script to get the solid for a get_geometry.

Are you referring to how I know that the dynamo node geometry.element doesn’t work when voids in the family overlap and with revitapi I can get the geometry?

generic line base model ref lines not a reference.rfa (404 KB)
generic line base model ref lines weak reference.rfa (404 KB)

geometry to solid.py (817 Bytes)

Correct. My guess is that there is something more going on than just partially overlapping void hosts.

I found the problem why the element.geometry node wasn’t working properly. In the dynamo script I had made a simpel python script to get from a number to a string, without having to deal with decimals what happens when you set a number to string in dynamo. Apparently the standaard import clr command disrupts the function of the element.geometry node. I added a screenshot of the script, when it was not working. Removing the import clr command will solve the problem.

1 Like