Hi all,
I found that Element.Location returns inaccurate result on several beams. How come?
Thx!
You try node “StructuralFraming.location”
1 Like
Hi, i maybe have a clue : the [Element.Location] node retreives the family “basic geometry”. For example, a window location is just a point. But if the window’s family was created with an insertion point set up in the up-rigth corner of the this wondow, then the location given by this node will be this point, which isn’t at all acurate.
What i suggest is to try to edit your beam family and check wether the reference axes are well positionned.
2 Likes
really is a good point, thx. I’ll look into it. 
I think the problem is, that the location is pulling the end-points of your element, and not the overall geometry.
This also applies to joins at columns. The points are defining the location, not the geometry.
I don’t have a solution, but perhaps you could pull the points to the outside faces of the beam geometry?
1 Like
Not very elegant, but I guess it works.
You can see the origin of the beam at the preview points and in the Watch-Node at the bottom.
Watch Node at the top displays the correct values.
The solution looks like this, but THERE IS A CAVEAT!!!
This will only work where the origin line is intersecting the geometry.
This will not work in this case. There you would have to scale the line.
(I would say, according to the cut length plus some factor.)
1 Like
Hi jshial,
What exactly are you trying to accomplish?
To understand what you’re getting from Dynamo’s location nodes, you have to understand how beams (structural framing) work in Revit. Beams are “curve driven” elements. The “location” is a curve (usually a line, but it can be also be an arc, partial ellipse, or spline). That is the basic definition. However, where exactly the geometry ends up depends on other elements in Revit and their proximity to the beams (beam “joins”), as well as many other parameters.
So, you have:
- Beam Joins, which will automatically extend or cut back an element based on what it’s joined to (an entire topic in itself)
- Start/End extensions (if end is not joined)
- Start/End cutbacks (if the end is joined to something else)
- Y justification (“horizontal” offset)
- Z justification (“vertical” offset)
- Justification reference (top/bottom/left/right/origin, based on references in the beam family itself)
- Justifications can be uniform along the entire beam, or different at each end
- Cross-section rotation (which will also affect the direction of the offsets)
In addition to all those “built in” parameters, the family can have additional parameters that push the geometry around- extensions, offsets, whatever- and those can be different for every family. (the older “out-of-the-box” beam families have additional rotational and extension/cutback parameters, from the time before these were system parameters.)
If you need to know the location of the actual geometry, you can use the element.geometry node. If you want to figure out the “actual” endpoints, you’ll need to add some logic and do some math to account for all the possible modifications that can be made via parameters.
Joe
1 Like
By the way. I should ask about how you typically extend items in Revit.
I’ve noticed that many users gravitate to the align command.
I generally discourage this because of unintended consequences it may produce in the model accuracy.
Using align to the xt news the end of a beam grabs the geometry pulls, and not the control points. The extend multiple command does.
it’s not because of the family since some other beams are the same type while having the correct result. But really is a good point, a poorly made family could be the reason behind this, I’ve never thought about it this way. Thx
Hi Owens,
Great observation!
I think u are right, Element.Location does follow this little round blue grip.
I haven’t encountered the case that LocaLine is longer than the real length. Geometry.Intersect is a solution indeed. Currently, I still stumble at dealing with “shorter” LocaLine. I will look into ur suggestion about “according to the cut length plus some factor”. Thx~
I barely extend things. For this case, I just drew several beams along the grid while some of them has strange results.
Hi Joe.
Thx for ur detailed explanation. I always take it for granted that Element.Location should return the line whose length is equal to that of the beam.
What I’m after is get the locaLine first, establish a coordinate system at its midpoint. The fact that “shorter” locaLine would eventually give me an “inaccurate” cs_Origin. Element.Geometry does give me a hint. A workaround to this could be getting the centroid of the Beam Geometry and translate it upwards for half of its “h”. But still, knowing the locaLine is influenced by so many factors is great.
Thx Joe, I’ll look into this.
jshial
I am very happy to find this information here. I was just encountering the same issue.
In my case I created some family instances from insertion points, and then after creation I wanted to compare Element.GetLocation values with the original insertion points. And in some instances, they didnt match!
This might very well have to do with family geometry not being at the family origin, as these are catalog families which I didnt make myself.