Large Coordinate Issue and Point Clouds

[Steve_Bennett]

I am absolutely amazed that I could not find any threads regarding this issue anywhere on AUGI (either that or once again I suck at searching). There are some posts on Shaan Hurley's blog and an article in cadalyst, but nothing here. I may even be posting this in the wrong forum, but what I'm about to describe cover 4 or possibly more different industries - general CAD, Surveying, 3D Modeling, possibly manufacturing, CSI and as built models/renovations - all rolled into one task.

Here's the deal. Using a 3D laser scanning device such as Faro or Leica a user builds what's called a point cloud that has millions of data points that represent actual coordinates of all desired geometry. These points need to be tied in with some sort of geographic location such as NAD or somewhere in the GPS grid. When that is done and the geometry imported into cad, the point cloud is typically millions of units away from 0,0 due to each region of the NAD having one common point. Millions of units generally translates into hundreds of miles which is a LONG ways away from 0,0. The point clouds can be used to build all sorts of data - terrain, buildings, tunnels, crash scenes from auto accidents (including the wrecked vehicals).

When geometry is located that far from 0,0 - things start to happen - strange things I might add. Commands stop working properly on obects, things display wrong in 3D - even vertical apps built on top of AutoCAD such as ADT start displaying things incorrectly. To start with, Shaan has made a few posts on his blog that discuss this. Post 1, post 2, post 3. Reading these posts are essential to understanding what the problem is when you have geometry far away from 0,0.

Shaan's article uses the drawing of the solar system that many of you may remember from the older days of AutoCAD. You can draw the solar system to scale, but you run into problems when you try to draw a lander on pluto to scale due to the limit of digits that the computer can use. Currently that is 16 digits total and that does not mean 16 on each side of a decimal point. 16 total means you can have 10000000.00000001 or 1.000000000000001 or 100000000000000.1 as a number. When dealing with coordinates in the millions, you run out of decimal places real quick and that is what cause things to stop working when far away from 0,0.

Also, there is a lovely article on Cadalyst that discusses this in depth too. This article describes some lovely workarounds for dealing with this situation.

My question is, what can be done if the user cannot move the data near 0,0? They cannot reregister the point cloud closer to 0,0 as that would be far too time consuming and they cannot move the point cloud near 0,0 as that "could" cause rounding errors.

[jaberwok]

The obvious answer seems to be to create a UCS near to the objects of interest.
Too easy and too obvious to work?

[Steve_Bennett]

The obvious answer seems to be to create a UCS near to the objects of interest.
Too easy and too obvious to work?

That is just a band aid and issues contiune to persist. You haven't changed the fact that you have moved the UCS to an alternate location 100's of miles from where it used to be. The numbers are still there.

[Lemons]

That is just a band aid and issues contiune to persist. You haven't changed the fact that you have moved the UCS to an alternate location 100's of miles from where it used to be. The numbers are still there.

Have you tried messing with the units? I see that insert units can go as big as parsecs.

[jaberwok]

Mathematically, what is the difference between moving the objects closer to the origin and creating a closer UCS (moving the origin closer to the objects)?
If you create the new origin by TYPING a new coordinate value that ends with several zeros rounding shouldn't occur.

For others - Shaan Hurley was mistaken when he referred to John Walker's drawing "of the universe"; it was a drawing of the solar system as correctly mentioned later in the article.

[Maverick91]

That is just a band aid and issues contiune to persist. You haven't changed the fact that you have moved the UCS to an alternate location 100's of miles from where it used to be. The numbers are still there.

When a building is built, it's usually tied to a few temporary benchmarks on site, instead of directly to the state plane coords. Those benchmarks were probably pulled from county or maybe state BMs. By doing this, the builders "move the UCS" instead of tying back to the universe.

Your lunar lander's footpad could be 2 meters from the cabin, which is some kilometers from the center of the moon, which is some distance from Earth, some distance to the sun, some distance to the Milky Way.

Granted, a bust in the survey makes for an interesting day. But it's not very often I want to know how far this mouse is to Alpha Centauri.

[Steve_Bennett]

Have you tried messing with the units? I see that insert units can go as big as parsecs.

An application that is not designed by Autodesk exports the point clouds and creates a dwg file. I have no idea if the external app has control over the units setting.

[Steve_Bennett]

Mathematically, what is the difference between moving the objects closer to the origin and creating a closer UCS (moving the origin closer to the objects)?
If you create the new origin by TYPING a new coordinate value that ends with several zeros rounding shouldn't occur.

As I mentioned ealier, it's only a band aid. One of those articles I linked to discusses the same thing. Doing so creates either the same problem or others. It still has to keep track of where the original 0,0 is. So in effect, even though you've created a new ucs closer to the points it still has a huge coordinate system to keep track of.

[Steve_Bennett]

When a building is built, it's usually tied to a few temporary benchmarks on site, instead of directly to the state plane coords. Those benchmarks were probably pulled from county or maybe state BMs. By doing this, the builders "move the UCS" instead of tying back to the universe.

In this particular case they survey existing buildings and tied to the NAD83 system for the corresponding zone in California. The base point resides in the pacific ocean. If he had known about this issue in advance, he would have generated the points closer to 0,0 instead of 100's of miles away.

[Opie]

How accurate does one have to be when they survey an existing building? The usual decimals I have seen displayed on an As-Built survey is two decimals.

What are the units specified as?