This topic is more for us eastern guys who aren't working with thousands of acres but small subdivision lots of an acre or two. Using today's software based on a coordinate file we come up with a nice neat printout with an area in both square feet and acres. We all perform a closure check around each lot using the bearing and distance on the plan as drafted. Often the final area from the check is slightly different from the coordinate file area.
Which area to you publish on the plan and why?
The Hack
I only publish what I measure, or compute from my measurements.?ÿ I cannot, ethically, use someone else's work and pass it along as my own.?ÿ Normally any differences are small enough that it makes no appreciable difference, but the work is mine.
Andy
I use the one from the inverse around the mathematically perfect lot.
The map check is just a check.
I use my polyline around the lot, there may be tiny differences in a rounding area when you punch in the numbers for a closure report.
What the calls in the survey report calculate and shown as no more than 3 decimal places.
Area is the least concern when it does not relate to the location and limits of the property.
I'm using Carlson, I use the polyline report, but I do check it with the AutoCad list command, I do not believe I would get any difference if I assigned points or used the recovered monuments in the coordinate file since I am just snapping to the nodes in cad. Are you using 2 different softwares. Entering bearings and distances off the plat gives you a difference due to rounding, I prefer the polyline data.?ÿ
I don't know what version you use, but see Terry Dotson's post in an Autodesk forum that addresses the AutoCAD polyline area error.?ÿ I don't know if it's still an issue in later releases, but I'd be cautious.
Thanks all. I was speaking of the rounding error inherent in publishing distances to 0.01 and bearings to the second while the calc is infinitesimal.?ÿ Just curious. Seems most people do what we do here but I've heard agrument to the contrary.
?ÿ
Hack
?ÿ
I see what you're saying there.?ÿ I'm not worried about the small difference between the inverses of my coordinates and someone else's calc area, based on running in my plan distances.?ÿ
I usually make sure that new lots aren't hitting the SF to the exact minimum.
I have never run into this problem because I would never report an acerage to a precision that a few 1/1000th of a foot would make a difference.?ÿ
I have never run into this problem because I would never report an acerage to a precision that a few 1/1000th of a foot would make a difference.?ÿ
It's not necessarily that.?ÿ But I've run in some lots that were platted at the 40,000 SF minimum, and using the plan/plat B-D, the lot came out to be 39,999.45 SF, or something like that.
I have never run into this problem because I would never report an acerage to a precision that a few 1/1000th of a foot would make a difference.?ÿ
It's not necessarily that.?ÿ But I've run in some lots that were platted at the 40,000 SF minimum, and using the plan/plat B-D, the lot came out to be 39,999.45 SF, or something like that.
Reporting to the nearest square foot exceedes the appropriate precision for almost all boundary surveys, so 40,000 sqft seems like the right way to report this.
I have never run into this problem because I would never report an acerage to a precision that a few 1/1000th of a foot would make a difference.?ÿ
It's not necessarily that.?ÿ But I've run in some lots that were platted at the 40,000 SF minimum, and using the plan/plat B-D, the lot came out to be 39,999.45 SF, or something like that.
Reporting to the nearest square foot exceedes the appropriate precision for almost all boundary surveys, so 40,000 sqft seems like the right way to report this.
Strictly speaking, reporting 40,000 sf is ambiguous.?ÿ It could be interpreted as having only 1 significant figure, with the true value ranging from 39,500 sf to 40,499 sf.?ÿ From wiki:
- The significance of trailing zeros in a number not containing a decimal point can be ambiguous. For example, it may not always be clear if a number like 1300 is precise to the nearest unit (and just happens coincidentally to be an exact multiple of a hundred) or if it is only shown to the nearest hundred due to rounding or uncertainty. Many conventions exist to address this issue:
-
- Less often, using a closely related convention, the last significant figure of a number may be?ÿunderlined; for example, "2000" has two significant figures.
-
- A decimal point may be placed after the number; for example "100." indicates specifically that three significant figures are meant.
Hypothetically if you can field measure the the lengths of the sides of a perfect 200' square lot with an accuracy of ?ñ0.02'?ÿ the true area could range from 39,992 sf to 40,008 sf?ÿ so you could use the underline convention thusly 40,000 sf,?ÿ or precisely express the area as 40,000 sf?ÿ?ñ 8 sf, or 40,000 sf?ÿ?ñ 0.02%.?ÿ Similarly the mapcheck (which is?ÿ the numbers printed on the map), of a square 200.00' lot has an area of 40,000?ÿ?ñ 2 sf.?ÿ?ÿ
Don't try this at home or you'll send various real estate agents, lawyers, title company officers and planning departments into a tizzy ? .
?ÿ
I usually make sure that new lots aren't hitting the SF to the exact minimum.
Really??ÿ In large subdivisions where interior lots are rectilinear polygons, say exactly 50.00000...'x 100.00000...' as laid out in CAD I'll report 'em all at the exact permitted minimum, 5,000. sf, even 5,000.00 sf if some planchecker has a stick up his/her butt.
Irregular polygon lots, especially ones with curves in the boundary, yea, I'll lay 'em out to be a few square feet fat just to save computation time.?ÿ But not much more; when I was starting out I had developers bitch if many lots were significantly fat; they said it creates a perceived difference in value amongst the lots, and in a big subdivision if there's too many fat lots the developer will add up the overage and demand the layout be rejiggered to squeeze in one more lot,?ÿ pure profit for him/her.
The AutoCAD area bug existed in versions 2011, 2012, and 2013 (scary I know).?ÿ It occurred when polyline segments followed the same points as previous points in the polyline.?ÿ In other words if exploded it would create two lines on top of each other considered duplicate except their direction.
