Mismatch Between Revit Survey Point Rhino Survey Benchmark Point

[brianorser (Brian)]

Hello

I am building a Rhino.Inside.Revit workflow, and I am currently setting up a system for establishing reliable connection between Rhino coordinate system and Revit coordinate system.

Specifically, in Rhino we have our Project Base Point at the Origin, and a Survey Benchmark, from a CAD survey, positioned three-dimensionally in relation to the Project Base Point. The Rhino file is Project North orientation, and does not take into account real world elevations (elevation of Project Base Point is 0).

In Revit, the Project Base Point is set to X=0,Y=0, Z=2,810.786359’. I then modified the “Angle to True North” parameter to 8.70 degrees. The Survey Base Point was then moved (using Move tool, while Survey Point was clipped) in relation to the Project Base Point to X=19.692504’, Y=41.075122’. Then, while Survey Point was unclipped, I changed the Project Elevation parameter of the Survey Point to 2818.09’ (the real world elevation of the Survey Benchmark).

To verify that the Revit Survey Base Point and Project Base Point are in the correct position relative to each other and to their counterparts in Rhino, and to test my Plane to Plane transformation of Rhino geometry into Revit, I created a diagnostic system in Grasshopper seen in this screenshot:

In this screenshot you can see the points I am sending back and forth from Rhino and Revit to ensure they have the same relative positions:

The diagnostic shows that there is a minor difference in the Z-coordinate of the Revit Survey Point. The Z-coordinate difference in Rhino between the Survey Benchmark and the Project Base Point (Origin) is 7.303641’. However, in the Revit model the Z-coordinate difference between the Survey Point and the Project Base Point is 7.303385’.

My theory is that this has to do with a built-in rounding-up in Revit. I input the X, Y coordinates and Project elevation of the Revit Survey Base Point and the Z coordinate of the Revit Project Base Point in decimal feet as this is the native format of the Surveyor’s numbers, and it is more accurate than fractional inches. However, I notice that Revit accepts input in decimal feet but immediately converts it to Feet and Inches (fractional). I originally assumed this conversion was graphical (for display only) and that Revit was storing more decimal places of the input number. However, the error I have found suggests that this is not true.

What should I be doing differently?

Thank you very much for your help on this fundamental part of the build.

Brian

[brianorser (Brian)]

In a similar way, we can see a slight error in the readout of the Project Base Point coordinates, from the Project Elevation component. This component is giving Project Elevation=2810.786458 whereas, as previously stated, what I input into the Project Elevation parameter of the Revit Project Base Point was 2,810.786359’.

[Japhy]

Hi Brian,

I’ll take a look at your basepoint comparisons later today.

Doing equalities on floats through text panels is hardly ever “True”

@brianorser

In a similar way, we can see a slight error in the readout of the Project Base Point coordinates, from the Project Elevation component. This component is giving Project Elevation=2810.786458 whereas, as previously stated, what I input into the Project Elevation parameter of the Revit Project Base Point was 2,810.786359’.

Integer-floating point automation

The panel tells each data item to format itself however it sees fit. For floating point numbers that means it will use the formatting options set in the preferences. These options touch upon rounding, special casing integers and multiples of pi, and when to switch from decimal to scientific notation. If you want to see what a floating point number is really like, then you must use the Format component with the pattern "{0:R}". The R stands for roundtrip meaning no information is lost while for…

[brianorser (Brian)]

Hi @japhy

That is very good info–I thought something like this might be at play. What is the correct way for me to confirm that the datapoints in Rhino are the same as the data points in Revit?

To summarize, I am trying to verify an equality between a) the Z-coordinate difference between Revit Survey Point and Revit Project Basepoint and b) the Z-coordinate difference between Rhino Survey Benchmark point and Rhino project basepoint, aka origin)

Thanks for taking a look. Let me know if you need my files, I could email them.

Best

Brian

[Japhy]

@brianorser

In Revit, the Project Base Point is set to X=0,Y=0, Z=2,810.786359’. I then modified the “Angle to True North” parameter to 8.70 degrees. The Survey Base Point was then moved (using Move tool, while Survey Point was clipped) in relation to the Project Base Point to X=19.692504’, Y=41.075122’. Then, while Survey Point was unclipped, I changed the Project Elevation parameter of the Survey Point to 2818.09’ (the real world elevation of the Survey Benchmark).

@brianorser

a) the Z-coordinate difference between Revit Survey Point and Revit Project Basepoint and b) the Z-coordinate difference between Rhino Survey Benchmark point and Rhino project basepoint, aka origin)

Can you provide a small sample of your setup? Thanks

[brianorser (Brian)]

@japhy

I seem to have resolved the problem, in Revit. I have attached the project files here with the fix. In this screenshot, you will see I have achieved the desired equalities:

As an aside, please do tell me the correct way to do equalities on floats, if not through text panels. Do I just eliminate the panel and send the data directly to the Equality component?

It seems the problem was in fact the result of destructive (i.e. permanent) rounding done by Revit on the input elevation numbers. This permanent rounding is a function of the Project Units. I have documented my testing of this problem at this Revit Architecture Forum post (Solved: Project Elevation in Decimal Feet - Survey Base Point - Autodesk Community).

At the suggestion of @SteveKStafford, in his response to my thread, I explored a solution: setting project units to Feet (decimal feet) with the necessary number of decimal places in the rounding, prior to inputting the Survey Point and Base Point elevations in decimal feet. Then, it is possible to switch back to Feet and Inches (fractional). This causes the elevation reported by the Properties Panel for the Survey Point to be rounded into fractional inches, but it seems that this rounding is non-destructive (temporary) and can be reversed by returning the Project Units to Feet (decimal feet). Actually, even if I leave the Project Units as Feet and Inches, the Project Location Rhino.Inside module is reporting the correct decimal feet elevation for the Survey and Project Base Points.

So, it seems that if the Elevation parameter inputs of the Revit Survey Point and Project Base Point do not match the Project Units, including the Rounding Increment, then that input is permanently (destructively) rounded up or down to match the structure of the Project Units. However, after the input has been made, changing the Project Units, and changing the Rounding Increment of the Project Units, does not seem to destructively modify the Elevation parameter value of the Revit Survey Point and Project Base Point. It seems possible to change Project Units and Rounding Increment back and forth with no effect on the values, as documented in my Revit Architecture Forum post, linked above.

The one piece I am unsure about now is why if I change the Project Units to Feet and Inches after inputting the elevation parameter, the Project Location Rhino.Inside grasshopper module is reporting in decimal feet. This suggests that the Feet and Inches Project Unit schema is more superficial than the Feet Project Unit schema. Something to test further.

[brianorser (Brian)]

23 0818 Elevation Units Testing.3dm (1.6 MB)
23 0818 Elevation Units Testing.gh (13.4 KB)
@japhy Can’t seem to upload a Revit file here (says it exceeds a max attachment size of 20mb) but happy to email it to you. Here is a WeTransfer for the time being: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free

[Japhy]

Thanks for the great info, I didn’t realize that there was rounding on the Revit side in this scenario.

[brianorser (Brian)]

Happy to contribute something.

[woodhouse]

@brianorser thanks for your work on this - I’m setting up a similar utility for comparing between Rhino and Revit model origins, and this is a great starting point. Thanks for working through this, and for sharing the definition!

[brianorser (Brian)]

Happy to help @woodhouse Please tell me what you learn

[Japhy]

@brianorser

As an aside, please do tell me the correct way to do equalities on floats, if not through text panels. Do I just eliminate the panel and send the data directly to the Equality component?

Correct, the cardinal sin here is casting to Text (panel)

To get the Real number you can use format like so…

Re_Format_RealNumber.gh (8.0 KB)

[Craig_L]

Hi, I also often have to take some time to try to work out these coordinates issues, especially when trying to bring in mesh, because Rhino doesnt like making calculations a long way from zero, and so it will give weird results in Revit sometimes.

I use the following nodes and I find its better because it gets the actual parameters straight from revit. getting the points as you showed earlier I remember gave me some odd returns and so we came up with this method.

it also just lets me switch to a different point depending on what suits me at the time by just switching the top left node element inputs.