Hello
I am working with a survey which has a physical survey benchmark drawn, with an elevation given in decimal feet (2818.09'). I input this number into the "Elev" parameter of the Survey Base Point, with the Survey Base Point unclipped. It accepted the elevation in decimal feet, but immediately converted it to Feet and fractional inches (2818' 1-5/64") in the Properties Panel and the readout at the Survey Base Point when I select it.
The trouble is, 2818' 1-5/64" = 2818.08984375'. It does not equal the decimal feet elevation I actually input: 2818.09'
I initially assumed that the conversion was only graphical, meaning Revit was holding on to the original input number with full precision, in decimal feet. But in pulling out some data in Grasshopper I found that in fact, it seems Revit really did convert my number from 2818.09' to 2818' 1-5/64" (2818.08984375'), introducing an error of 0.00015625'. This is obviously a physically negligible error, but it is not mathematically negligible, and there is no reason for any error in this operation of inputting a survey elevation. Besides, surveyor's elevations are in my experience, always given in decimal feet.
Can anyone shed light on this? Am I missing something? I can see a work around for this would be for me to convert the elevation to Feet and Inches first, with a more precise denominator, then input that. But this isn't really a better solution when coordinating with my Civil Engineer who will be using the actual project elevation.
Thank you
Brian
Gelöst! Gehe zur Lösung
Gelöst von SteveKStafford. Gehe zur Lösung
I just tested changing the Project Units to Feet (which is decimal feet), with three decimal places. The Survey Point now reads an elevation of 2818.090'. Does this suggest that actually Revit did store the correct input value of 2818.09' and that the conversion to 2818' 1-5/64" was non-destructive (i.e. graphical only)?
@brianorser wrote:
I just tested changing the Project Units to Feet (which is decimal feet), with three decimal places. The Survey Point now reads an elevation of 2818.090'. Does this suggest that actually Revit did store the correct input value of 2818.09' and that the conversion to 2818' 1-5/64" was non-destructive (i.e. graphical only)?
Yes. You can export to DWG and verify in AutoCAD. I did and 2118.090' in Revit is 2818.090' in AutoCAD.
Hi @ToanDN
This makes sense. However, I cannot permanently change the Project Units to Feet because the project needs to be in Feet and Inches. I wonder if it is safe to assume that while the Project Units are Feet and Inches, the elevations I input in decimal feet are preserved with full accuracy. I'll try testing this a bit.
@brianorser wrote:
Hi @ToanDN
This makes sense. However, I cannot permanently change the Project Units to Feet because the project needs to be in Feet and Inches. I wonder if it is safe to assume that while the Project Units are Feet and Inches, the elevations I input in decimal feet are preserved with full accuracy. I'll try testing this a bit.
Keeping Project Units as Feet and Fractional Inches doesn't affect the actual dimension value. Below is a measurement in AutoCAD.
Great. That is the expected behavior. I guess my verification in Grasshopper is picking up an error from a different source.
Thank you for your time evaluating my problem.
I've observed that entering values like you shared in your post are displayed as you describe when the Project Units are set to a different unit format. I also find that Revit does not report the same rounded value that I enter initially when I changed the Project Units back and forth. The fractional value that is reported is converted to a decimal value with greater precision than the value I entered.
As such, when dealing with shared coordinates, I always change the Project Units to match those that I am entering explicitly. Then I return the Project Units to the original setting. I find that doing so will Revit report the original decimal value I entered when/if I switch the units back and forth between formats.
My experience is based on entering coordinates using the Specify Coordinates at Point (SCaP) tool versus using the Acquire Coordinates tool. I've never seen a change in the values using Acquire Coordinates. Entering values into the Project Base Point or Survey Point icons is accessing the same data that SCaP provides. I haven't tested this out in Revit 2024 yet. I'd be interested to learn if your Grasshopper values match the original input value if you take the steps I do when entering these values.
Steve Stafford
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Thank you for your detailed and technical reply. This is very useful information, re: the order of operations. I will test this myself.
I will post the results of my Grasshopper values in relation to this order of operations test.
Your tip was very productive. In short, setting the Project Units to Feet (decimal feet) with sufficient decimal places in a Custom Rounding Increment, then inputting my elevations in Survey Point and Project Base Point, resulted in a resolution of the errors being reported in Grasshopper. Below I have documented my tests in great detail.
By the way, for a discussion of my Grasshopper process, a separate issue which brought this Revit issue to my attention, see this forum post.
Equalities are True now--numbers all match
Grasshopper still retrieving values in decimal feet which is unexpected after switching to Feet and Inches. This suggests that the Feet and Inches Project Unit schema is more superficial than the Feet Project Unit schema. Something to test further.
Thanks for the details. Very thorough. I don't specify any custom rounding beyond 6 decimal places. While Revit stores values as doubles which supports up to 12 decimal places I've been told in the past that Revit doesn't really deal with anything beyond 6 decimal places.
Your observation seems to be inline with my own, the process of converting units and the rounding that occurs changing from Decimal Feet to Feet and Inches is destructive, as you put it. The conversion back to Decimal Feet from Feet and Inches is resolving the fractional value and imposing a new more accurate conversion from the fractional value. When we change the project units to match the input value including decimal places Revit seems willing to store and maintain that value and the rounding that occurs to display the fractional value does not alter the original input value.
When dealing with more than 3 decimal places it may be far too subtle to matter in reality (unless the model is very far from the origin too, which we should not do) but at least you have a process that can provide a predictable result.
Steve Stafford
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
Re: conversion and rounding
I agree with your analysis. I am still unclear on what format Revit is actually storing the elevation data in. Would be nice to look inside that database. I know that Revit defines everything in relation to metric. But it also seems that Feet is more central to its thinking than Feet and Inches, based on my Grasshopper reporting in decimal feet even when I switch the Project Units to Feet and Inches.
Re: decimal places
Yes, more than 6 decimal places is functionally unnecessary. Here's a little background, which is probably much to much detail for you. In fact, the survey benchmark inherited from the surveyor is 2818.09', so two decimal places is sufficient. However, because of an existing house being related via stairs to an addition a few vertical yards down the hill, the Project Base Point (which sits at the top of bottom sill of the addition) happens to end up 7.303641' below the Survey Point. So when I input the Project Base Point elevation value (7.303641' less than 2818.09', or 2810.786359', that's when I ran into the need for a custom rounding to 6 decimal places. And because I am working in between Rhino and Revit, I can't let Revit simplify that Project Base Point elevation value, or it won't be identical with it's counterpart value in my Rhino coordinate system.
Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.