0 Members and 1 Guest are viewing this topic.

#### MikeJarosz

• Guest
« on: June 27, 2008, 03:24:03 PM »
I posted this on AUGI and didn't get much response. Anyone here have an insight into my problem?

I am working on an airport project owned and managed by a government authority that has many facilities in the metropolitan area. They understandably want all their files to have a common origin point. Given the size of the local region, this involves some very large numbers. Complicating the issue, they maintain their database in engineering units, IE decimals of a foot. We all know that what this really means in Acad terms is decimals of an inch. But as architects, we use feet and inches. Switching from one system to the other repeatedly without introducing cumulative rounding errors is a nightmare.

If that's not enough, there's more. The original CAD data was drawn to an origin point the agency has decided to abandon in favor of NAD83. This means the data needs to be translated one time only over 180 MILES from point A to point B!!!!!

My approach is to write a VBA program that uses the old insertion point, the translate from point, translate to point and the final resting point, scaling up and down by 12 and 1/12 as needed. All numbers are captured to the maximum in double precision. I am well aware of the intricacies of floating point arithmetic. I'm beginning to wonder if I have found the limits of Acad units.

Once the data is translated to the final resting place in decimals of a foot the coordinates are 1044943.91129001,173435.132338795,0 in engineering units. I then have to scale this engineering data up by 12, change the units and move the data to1044943'-10.935480132",17345'-1.58806554",0.0000. After I move the data to these coords and list the result I get X = 1.2539E+07 Y = 17345'-1 9/16" Z = 0'-0" The x is in inches and the y is in FTIN.

Can anyone explain what is going on here? Interestingly, VBA seems to handle large numbers better than the Acad application does.

Did I mention the rotation? It's -28d58'6.4289"

#### rogue

• Guest
##### Re: Acad & VBA precision
« Reply #1 on: June 27, 2008, 05:29:12 PM »
>>Once the data is translated to the final resting place in decimals of a foot the coordinates are 1044943.91129001,173435.132338795,0 in engineering units. I then have to scale this engineering data up by 12, change the units and move the data to1044943'-10.935480132",17345'-1.58806554",0.0000. After I move the data to these coords and list the result I get X = 1.2539E+07 Y = 17345'-1 9/16" Z = 0'-0" The x is in inches and the y is in FTIN.

>>Can anyone explain what is going on here?

What is it that you need explaining? You seem to have a pretty good handle on what your 'challenges' are. If you're familiar with floating point, then you understand what "1.2539E+07" is? If not, that is a rounded off version of the correct X Position - (1044943.91129001 * 12 = 12539326.93548012), which is 1.2539, with your decimal point shifted "E+" 7 digits to the left.

You're probably already seeing round off errors. Since you are stuck with a fixed amount of numeric characters to represent your locations, I would limit the back and forth between converting units. Every time you divide by 12, you are looking at the possibility of adding at LEAST another number to the RIGHT of the decimal point; and every time you multiply by 12, you are adding a character to the LEFT of the decimal point, which means knocking another one off  from the right....

For utmost precision, Id start off by converting everything to one type of unit. Id probably Multiply the smaller units, rather than divide the larger ones; you'll only add a single character to the left that way, but dividing can add mucho decimals to the right....

And I'd do all my transations last.

#### mjguzik

• Newt
• Posts: 30
##### Re: Acad & VBA precision
« Reply #2 on: June 28, 2008, 11:11:49 AM »
I would expect that the airport already has local survey control points established and reconciled to NAD83 seeing it was required back in the 90's.

As for changing the base from feet decimal to feet and inches.  It seems you would be introducing error rather than reducing error.  A drawing unit is a drawing unit. 10 feet is 10 units in a feet decimal system and 120 units in feet inches. AcGeTolerance class has default functions equalPoint and equalVector with tolerances set to 1.e-10.  By multiplying everything by twelve you would have equal points and vectors where they did not exist.  A drawing file is simply a database of vectors and points.

Besides most GIS, surveys and civil work is performed in decimal units.  0.01 feet is still 1/8" (+/-) and datums for benckmarks are set at 0.005 ft precision.  Providing a higher level of precision then the original data was obtained isn't going to provide more precise data.

Best regards,

MJG

#### MikeJarosz

• Guest
##### Re: Acad & VBA precision
« Reply #3 on: June 30, 2008, 04:22:37 PM »
I agree that changing units introduces error into calculations. The civil engineering drawings of existing conditions at the airport (fueling hydrants and a myriad of other utilities) are all in decimals of a foot. Building design, on the other hand, is in feet and inches. Because of the congested infrastructure of this airport, we will have to bridge some major service lines with our new building. Accuracy in clash detection is an issue here. To compare the architectural drawings with the engineering drawings will require one or the other be translated. As the project progresses, we will have coordination meetings, which will require overlays.

Maybe this is the place to lament Acad's whole treatment of units. It's not just engineering units either. We do lots of metric architectural work. There the scale factor is 25.4. I was trained that a physical object does not change size because of the ruler that is used to measure it. But that is just what Acad does. The whole process is a workaround the fact that Acad 1.0 never anticipated worldwide dominance and the need for world units.

Then there are programs like Revit that do all the conversions internally............