Changes between Version 5 and Version 6 of FDORfc49


Ignore:
Timestamp:
Jun 2, 2010, 7:53:56 AM (14 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • FDORfc49

    v5 v6  
    66== Status ==
    77 
    8 ||RFC Template Version||(1.0)||
    9 ||Submission Date||(Jun. 02 2010)||
    10 ||Last Modified||(Romica Dascalescu) [[Timestamp]]||
    11 ||Author||(Romica Dascalescu)||
    12 ||RFC Status||(draft)||
    13 ||Implementation Status||(draft)||
    14 ||Proposed Milestone||(3.6.0.0)||
    15 ||Assigned PSC guide(s)||(when determined)||
     8||RFC Template Version||1.0||
     9||Submission Date||Jun. 02 2010||
     10||Last Modified||Romica Dascalescu [[Timestamp]]||
     11||Author||Romica Dascalescu||
     12||RFC Status||Draft||
     13||Implementation Status||Pending||
     14||Proposed Milestone||3.6.0.0||
     15||Assigned PSC guide(s)||Greg Boone||
    1616||'''Voting History'''||(vote date)||
    1717||+1||||
    … …  
    2929
    3030{{{
    31         //those numbers are very small and provide
    32         //the tolerance needed for "exact" computations,
    33         //i.e. CAD style non-FDO geometry intersection.
     31
     32        /// These numbers are very small and provide
     33        /// the tolerance needed for "exact" computations,
     34        /// i.e. CAD style non-FDO geometry intersection.
     35        ///
    3436        #define EPSILON 1e-10
    3537        #define NEGEPSILON -EPSILON
    … …  
    3739}}}
    3840
    39 Here we try to change the FDO API for spatial evaluation (FdoSpatialUtility - FDOSpatial.dll) used by providers like SQLite, SDF, SHP and not providers like KingOracle or SQL Spatial Server where the spatial evaluation is done on the server side.
     41Here we try to change the FDO API for spatial evaluation (!FdoSpatialUtility - FDOSpatial.dll) used by providers like SQLite, SDF, SHP and not providers like !KingOracle or SQL Spatial Server where the spatial evaluation is done on the server side.
    4042
    41 The idea is to add support in FDO API for passing the tolerance into the spatial utility.
    42 FDO has already support for those tolerances, so user can provide them when a new spatial context is created. Also those values can later be obtained using a spatial context reader. Each class in FDO has a dedicated spatial context reader. The provider can get those tolerances (XY and Z) by getting the spatial context of the class before running the spatial evaluation. Since providers might want to have 0.0 tolerances we cannot pass default values as 0.0, so we can pass 1e-10 same as before this RFC, which is the default value used by FDO API. If the spatial condition is a 2D evaluation the Z tolerance will be ignored.
     43The idea behind this RFC is to add support in FDO API for passing the tolerance into the spatial utility. FDO has already support for tolerances, so users can provide them when a new spatial context is created. Also those values can later be obtained using a spatial context reader. Each class in FDO has a dedicated spatial context reader. The provider can get those tolerances (XY and Z) by getting the spatial context of the class before running the spatial evaluation. Since providers might want to have 0.0 tolerances we cannot pass default values as 0.0, so we can pass 1e-10 same as before this RFC, which is the default value used by FDO API. If the spatial condition is a 2D evaluation the Z tolerance will be ignored.
    4344
    4445== Proposed Solution ==
    … …  
    4748
    4849{{{
     50
    4951        /// \brief
    50         /// Spatial utility class.
     52        /// Spatial Utility Class.
     53        ///
    5154        class FdoSpatialUtility
    5255        {
    5356        public:
    5457            /// \brief
    55             /// Evaluates if two FDO geometric objects spatially interact with each other based on a user supplied spatial operator.
    56             /// For example: Contains, Crosses, Disjoint, Equals, Intersects, Overlaps, Touches, Within, CoveredBy, Inside, EnvelopeIntersects.
     58            /// Evaluates if two FDO geometric objects spatially interact with each other
     59            /// based on a user supplied spatial operator. For example: Contains, Crosses,
     60            /// Disjoint, Equals, Intersects, Overlaps, Touches, Within, CoveredBy, Inside,
     61            /// EnvelopeIntersects.
    5762            ///
    5863            /// \param g1
    … …  
    6065            /// \param op
    6166            /// Input The spatial operation to apply to the left and right hand geometries
    62                     /// \param g2
     67            /// \param g2
    6368            /// Input Right hand Geometry to Evaluate
    6469            ///
    … …  
    7378            /// Returns the evaluation of spatial operation.
    7479            ///
    75             FDO_SPATIAL_API static bool Evaluate(FdoIGeometry* g1, FdoSpatialOperations op, FdoIGeometry* g2, double toleranceXY = 1e-10, double toleranceZ = 1e-10); 
     80            FDO_SPATIAL_API static bool Evaluate(FdoIGeometry* g1,
     81                                                 FdoSpatialOperations op,
     82                                                 FdoIGeometry* g2,
     83                                                 double toleranceXY = 1e-10,
     84                                                 double toleranceZ = 1e-10);
     85
     86
     87
    7688}}}
    7789
    … …  
    7991== Managed FDO API ==
    8092
    81 The FDO Managed Interfaces will be updated in a similar manner to reflect the proposed changes (adding a new function which takes an additional parameter named tolerance).
     93The FDO Managed Interfaces will be updated in a similar manner to reflect the proposed C++ API changes.
    8294
    8395== Provider Implementation ==
    8496
    85 Initially, we need this for SQLite provider. Other provider developers can use it and use it as needed. No change is required in other providers. SQLite provider must be changed in order to be able to store those tolerances. Right now the provider keeps just a few values for spatial context like srid, name, WKT, auth_Text, auth_srid, and we have to add tolerances. The old versions of provider will ignore those new columns, and the new provider in case will not find these tolerances will use the default values. All other providers don’t have to be changed and 1e-10 will be passed. Each provider will handle tolerances as they want. This RFC will not force providers to use the tolerance from spatial context (even that should be the right thing to do).
     97Initially, the changes identified by this RFC are needed for the SQLite Provider. Other provider developers can provide support for these values on an as-needed basis. However, no change is required in other providers. The SQLite Provider will be changed in order to be able to store those tolerances. Right now the provider keeps just a few values for spatial context like srid, name, WKT, auth_Text, auth_srid. Tolerances will be added to that list. Older versions of the SQLite provider will ignore those new columns, and the new provider in case will not find these tolerances, will use the default values. All other providers don’t have to be changed and 1e-10 will be passed. Each provider will handle tolerances as they want. This RFC will not force providers to use the tolerance from spatial context (even that should be the right thing to do).
     98
    8699This RFC will just add to the spatial FDO functions two new parameters, having as default values the values used till now (hard-coded values) in order to make possible that some providers which cares about tolerance to be able to use it.
     100
    87101FDO spatial API had no way to pass tolerances and it used an internal hard-coded one making impossible for providers like SQLite to evaluate spatial queries having a certain tolerance.
    88102