Project Elevation in Decimal Feet - Survey Base Point

[brianorser]

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

[brianorser]

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)?

[ToanDN]

Chang project units to Feet.

[ToanDN]

---

@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.

[brianorser]

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.

[ToanDN]

---

@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.

[brianorser]

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.

[SteveKStafford · Accepted solution]

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.

[brianorser]

@SteveKStafford 

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.

[brianorser]

@SteveKStafford 

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.

Test 1

Set Project Units/Length to Feet and Inches (default rounding)

Enter Elevation (2818.09')  in Survey Point (unclipped)

Converts it to 2818' 1-5/64" in the Properties Panel report of Elev. parameter

Switch Project Units/Length to Feet (with Rounding of 2 decimal places)

Now Properties Panel reports 2818.090' 

Why is there a third decimal place?

Test 1.1

Set Project Units/Length to Feet and Inches (Rounding to 1/256th")

Enter Elevation (2818.09')  in Survey Point (unclipped)

Converts it to 2818' 1-5/64" in the Properties Panel report of Elev. parameter

Switch Project Units/Length to Feet (with Rounding of 0 decimal places)

Now Properties Panel reports 2818.090' 

The rounding doesn't seem to change the reported value

Test 2

Set Project Units/Length to Feet (Rounding of 2 decimal places)

Enter Elevation (2818.09') in Survey Point (unclipped)

Properties Panel reports: 2818.090'

Switch Project Units/Length to Feet and Inches

Properties Panel reports: 2818'  1 5/64"

Switch Project Units back to Feet

Properties Panel reports: 2818.090'

Test 2.1

Set Project Units/Length to Feet (Rounding of 0 decimal places)

Enter Elevation (2818.09') in Survey Point (unclipped)

Properties Panel reports: 2818.090'

Switch Project Units/Length to Feet and Inches (Rounding to 1/256th")

Properties Panel reports: 2818'  1 5/64"

Switch Project Units/Length to Feet and Inches (Rounding to 1/8th")

Properties Panel reports: 2818'  1 5/64"

Switch Project Units back to Feet

Properties Panel reports: 2818.090'

Test 3

New document

Change Base Point "Angle to True North" parameter to 8.70

Make a True North and Project North Floor Plan

Change Project Units to Feet  (Rounding of 2 decimal places)

Move Survey Point (using move tool, in Project North Plan) to the following coordinates, taken from the Survey Benchmark in Rhino and the Project Elevation:

x=19.692504' (clipped)

y=41.075122' (clipped)

z=2818.09' (unclipped)

Properties Panel reports Elevation= 2818.090'

Moved project base point to Z=2,810.786359'

Properties Panel reports elevation = 2810.786'

This is a reduction in decimal places, but not consistent with the Rounding of 2 decimal places, instead rounding to 3?

Further test: I now change the Project Units to Feet, Rounding (custom) with an increment of 0.00001

The Project Base Point elevation in Properties Panel reports as 2810.78600

Test 3.1

New document

Change Base Point "Angle to True North" parameter to 8.70

Make a True North and Project North Floor Plan

Change Project Units to Feet  **(Rounding (custom) with an increment of 0.00001)**

Move Survey Point (using move tool, in Project North Plan) to the following coordinates, taken from the Survey Benchmark in Rhino and the Project Elevation:

x=19.692504' (clipped)

y=41.075122' (clipped)

z=2818.09' (unclipped)

Properties Panel reports Elevation= 2818.09000

(Move scope boxes and levels so that Survey Point and Base Point are visible in Plan views)

Moved project base point to Z=2,810.786359'

Properties Panel reports elevation = 2810.78636'

This is a reduction in decimal places, consistent with the Rounding (custom)

Further test: I now change the Project Units to Feet, Rounding (custom) with an increment of 0.00000001

The Project Base Point elevation in Properties Panel reports as 2810.78636000

Conclusion: The rounding that happens in relation to the Project Units actually is destructive, appearing to permanently eliminate any decimal places outside the rounding

Therefore it is necessary to set the Project Units to an rounding accuracy required by the input data

Test 3.2

New document

Change Base Point "Angle to True North" parameter to 8.70

Make a True North and Project North Floor Plan

Change Project Units to Feet  **(Rounding (custom) with an increment of 0.000001)**

Move Survey Point (using move tool, in Project North Plan) to the following coordinates, taken from the Survey Benchmark in Rhino and the Project Elevation:

x=19.692504' (clipped)

y=41.075122' (clipped)

z=2818.09' (unclipped)

Properties Panel reports Elevation= 2818.090000

(Move scope boxes and levels so that Survey Point and Base Point are visible in Plan views)

Moved project base point to Z=2,810.786359'

Properties Panel reports elevation = 2810.786359

Run diagnostics with Rhino.Inside

Equalities are True now--numbers all match

Then switch Project Units back to Feet and Inches (rounding to the 1/64th")

Run diagnostics with Rhino.Inside

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.

[SteveKStafford]

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.

[brianorser]

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.