Changes between Version 6 and Version 7 of FDORfc48

Timestamp:

Jun 22, 2010, 1:36:53 PM (14 years ago)

Author:

oresthalustchak

Comment:

--

FDORfc48

@@ -33 +33 @@
 Currently there are two inconsistencies in dealing with polygon vertex order. The first consistency is the vertex order rule in a polygon loop.
 
-    * For most systems where there is a specific rule for the order of vertices in a polygon boundary, the rule is that exterior loops follow a counterclockwise order whereas inner loops follow a clockwise order. For deeper nesting of loops, the order rule alternates from level to level, with the most exterior level following the counterclockwise rule. This is the rule that OGC has defined.
+    * For most systems where there is a specific rule for the order of vertices in a polygon boundary, the rule is that exterior loops follow a counterclockwise order whereas inner loops follow a clockwise order. This is the rule that OGC has defined and applies to 2D polygons.
     * The exception to this rule is the SHP file format specification. SHP follows a clockwise rule; however the SHP format was defined before OGC existed.
 
@@ -49 +49 @@
 == Proposed Solution ==
 
-Add the two capability functions in class !FdoClassCapabilities to get the polygon vertex rule and the vertex order strictness of the geometry in a feature class.
+Add the two capability functions in class !FdoClassCapabilities to get the polygon vertex rule and the vertex order strictness of the geometry in a feature class. These will apply to 2D polygons. For 3D polygons, e.g. ones that are completely vertical, these could be in either direction depending on which way is "up".
 
 SQL Server 2008 adds a complication. SQL Server 2008 handles spatial data with two separate data types, geography for geodetic data and geometry for others. The geography type has the strict enforcement of the CCW order. The geometry type has the same rule, but does not have strict enforcement. We could have the capabilities tied to a particular geometry property, which would make the capability handling more complex for providers and for applications. Alternatively we can just make these schema level capabilities and have SQL Server advertise a general strict enforcement of the vertex order rule. Unfortunately, this messes up the capability-based copying of polygons from one provider to another when the source is SQL Server. Existing geometry data may not follow the rules if it uses the SQL Server geometry type. Another alternative is to have the capability function take a coordinate system definition as a parameter. But, that adds complexity as well, and requires providers to analyze the coordinate system definition. So, we’ll stick to defining the capability function for this against the geometry property.