Area of the parts != Area of the whole

Question

My tables are polygon datasets stored in NAD83 (SRID=8265) and I have noticed that the sum of area calculations of a subdivided polygon do not equal the area of the original polygon.
I created a simple test case to confirm the results. I created a square polygon, 5 degrees by 5 degrees (-94,36, -89,36, -89,31, -94,31, -94,36), and the resulting area (in square miles) is 99455.7384. I then cut that polygon into 10 irregular pieces which, if they were unioned back together, would equal the original polygon exactly. If I calculate the area on these polygons and sum the area, the result is 99444.1878 (a difference of ~11.5 square miles). I have increased the precision of the area fields to rule out problems caused by rounding or truncation. Why does the sum of the area of the parts not equal the area of the whole? Is there any way to perform a more rigourous area calculation that will give me areas that equal each other? I was wondering about triangulating the polygons (sort of like a TIN structure) before doing the area calculations to reduce error caused by the irregularity of the polygons. A tringulation solution would be ok for smaller datasets, but I am working with datasets that have 4 million polygons, so triangulation would be a bit time-consuming. It is important for our reporting purposes that the area sums equal the original area.
On a somewhat related topic, I have also noticed that if I intersect that same starting polygon from above (5 degrees by 5 degrees) with another polygon dataset that extends beyond the boundaries of this polygon, the northen and southern boundaries of the resulting 'intersected' dataset are curved northward, with the northern boundary extending a small bit beyond the original boundary. I get resulting polygons that have coordinate values greater than 36 in the y dimension (northern boundary of the original), and only two coordinates that are equal to 31 which are found at the southern corners of the original. I understand that this is caused by the use of 'great circles' to calculate the shortest distance between my two northern boundary points and between my two southern boundary points, so this is not a 'bug' because great circles are not the same as latitude parallels. Is there any way to force the sdo_intersection command to perform the intersecetion while treating the coordinates as 'cartesian' coordinates, so that none of the resulting coordinate values extend beyond the original boundaries of my dataset?
Thanks in advance for any help or suggestions.
John

Answer 1

Hi John,
It is very likely that the first part of your question is related to the information you understand from the second part of your question, which is that Oracle uses great circles to connect points in a geodetic coordinate system.
-94,36 connecting to -89, 36 actually deviates from the 36 degree line of latitude by almost 3km at its greatest (2885.3 meters at coordinate -91.5,36). That distance is smallest near the actual vertices and gets larger and larger until the midpoint between the coordinates specified (hence 91.5,36).
If you arbitrarily cut that polygon into several pieces, then depending on how you slice it you could get a polygon with greater or smaller area than the original (if you slice horizontally you will get an area larger than the original, if you slice vertically the area is smaller).
So hopefully the above explains the first part of your question.
The second part of your question relates to the ability of Oracle to densify coordinates to either eliminate or greatly reduce the "drift" of the data along a line of latitude.
Starting in Oracle 10g, the ability to specify a a geodetic "rectangle" was added to spatial/locator). This is done by specifying just the lower left and upper right coordinates, and using an sdo_elem_info_array of (1,1003,3) where the interpretation of 3 means you are specifying a rectangle. So your polygon would be specified as
sdo_geometry(2003,8265,null,sdo_elem_info_array(1,1003,3),sdo_ordinate_array(-94,31,-89,36))
Internally, this signals Oracle to densify this geometry at 1 degree intervals along the lines of latitude, so the movement off of the latitude line is limited.
How limited? The "drift" off the line of latitude is greatest at 45 degrees north and south (this makes sense if you think about it - there is no drift at the equator, which of course is a great circle itself, and there is no drift at the poles). So you can use spatial to calculate the greatest drift:
select sdo_geom.sdo_distance(
sdo_geometry(2002,8265,null,sdo_elem_info_array(1,2,1),sdo_ordinate_array(-91,45,-90,45)),
sdo_geometry(2001,8265,sdo_point_type(-90.5,45,null),null,null),0.5)
from dual;
So at 45 degrees north latitude, when densifying automatically every degree, the greatest movement from the line of latitude is about 121.3 meters.
If you need to follow the line of longitude more precisely, you can densify at greater precision. For instance, if you densify at 0.5 degree intervals your greatest drift is about 30 meters. If you densify at 0.1 degree intervals along the line of latitude your greatest difference is about 1.21 meters.
You could write a function to automatically densify, being careful near the poles so you don't create invalid geometries.
Hope this helps,
Dan