Changes between Initial Version and Version 1 of FDORfc48


Ignore:
Timestamp:
May 6, 2010, 12:52:41 AM (14 years ago)
Author:
leaf
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FDORfc48

    v1 v1  
     1= FDO RFC 48 - Polygon Vertex Order =
     2
     3This page contains an change request (RFC) for the FDO Open Source project. 
     4More FDO RFCs can be found on the [wiki:FDORfcs RFCs] page.
     5
     6
     7== Status ==
     8 
     9||RFC Template Version||(1.0)||
     10||Submission Date|| May. 06, 2010 ||
     11||Last Modified|| Leaf Li [[Timestamp]]||
     12||Author||Orest Halustchak, Dan Stoica, Gavin Cramer, Leaf Li||
     13||RFC Status||Ready for Review||
     14||Implementation Status||Pending||
     15||Proposed Milestone||3.5.0.0||
     16||Assigned PSC guide(s)||Orest Halustchak||
     17||'''Voting History'''|| ||
     18||+1|| ||
     19||+0|| ||
     20||-0|| ||
     21||-1|| ||
     22 
     23== Motivation ==
     24
     25Currently there are some inconsistencies and missing capability in dealing with the vertex order of polygon loops for different FDO Providers. Some of data sources use clockwise vertex order rule. Some of data sources use counterclockwise vertex order rule. For example, SHP file follows clockwise vertex order rule and Oracle follows counterclockwise rule.
     26
     27When inserting or updating a geometry, the current strategy of FDO Provider is focused on the user being responsible for the geometry and not having the providers fix it. FDO Providers may even throw exceptions rather than automatically try to fix a user’s geometry. So FDO should provide a way for users to get the vertex order rule and the vertex order strictness rule so that users can insert or modify polygon correctly.
     28
     29This purpose of this RFC is to resolve polygon vertex order issue. It outlines changes that are required in the FDO API.
     30
     31== Overview ==
     32
     33Currently there are two inconsistencies in dealing with polygon vertex order. The first consistency is the vertex order rule in a polygon loop.
     34
     35    * 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.
     36    * 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.
     37
     38The second consistency is the vertex order strictness when inserting or updating a polygon.
     39
     40    * SQL Server 2008 Spatial has two data types that support geometry. They are Geometry and Geography. Both of these support polygons but the Geography type has a constraint that the vertex order around loops must be counterclockwise for outer loops and clockwise for inner loops. Polygons that fail this test will be rejected. The FDO SQL Server Spatial provider does not attempt to fix these polygons.
     41    * Oracle also uses the counterclockwise loop order rule, but is not as stringent about enforcing it. It will allow polygons to be inserted with either order. Area calculations will always be positive. A validity function however will indicate which are valid and which are invalid.
     42    * SHP follows a clockwise polygon loop vertex order in contrast to the other formats. While applications that process SHP files may be fairly lax in requiring that polygons follow a clockwise vertex order. ArcView can render polygons with counterclockwise loops correctly and display negative areas for them. OSGEO FDO SHP provider does not change the vertex order of polygons. However, the FME SHP provider does correct the vertex order of polygons.
     43
     44We are not going to change the current strategy of FDO Provider to fix polygon vertex order error automatically by FDO Provider because users may want to save their modification to geometry temporarily before they fix all of geometry errors. Moreover, it may result in performance issue. So what FDO Provider should provide is the following two functionalities.
     45
     46    * Provides a way for users to get the vertex order rule and the vertex order strictness rule.
     47    * Provides one utility method to help user fix polygon vertex order error. Users can call this method to fix polygon vertex order error anytime according to the polygon vertex strictness of a geometry.
     48
     49== Proposed Solution ==
     50
     51Add 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.
     52SQL 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.
     53
     54{{{
     55/// \brief
     56/// The FdoPolygonVertexOrderRule enumeration defines the vertex order rule in a
     57/// polygon loop. FdoPolygonOrderVertexRule values are typically counterclockwise,
     58/// clockwise and none. None value means the vertex order rule is unknown,
     59/// undefined or not care.
     60///
     61enum FdoPolygonVertexOrderRule {
     62        FdoPolygonVertexOrderRule_CCW,
     63        FdoPolygonVertexOrderRule_CW,
     64        FdoPolygonVertexOrderRule_None
     65};
     66
     67/// \brief
     68/// The FdoClassCapabilities class describes various capabilities
     69/// for a particular FDO class definition and an FDO Provider datastore.
     70///
     71class FdoClassCapabilities 
     72{
     73    ......
     74/// \brief
     75/// Gets the vertex order rule of the specified geometry property.
     76///
     77/// \param geometryPropName
     78/// Input the geometry property name
     79/// \return
     80/// Returns the vertex order rule that the specified geometry property follows.
     81///
     82FDO_API FdoPolygonVertexOrderRule GetPolygonVertexOrderRule(
     83FdoString* geometryPropName );
     84/// \brief
     85/// Sets the vertex order rule of the specified geometry property.
     86///
     87/// \param geometryPropName
     88/// Input the geometry property name to set vertex order rule
     89/// \param vertexOrderRule
     90/// Input vertex order rule that the specified geometry follows.
     91///
     92FDO_API void SetPolygonVertexOrderRule  (
     93FdoString* geometryPropName,
     94FdoPolygonVertexOrderRule vertexOrderRule );
     95/// \brief
     96/// Gets the vertex order strictness of the specified geometry property.
     97/// \param geometryPropName
     98/// Input the geometry property name
     99/// \return
     100/// Returns true if the vertex order  of the specified geometry property is enforced.
     101///
     102FDO_API FdoBoolean GetPolygonVertexOrderStrictness  (
     103FdoString* geometryPropName );
     104/// \brief
     105/// Sets the vertex order strictness of the specified geometry property.
     106/// \param geometryPropName
     107/// Input the geometry property name
     108/// \param value
     109/// Input true if the vertex order  of the specified geometry property is enforced. Or input false.
     110/// 
     111FDO_API void SetPolygonVertexOrderStrictness (
     112FdoString* geometryPropName
     113FdoBoolean value );
     114......
     115};
     116}}}
     117
     118Add a new function in class FdoSpatialUtility to fix the polygon vertex order error.
     119
     120{{{
     121/// \brief
     122/// Spatial utility class
     123///
     124class FdoSpatialUtility
     125{
     126    ......
     127/// \brief
     128/// Fixes polygon vertex order error according to the specified vertex order rule.
     129///
     130/// \param geometry
     131/// Input the polygon geometry to be fixed.
     132/// \param vertexOrderRule
     133/// Input polygon vertex order rule that the specified geometry should follow.
     134/// \return
     135/// Returns the fixed polygon. If the input polygon already follows the specified
     136/// vertex order rule or the specified vertex order rule is
     137/// FdoPolygonVertexOrderRule_None, returns NULL . 
     138///
     139FDO_API FdoIGeometry* FixPolygonVertexOrder  (
     140FdoIGeometry * geometry,
     141FdoPolygonVertexOrderRule vertexOrderRule );
     142......
     143}
     144}}}
     145
     146== Managed FDO API ==
     147
     148The FDO Managed Interfaces will be updated in a similar manner to reflect the proposed changes.
     149
     150== Provider Implementation ==
     151
     152All FDO providers will be updated to return the correct polygon vertex order rule value and polygon vertex strictness value.
     153
     154== Test Plan ==
     155
     156Existing FDO core unit tests will be expanded to test the proposed enhancements defined above. Provider specific unit tests will be added to test the proposed enhancements defined above.
     157
     158== Funding/Resources ==
     159
     160Autodesk to provide resources / funding.
     161