Percent Error and Area
November 17th, 2008I just had a realization about the area error (”+/- X acres”) that I’ve been computing. The way it is currently calculated is very simple. Take the perimeter error percentage (also displayed in the results), multiply that by the computed area, and voila. A simple way of expressing the potential error of the calculated area. If your closure is 10% of the perimeter (now that I think of it, there are two ways of thinking about the perimeter; inputted perimeter (total distance of all deed calls inputted) and final perimeter (including any computed closure); the current implementation is the first way, which in one sense is correct, but in another sense overstates the percent error; I guess it’s better to err on the safe side and call the error bigger than it might actually be) (sorry for all the parenthesis folks, this is just how programmers think) then the area +/- is 10% of the calculated area. Simple, no? Perhaps too simple.
One of the first things you learn in geometry is that area is proportional to the square of linear distance. The perimeter is a linear distance; the area is proportional to the square of the perimeter, therefore the calculated area error should be proportional to the square of the perimeter area. As soon as I think of a way of implementing this without going completely nuts with the acreage error, I will fix it.
By the way, my reason for including this figure at all is just to draw the your attention to the fact that you have a problem of some severity with your plot. Competing products (*ahem, GGDP*) will just adjust the calculated acreage, based on the error, and never inform you of that fact. So if you input a square tract 200ft on a side, you will get 40,000 sf; but if you make an “error” and make one of the sides 205ft instead of 200, GGDP will tell you that the actual acreage is MORE than 40,000 sf! I know that a lot of sophisticated analysis probably went into solving this problem in GGDP, but in my opinion this is the wrong way to go, and in fact it is a fairly ludicrous proposition. I would rather leave that sort of judgment call to the user instead of having a one-size-fits-all calculated solution. If the plot doesn’t close properly, the user can decide whether the acreage is right or not, and whether it should be adjusted up or down, or even whether the deed calls themselves should be altered to fix the problem (I know we have all come across transposed digits, missing digits, or otherwise mutilated deed calls). I would rather give the “right” acreage, based on the input data, than include a “fudge factor” that in no way should be taken for gospel.
By the way, another thing that I do in terms of stating the error is truncate the number of significant digits in the acreage results. If there is an error of > 10%, you only get 2 significant digits; 1% - 10%, 3; 0.1% - 1%, 4; and <0.1%, 5 significant digits. This is just another kind of a “seat of the pants” error detection that I have included. So if your tract doesn’t close by 20%, Tract Plotter is not going to tell you that it’s 42.385 acres. It’s going to be 42, and even that is probably too generously precise, but I find less than 2 significant digits to be pretty worthless. On the other end of the curve, more than 5 SD’s is probably better than any surveyor could ever trust his instruments. But, as always, I leave the final decision up to you, as you can always see the full calculated value, out to as many SD’s as the computer can handle, by clicking on the “Show Full Precision” checkbox.
I definitely want to improve this significant digit algorithm in future versions, taking into account the precision of all entered data. But, for now, I think it serves its purpose, and I hope that you find it useful.