Last year I had posted to the Revit Forum about this, however it’s just kind of sat.
I’m seeking a better solution due to the nature of my work and hope it’ll also help others out. Many of my jobs are very large (structural firm), the straw that broke the camel’s back was when I had to create 21 pages of dimension plans b/c we had roughly 283 columns, and 3 transfer floors…fun times when engineers get in the model and move something and don’t tell you and dim’s disappear.
So I’ve recently reached out to Autodesk to see if this was an actual error or intent to function like this. Turns out, for now, it’s actually meant to function like this.
I’ve found an almost work around from a script using python (found online not chatgpt)
Key notes about the script:
Grids must be numeric one way and alphanumeric the other. Grids can’t all be letters or numbers. I ran into issues with having angled grids as well.
@jacob.small , do you have any insight/thoughts to a solution?
You can’t modify the built in parameter which is working as intended. The intent is to let the team know more or less where something is, not give final dimensions for location or orientation. That’s what dimensions are for. This is because most columns aren’t as straight forward as we might like - between rotations and irregular modeling of the shapes that data is VERY dangerous to rely on. But since you asked… It is possible to pull the distance from a nearby intersection of two grids.
My graph logic:
Get all grids and the objects which you want to add location info to.
Get the grid nearest location of each object.
Get the grids which intersect the found grid.
From the list of intersecting grids, get the one closest to the object.
intersect the grid lines to find the ‘grid reference point’
Build a vector from the grid reference point to the object location.
Get the grid names and sort them into X and Y directions by putting the X grids first.
Pull the X and Y components of the vector, round to the desired precision, and convert to a string.
Build the offset string by pulling joining the X grid name, X offset, Y grid name, and Y offset into one string.
Set the desired parameter value on the original object.
I’m using the “comments” parameter here, but short of setting up your own shared parameter it looks something like this:
These dimensions could be somewhat automated on a plan as well - doubly so if you had a callable reference to the center of the column or grid intersections.
Attached .dyn is tested in 2024 and 2022 (likely encompassing 2023 as well as a result). I would have tested 2021 as well but my build has been wrecked by an add-in I’m building…
Things you’ll need to account for:
Situations where X grids are a higher value than Y. Just swap the sort order for building the parameter value.
Situations where grids/columns are on varying levels. Use a “all elements of category in view” to fix that.
Situations where you wanted the distance in feet and inches. Currently reporting in the units of the active project directly (decimal feet/ decimal metric things).
Situations where you want the dimension perpendicular to the grid instead of on the global X/Y axis. Geometry.ClosestPointTo > VectorByTwoPoints > strip the Z component and you should be all set in those cases.
Situations where columns are centered between two grids; it picks the ‘first created’. In such cases you may want to test the intersection point of girds instead of the grid curves themselves.
So not only does this work really well, it’s also really fast! The only question I have is how can I get it to show feet and inches instead of decimal feet? I was trying to figure out where to add the Feet2Inches but my Code Block understanding is a weak point.
They were correct in my testing, but if so feel free to add a -1 multiplier.
If your issue is that the X and Y grid references are backwards, that’s because your grids are renumbered in the reverse order; swap the two in the code block.
Everything is working, almost. I’m testing in R23 as well. When changing to the Feet.ToFraction, it occasionally will do some crazy rounding (x/256), I’m working on getting it to 1/8" increments with python.
But also for the code block digits, it’s giving nulls depending on whether or not there’s a long fraction or not. So I’m not able to have the Decimal places higher than 2, which makes the output too short. Column Grid Marks.dyn (114.8 KB)
As well for the Feet.ToFraction, if the column is on the grid it takes the 0 and returns empty.
If you’re going to get the nearest 1/8" value with Python, you might as well generate the fraction string at that point as well; you’ll have better control end to end that way. Note that this means you’re taking on the technical debt of that Python code.
I’d rather avoid python as much as I can, but I’m not really finding any other solutions. My packages may not be the latest either, so if there is a node that might work, I just haven’t found it yet.
@jacob.small, So after tinkering a while I’m able to get it to work perfectly…almost
The only issue now is if i have grids that are angled. For some reason it’s not calculating the vectors correctly. Or maybe too correctly?
I ended up removing the python and found an ootb node
Rectangular Building (works)
(is there a way to know which grid should come first? Is it based on creating the grids left to right and up to down?)
For the angle portion would I need to use a bounding box for all grids/columns inside the bounding box so the vectors calculate correctly? Is that even possible?
When a building has other rotated parts and a normal orthogonal plan, it’s taking true vectors to the center:
For example only sectors A and G are rotated.
My intent on this was to measure on the internal X and Y axis relative to the grid intersections, not the grid itself. This was my point #4 above.
If you want the distance to the grid you would need to first pull all the geometry into a single plane, and use a Geometry.DistanceTo node to get the distance from the column point to each of the associated grid’s curves.
I’ve been trying to figure out where to place those nodes, but I’m just not understanding where. I’ve not really worked with List.SortByKey at all. But the intent is to have the calculated column location mark be perpendicular to the closest grid.
I was kind of wondering about that. If there’s a curved GL, those are worthless for dims, but I was curious if it’s worth doing a rotation/map based location for non 0/90 degree and sorting those separately?
Because as well, the shortest direction from a column to a grid would be the perpendicular distance when looking at column to grid, not column to grid intersection.
I feel like this may open a whole other can of worms.
This is why I used an orthogonal measurement from the grid intersection point… Values will differ otherwise.
When building an automaton it’s important to identify what you need, and what you want, and what would be nice to have. In this case:
NEED a way to find a column relative to the structural grid.
WANT locate the columns in a particular way that addresses edge cases
NICE populating the dimensions automatically
For the NEED, I assumed (perhaps incorrectly?) that the local X and Y axis of the project was known, and therefore I could take any intersection point and move a distance on the X and Y axis to find the column center.
For the WANT, edge cases weren’t outlined so they couldn’t be addressed in the way which was originally desired.
For the NICE… Dimensioning to a point is a mess that I’m not going to get into.
If you can outline those edge cases and why you’d go with one over the other I’m happy to have another look at this, but by adding curved grids things go sideways, and in my daily work curved grids are more common than needing dimensions pulled in a particular way.
Not saying it’s a good idea, but this is how I usually handle edge cases such as slightly arced grids (common with ‘spline’ layouts of things like apartments and dorms).
For us I would say 99% of our jobs has grids like ex2, unless it’s a stadium. Which even then typically has arrayed grids, but they’re still straight. I’m reaching out to a few people in our firm to see what they agree upon, b/c ultimately it’s going to be how they’re laying it out in the field.
