Changes between Version 1 and Version 2 of FDORfc51


Ignore:
Timestamp:
07/27/10 23:56:44 (14 years ago)
Author:
leodai
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc51

    v1 v2  
    88 
    99||RFC Template Version||(1.0)||
    10 ||Submission Date|| May. 06, 2010 ||
    11 ||Last Modified|| Leo Dai - 07/06/10:10:13||
     10||Submission Date|| July. 28, 2010 ||
     11||Last Modified|| Leo Dai - 07/28/10:10:13||
    1212||Author||Leo Dai||
    1313||RFC Status||Draft||
    1414||Implementation Status||Pending||
    1515||Proposed Milestone||3.6.0.0||
    16 ||Assigned PSC guide(s)||Orest Halustchak||
     16||Assigned PSC guide(s)||Orest Halustchak, Greg Boone||
    1717||'''Voting History'''||||
    1818||+1|| ||
    … …  
    2121||-1|| ||
    2222 
     23== Overview ==
     24
     25The purpose of this RFC is to enhance FDO WFS provider to support the WFS latest 1.1.0 version. It outlines changes that are required in the FDO.
     26
    2327== Motivation ==
    2428
    25 Currently 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.
     29The OGC upgrades the WFS specification from 1.0.0 to 1.1.0, and also changes some definitions in it. Currently, WFS FDO provider is hard-coded to 1.0.0 version related in its code. So we need to enhance it to support both versions.
    2630
    27 When 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 
    29 This 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 
    33 Currently 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. This is the rule that OGC has defined and applies to 2D polygons.
    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 
    38 The 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. !ESRI !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 
    44 We 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 utility methods to help users fix polygon vertex order issues. Users can call these methods to fix polygon vertex order error anytime according to the polygon vertex strictness of a geometry.
    4831
    4932== Proposed Solution ==
    5033
    51 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".
     34WFS spec changes a lot while upgrading from 1.0.0 to 1.1.0. For example: The service schema’s structure changed, and it now uses GML 3 instead of GML 2. Accordingly, we need to enhance the provider in the following areas in order to make sure it can consume both versions:
    5235
    53 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.
     361.      Support WFS 1.1.0 capability schema
     37The WFS spec defines new capability schema while upgrading from 1.0.0 to 1.1.0, so we must enhance the parsing process in WFS FDO provider also to support both versions.
     38The following diagram shows capability schema in 1.0.0.
    5439
    55 {{{
    56 /// \brief
    57 /// The FdoPolygonVertexOrderRule enumeration defines the vertex order rule in a
    58 /// polygon loop. FdoPolygonOrderVertexRule values are typically counterclockwise,
    59 /// clockwise and none. None value means the vertex order rule is unknown,
    60 /// undefined or not care.
    61 ///
    62 enum FdoPolygonVertexOrderRule {
    63         FdoPolygonVertexOrderRule_CCW,
    64         FdoPolygonVertexOrderRule_CW,
    65         FdoPolygonVertexOrderRule_None
    66 };
     40From the XML schema diagram above, we can see the 1.1.0 version used the ows:CapabilitiesBaseType instead of wfs:ServiceType exists in 1.0.0. So the OWS related elements parsing process will be put into OWS component.
     41WFS 1.1.0 spec has also defined some new operations, like GetGMLObject, LockFeature… We are not going to support these commands yet in this updates. In this enhancement, we will focus on the elements and operations which already existed in 1.0.0 version but changed in 1.1.0 version.
    6742
    68 /// \brief
    69 /// The FdoClassCapabilities class describes various capabilities
    70 /// for a particular FDO class definition and an FDO Provider datastore.
    71 ///
    72 class FdoClassCapabilities 
    73 {
    74     ......
    75     /// \brief
    76     /// Gets the vertex order rule of the specified geometry property.
    77     ///
    78     /// \param geometryPropName
    79     /// Input the geometry property name
    80     /// \return
    81     /// Returns the vertex order rule that the specified geometry property follows.
    82     ///
    83     FDO_API FdoPolygonVertexOrderRule GetPolygonVertexOrderRule(
    84                      FdoString* geometryPropName );
    85     /// \brief
    86     /// Sets the vertex order rule of the specified geometry property.
    87     ///
    88     /// \param geometryPropName
    89     /// Input the geometry property name to set vertex order rule
    90     /// \param vertexOrderRule
    91     /// Input vertex order rule that the specified geometry follows.
    92     ///
    93     FDO_API void SetPolygonVertexOrderRule  (
    94                      FdoString* geometryPropName,
    95                      FdoPolygonVertexOrderRule vertexOrderRule );
    96     /// \brief
    97     /// Gets the vertex order strictness of the specified geometry property.
    98     /// \param geometryPropName
    99     /// Input the geometry property name
    100     /// \return
    101     /// Returns true if the vertex order of the specified geometry property is enforced.
    102     /// Returns false if it is loose.
    103     ///
    104     FDO_API FdoBoolean GetPolygonVertexOrderStrictness  (
    105                      FdoString* geometryPropName );
    106     /// \brief
    107     /// Sets the vertex order strictness of the specified geometry property.
    108     /// \param geometryPropName
    109     /// Input the geometry property name
    110     /// \param value
    111     /// Input true if the vertex order of the specified geometry property is enforced.
    112     /// Input false if it is loose.
    113     /// 
    114     FDO_API void SetPolygonVertexOrderStrictness (
    115                      FdoString* geometryPropName
    116                      FdoBoolean value );
    117     ......
    118 };
    119 }}}
     432.      Handle GML 3
     44WFS1.1.0 uses GML 3 instead of GML 2 as default format for DescribeFeatureType and GetFeature request. Currently FDO can only handle GML 2 correctly and have some problem with GML 3, we need to enhance it to support both versions well. This includes two aspects:
     45       GML 3 to FDO
     46•       GML 3 schema to FDO schema
     47•       GML 3 feature to FDO feature (FDO only has a reader API, used by the WFS provider, which exposes GML features as FDO features. This API should be updated to handle GML 3)
     48       FDO to GML 3
     49•       FDO schema to GML 3 schema
     50•       FDO feature to GML 3 feature
     51Note: Those transform functions are implemented in the FDO component.
    12052
    121 Add the following three functions in class !FdoSpatialUtility to fix the polygon vertex order error. The first function is used to check the polygon vertex order and fix it as needed. The second function is used to reverse polygon vertex order directly. When the polygon vertex order is known, the second function can be used because it is more efficient.
    122 {{{
    123 /// \brief
    124 /// Spatial utility class
    125 ///
    126 class FdoSpatialUtility
    127 {
    128     ......
    129     /// \brief
    130     /// Check whether the vertex order of the input polygon follows the specified
    131     /// vertex order rule. If not, fix it.
    132     ///
    133     /// \param geometry
    134     /// Input the polygon geometry to be fixed. It can be a polygon, multipolygon,
    135     /// curvepolygon, or multicurvepolygon.
    136     /// \return
    137     /// Returns the modified polygon. 
    138     ///
    139     FDO_SPATIAL_API static FdoIGeometry* FixPolygonVertexOrder (
    140                               FdoIGeometry * geometry,
    141                               FdoPolygonVertexOrderRule vertexOrderRule );
     533.      Handle different version request
     54Currently, the WFS FDO provider uses version 1.0.0 (hard-coded) while sending the request to server. So first, we need to accept version information while open connection, and also set the correct version in the request parameters. Similar with WMS FDO provider, the design solution is to store the version information in the Feature server connecting property. And parse it in the provider, a default version will be provided if user doesn’t set.
    14255
    143     /// \brief
    144     /// Reverse the vertex order of the input polygon.
    145     ///
    146     /// \param geometry
    147     /// Input the polygon geometry to be reversed. It can be a polygon, multipolygon,
    148     /// curvepolygon, or multicurvepolygon.
    149     /// \return
    150     /// Returns the modified polygon.
    151     ///
    152     FDO_SPATIAL_API static FdoIGeometry* ReversePolygonVertexOrder (
    153                               FdoIGeometry * geometry );
    15456
    155     /// \brief
    156     /// Get the vertex order of the input polygon.
    157     ///
    158     /// \param geometry
    159     /// Input geometry to be checked. It can be a polygon, multipolygon,
    160     /// curvepolygon, or multicurvepolygon.
    161     /// \return
    162     /// Returns the vertex order of the input polygon.
    163     ///
    164     FDO_SPATIAL_API static FdoPolygonVertexOrderRule CheckPolygonVertexOrder(FdoIGeometry* geometry);
    165     ......
    166 };
    167 }}}
     57== Implications ==
    16858
    169 == Managed FDO API ==
    170 
    171 The FDO Managed Interfaces will be updated in a similar manner to reflect the proposed changes.
    172 
    173 == Provider Implementation ==
    174 
    175 All FDO providers will be updated to return the correct polygon vertex order rule value and polygon vertex strictness value. For King FDO providers, we will try to find some volunteers from the community to update them.
     59The change just enhances the WFS provider to support 1.1.0 version, it will not cause any side-effects.
    17660
    17761== Test Plan ==
    17862
    179 Existing 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.
     63Add specific unit tests to WFS FDO provider to test the WFS 1.1.0 server consumption. Also Existing unit tests related with GML in FDO will be expanded to test the proposed enhancements defined above.
    18064
    18165== !Funding/Resources ==
    18266
    183 Autodesk to provide resources / funding.
     67Autodesk to provide resources / funding