Parcel area rounding

[leahs6ALC9]

I've been wondering for a while now why truncate rounding sometimes results in lots with areas that are a whole number (e.g. 450m2) showing as having an area of one below that whole number (e.g. 449m2). What I've discovered is that parcelled areas reflect the whole number when all linework is orthogonal to the poles (on the right in image below), but once that linework is rotated away from the poles, the area calculation appears to become less accurate (on the left).

I've attached a DWG. It contains two areas of parcelled lots - one near the origin (0,0) and one in the region of my coordinate system. Both sets of lots display the rotation error. I've also included some example lots showing the difference between normal and truncate rounding (with those problematic 449m2 lots displaying in the truncate option). Regarding the hatch area error, setting the origin closer to the hatch doesn't appear to rectify the issue. 

For subdivision lots, we round down to the nearest whole number meaning that 450.2m2 and 450.8m2 are both displayed as 450m2 (the reasoning being that it's always better to tell people that they have less land than more). Truncate rounding is thus the ideal rounding to use, but this rotation error means that areas such as 449.99999998m2 are rounding down to 449m2.

My current workaround is normal rounding to 1 decimal place and after exporting, using the Find and Replace command to replace that single decimal with 'm' (e.g. 450.1m2 - ".1m" replaced with "m" - becomes 450m2).

My questions regarding the error:

- If not already done, is this something that I should raise with Autodesk? Could they address it or is it unrealistic to expect better accuracy?

- Does anyone know of a better workaround then my 1 decimal place option? It works fine, but I'm certainly open to quicker and/or more efficient alternatives.

[matt_anderson_pe]

Yes, report it.   I find it interesting that in two completely different manners of calculating area - you have two different areas.   While it's likely attributable to two different development teams (AutoCAD team vs. C3D team) using two different methods - it's something that shouldn't happen in the same application.

[Kevin.Spear]

Interesting... A few things come to mind. Is this in your template or the out-of-the-box template? I tried this with the imperial and my template but could not replicate the issue. If it's not your template, does fixing the drawing resolve this issue (audit)? 

As Matt suggests, this may be a bug after all. Maybe it's confined to metric units... who knows?

[MMcCall402]

In the mean time, what if you rounded the value to 5 or 6 decimal places to get beyond the slight inaccuracies of the different area calculation methods and then truncated the value.

[leahs6ALC9]

Mmm, yes, I thought it odd that the different methods are showing different results. Interesting point that it's likely the result of two different development teams. I'll report it.

@Kevin.Spear 

I started with a blank DWG file (in the sense of it being stripped back as far as possible without template specific items). That's interesting that you can't replicate the issue. What version of C3D do you have? On my end, the issue occurs in both 2022 and 2023.

I've attached an additional four DWG's to this post (I'll attach two in an additional post), each created from a different template (C3D metric, C3D feet, ACAD metric, ACAD feet). The same error occurs in each of them, exactly the same values to 8 decimal places.

An audit on my original file doesn't pick up any errors.

@MMcCall402 

Apologies if it's a simple task, but how do you round and then truncate? I tried a few different decimal places using the truncate option, but they all show the same result (mixture of 449 and 450 areas). Perhaps I'm not doing it the way that you mean?

[leahs6ALC9]

The two additional DWG's

[andrewpuller3811]

You can round to a certain number of decimals by using an expression that rounds the number * 10 then divide that by 10. This gives you a rounding to 1 decimal place. Rounds the number * 100 then divide that by 100 to round to 2 decimal places - etc.

Attached is a modified version of your drawing that has the area rounded to 1 decimal then rounded to 0 decimals. In the case of your drawing it cleans up the rounding errors. It might need more decimals to guarantee the result you should normally get.

[leahs6ALC9]

Ahh, well that's interesting. Thanks. I'll give that a whirl. I had to explore the DWG a bit to understand what you did.

I must say that I'm a bit confused by the terminology: "rounds the number * 10 then divide that by 10. This gives you a rounding to 1 decimal place". Can you perhaps provide an example? I'm wondering whether it can be replicated with regular math. Using 10 as an example, I'm reading it as 10*10 = 100 and 100/10=10, which can't be right since it's not to 1 decimal place. 

Sorry if this is all really simple. I'm really not that familiar with expressions. It's on my list of things to improve on - both for use in CAD and GIS.

[rl_jackson]

I reviewed this post and after looking at the significant digits I've determined that we are building a rocket ship to Mars

[matt_anderson_pe]

In this case - the Parcel area results from Surveyor calculations vs. the CAD linework. 

If you label using C3D Parcel Labels and perform a MAPCHECK on the rotated - it finds a tiny error. 

The traverse around the parcel with eight significant figures will likely have a rotational error vs. AutoCADs object area calculations.

As for the truncation calculations - remember you can build your calculations in parts using the output to the left and right of decimal characters to construct the area value.

This way, you report Area to 1 sq m to the left of the decimal, then the decimal, and then the truncated decimal to the right.
Area : <[Parcel Area(Usq_m|P0|RN|AP|GC|UN|Sn|OF)]><[Parcel Area(Usq_m|P0|RN|AP|GC|UN|Sn|ODS)]><[Parcel Area(Usq_m|P3|RN|AP|GC|UN|Sn|ORD)]>

[MMcCall402]

Here's an example of an area expression to get around the parcel area inaccuracies.  It creates a new property for the parcel that Truncates a version of the parcel area that's been rounded to 6 decimal places.  First you make the new expression and then use it will be an available property in the label style composer.

[snoyola1]

@leahs6ALC9 

is related to the IEEE-754 standard

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_math.html#:~:text=IEEE%20754%20specifies%3A,and%20....

example

Truncating means removing the fractional part altogether, so either 3.4 or 3.6 results in 3.

litle tip.

I hope this Help

Simon Noyola

[snoyola1]

video tip

https://drive.autodesk.com/de29dd56a/shares/SH512d4QTec90decfa6ea2ccb14c6048727b

Simon Noyola

DDSCAD.com

[BrianHailey]

My best guess as to the cause of the error is in how computers handle numbers. When converted from decimal to binary, 0.1 is a repeating bicimal (that's the binary equivalent of decimal). 0.1 in decimal is 0.00011001100110011... in binary. Since computers can't store an infinite number of digits in memory, it must round the value of 0.1 when written in binary. If this value is then used in a computation, then very likely, the error will compound until you get something like what you're seeing here.

https://www.educative.io/answers/why-does-01-not-exist-in-floating-point 

[leahs6ALC9]

Ok. Thanks for all the replies. There’s a lot of info to process here.

It looks like we’ve currently got two possible explanations for the rotation error:

@matt_anderson_pe has suggested a rotational error in the traverse around the parcel.

@BrianHailey has suggested it could be due to rounding of the decimal number in binary.

@andrewpuller3811 and @MMcCall402 have both suggested using an expression as a better workaround than what I’ve been doing: TRUNC((ROUND({Parcel Area}*…/…)) (with “…” signifying different values depending on decimal places).

@matt_anderson_pe has also suggested using the Output part of the expression builder (I’m not familiar with Output, so thinking I’ll go with Andrew and Mark’s approach for now, but no harm in having multiple options!).

I’ve opened a support case with Autodesk to try and notify the development team of the situation. I’ll let you know what the outcome is. I think the suggested workarounds will improve on my current workflow, but it would be great to have it addressed on Autodesk’s end if that’s a possibility.

Thanks again. I’m still quite green in the field of drafting and it’s wonderful having access to such a supportive community.