Specify Coordinates at Point is not accurate (SCaP)

[FG88]

Hi all,

I have a question regarding the Specify Coordinates at Point (SCaP) process and how I can't get it to be very accurate as opposed to Acquire Coordinate process. The issue I am running into is that although I input the precise coordinate bearings in the SCaP dialogue, Revit seems to round it up to some other numbers close to what I input but not 100% accurate. And the result of this action (round off) is that exports from Revit does not perfectly line up in CAD (if you were to compare this export to other CAD backgrounds). In other words you never get the right coordinates for any of the points in a model -at least not the same as what you get from a survey CAD file. Acquire Coordinate though seems to be working fine and very very accurate that any CAD exports out of Revit through this method would line up perfectly in CAD with survey files. How can I fix this issue?

P.S.#1: I adjusted Revit's unit precision decimal places but it still rounds off the number.
P.S.#2: One may say you would never get it 100% accurate identical to CAD data since CAD and Revit are using different coordinate systems etc. -I would argue against this since Acquire coordinate will work great.

Thanks in advance!

[Steve_Stafford]

How many decimal places are we talking about? I haven't observed this problem before and I've usually dealt with 6-8 decimal places. Ironically, I've seen Acquire Coordinates fail to work but it usually tracks back to a CAD file issue.

[FG88]

How many decimal places are we talking about? I haven't observed this problem before and I've usually dealt with 6-8 decimal places. Ironically, I've seen Acquire Coordinates fail to work but it usually tracks back to a CAD file issue.

Steve: I am using 8 decimal places, if not more. To ensure that CAD reading is accurate, I increased the decimal places there too to get a more accurate reading. So now both Revit and CAD are set to decimal inches with almost 8 decimal places. Inputting CAD readings will get rounded off in Revit for some reason. Funny but obvious thing that happens is that close to the point where you specify the coordinate at, the reading is very little off, but as you go further away from that point the reading becomes more and more inaccurate with a more significant difference. Let's say it's 9/256" off at specified point and gets to >1" when going 1 mile further than that point. Crazy!

[Steve_Stafford]

How are you measuring inaccuracy?

Acquire Coordinates moves the clipped Survey Point to mark the location of the WCS origin in a source DWG file you have linked. Regardless of how you place the DWG Revit now acknowledges this location as the relevent origin of survey data and for Revit's own Shared Coordinate System.

By comparison, Specify Coordinates at Point (SCaP) makes that a manual step and it is entirely dependent on our ability to pick the exact location in the survey data that we want to use as a reference. You could mimic Acquire Coordinates if there is something in the DWG marking the origin so you can move the survey point there yourself, or use SCaP and pick the location.

At eight decimal places I'd expect it to work. I much more suspicious of the accuracy of the coordinate information being used. How is it determined, by opening the DWG file and listing the properties of something in the model? If you are getting a message about the file having extents greater than 20 miles when you link the DWG than that is probably affecting Revit's ability to snap accurately when using SCaP.

Fwiw, I have a survey DWG that has benchmark blocks. They have a small circle and crossing lines to mark the "center" of the block so that marks the relevent coordinate location for a benchmark. Looks good except the circle isn't at the center really, it is off by something like 0.002 inches. The circle and lines are not exactly at the origin of the block either. It drove me crazy when I picked it with SCaP and kept getting a subtle discrepancy.

[FG88]

Steve,

Thanks for following up! Agreed on Acquire coordinates and on its reliability for aligning Revit's coordinates system with CAD's. The way I measure the inaccuracy is to export the positioned CAD to dwg and xref the original file to find out if the export is still the same as the original cad survey file. I simply dimension the difference.

Mimicking Acquire coordinates through the use of SCaP is exactly what I'm after. Regarding the accuracy of the information being used: Since I'm not relying on the annotative text in survey file, I place a point on a known point in CAD and read the bearings with 8 decimal places. Then I use those readings to input the coordinates when SCaP. Regarding how I SCaP, I snap to the point that I read the coordinates in CAD from.

I'm not getting 20 mile radius warning at all. Just to reiterate, at the point where I SCaP the discrepancy is subtle, but as you go further away it becomes larger and larger. What is throwing me off is that AC is working accurate but SCaP is not for exactly the same CAD background. I open two Revit instances and SCaP in one and AC in the other. The AC coordinate reading is identical to CAD but SCaP readings are rounded off. So I conclude that the file is a non-issue since AC works fine with it. Drives me crazy. I input a number but it rounds it off immediately.

[Steve_Stafford]

It may not be obvious, we don't have to pick an existing element in the DWG to use SCaP. We can place our own marker in the file at an easier coordinate value to rely on. Since Acquire Coordinates moves the Shared Coordinate system origin to align with the DWG's WCS origin (World Coordinate System) we could place a marker at the DWG origin ourselves to use SCaP. It is ill advise to do that though because at worst it will cause the 20 mile threshold warning or at best it will result in large extents to deal with when using zoom features.

If a benchmark or building corner (the spot we want to mark) has coordinates like 125,500.0456100, 101,678.550055010 then we can place our own marker nearby at round numbers like 125,500.000,101,678.000. Try that and then test it using both techniques and see if you find the discrepancy eliminated.

It is possible that the coordinate has more decimal places of "accuracy" than the eight you are using. For example it might be a situation like this 125,500.98070000005. The appearance of something other than zero further than 8 decimal places is a really tiny distance but if you check distances far enough away, very very far away, eventually you'll track a discrepancy.

If you can share the DWG file with me I'd be curious to experiment with it, via Steve at aecadvantage dot com.

[FG88]

Steve,

It eventually worked. CAD export lands perfectly in place when exported to CAD and measured against the original survey file.

Lessons learned:
It's funny how I tried a round coordinate in full feet before and it didn't work. What I was doing wrong previously was that upon inserting the survey file into Revit, I used to drop a model line using the pick line tool to be able to snap to one end of the line. And I am assuming that pick lining was not the most accurate thing to do although it was trying to capture an easy coordinate. This time, per your recommendation, I marked a clean point with easy coordinates in full feet (again) set to 8 decimal places i.e. 1257885.00000000 and put a circle with some crossing lines passing through the center. All I needed to do in Revit was to SCaP at that point, but this time with no model line and pick lining. I let Revit to snap to the CAD element not a Revit native element. And it's funny I didn't see this before when SCaP, you could start SCaP and TAB through the know CAD spot until it highlights the marked POINT for you. Once you see that point highlighted, click and boom! To double check myself, I threw in a ton of SPOT COORDINATES (under Annotate) and measured against CAD coordinates. It was perfect. Using the POINT command in CAD was very useful and safe for reading the coordinates.

My understanding is that CAD is not able to give you more that 8 decimal places of precision while Revit is able to go beyond that. And that could have been one reason for not getting the right coordinates. And of course, try to snap to a CAD native point not a Revit native point.

Make sure you set both Revit and CAD to most precise units before starting this process.

Thanks again Steve for taking the time to help with this! Great tips!

[Steve_Stafford]

Glad you got it worked out!

Yes the pick line tool is vulnerable since it is a command written to select and interpret something in another file to create a local element in Revit. I've heard from various people that they've run into issues with the Pick option before. I haven't but then I don't really use it much either. The snapping to define the point that SCaP uses IS critical and what has usually been the source of the problem for me and others I've helped in the past too.

It is my understanding that Revit (and I believe AutoCAD too) stores values in what they call Double Precision which is roughly 15-16 decimal places of accuracy. In imperial units Revit stops displaying units at 1/256" and custom rounding with decimal values allows for at least the appearance of greater resolution.

I do preset the rounding to match what the decimal precision of the point I'm trying to mark with is...more so I can see the same numbers without rounding. It's been my experience that entering the exact value will be respected despite few decimal places of rounding being in play; the point knows where it really is.

[FG88]

Yes! what you mentioned is exactly what I was understanding form the procedure but didn't know the corresponding coding infrastructure for such a function! Revit and CAD stop reporting their true coordinates after 8 decimal places and store it somewhere else that is not readily available to users and that causes a very subtle discrepancy for certain points. From a software development standpoint I don't understand why they don't report the whole thing, but your workaround (mark easy coordinates) becomes essential when dealing with crazy coordinate bearings.

Thanks for providing some insight on coding side of the SCaP as it is crucial to better understand the process and outcomes.