Changes between Version 1 and Version 2 of FDORfc55
- Timestamp:
- Jan 14, 2011, 1:55:01 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FDORfc55
v1 v2 1 = FDO RFC 55 - ??? for SHP provider =1 = FDO RFC 55 - Convert Decimal(p,0) datatype to FdoInt32 for SHP Provider = 2 2 3 3 This page contains an change request (RFC) for the FDO Open Source project. … … 10 10 ||Submission Date|| June 08, 2009 || 11 11 ||Last Modified|| Dan Stoica[[Timestamp]]|| 12 ||Author||Dan Stoica , Orest Halustchak||12 ||Author||Dan Stoica|| 13 13 ||RFC Status||Adopted|| 14 14 ||Implementation Status||draft|| … … 16 16 ||Assigned PSC guide(s)||Greg Boone|| 17 17 ||'''Voting History'''|| || 18 ||+1||Haris, Frank, Jackie, Traian, Greg, Orest, Jason ||18 ||+1||Haris, Jackie, Greg, Orest, Jason || 19 19 ||+0|| || 20 20 ||-0|| || … … 23 23 == Overview == 24 24 25 This RFC is for adding the FDO SHP provider capability to support multi-polygons geometries in the cases where SHP files have multi-polygons.25 This RFC is for handling the cases where DBF files contain DECIMAL(precision, 0) columns. 26 26 27 27 == Motivation == 28 28 29 Currently, this provider supports only simple polygons. The SHP specification defines only a polygon type, but it defines it as supporting multiple outer polygon loops, which basically are multi-polygons as defined in FDO. So a SHP polygon can be either an FDO polygon or an FDO multi-polygon, depending on the number of outer loops. The FDO SHP provider is not taking advantage of this and is not returning multi-polygons when the polygons are actual multi-polygons. The main processing that is missing with the current provider is on read, it does not check the polygon details to determine whether to generate an FDO polygon or an FDO multi-polygon geometry. 29 The motivation is well explained by: 30 Ticket #365 [SHP Provider]: When executing IApplySchema, Int32 properties are converted to Decimal properties 31 http://trac.osgeo.org/fdo/ticket/365 32 33 >> If you execute an IApplySchema on a SHP connection. Any Int32 properties in any class definitions inside the schema (to be applied) will be converted to Decimal properties once the schema has been applied. This does not happen if the Int32 property happens to be an Identity property. << 34 35 For further clarification "will be converted to Decimal properties" refer to FdoDecimal properties. 36 37 Note storing FdoInt32 as Decimals is expected since by specification DBF files natively do not have an integer type, but only DECIMAL(precision, scale) datatype. The same apply to double and single precision datatypes. Hence a FdoInt32 is mapped to a DECIMAL(11, 0) column type. 38 39 The impact is on Describe Schema when currently a FdoDecimal is returned for a DECIMAL column even in the cases when the scale is zero and most probably the original type was a FdoInt32. 40 41 This RFC is required since reading back a FdoInt32 instead of a FdoDecimal is a change in behavior. 30 42 31 43 == Proposed Solution == … … 33 45 Modify the FDO SHP provider: 34 46 35 * Change its capability setting to indicate that it supports multi-polygon geometry types, FdoIGeometryCapabilities::!GetGeometryTypes().[[BR]] 36 * On input of geometry, there is no further processing needed as the current code will save all input loops without checking whether they are outer or inner.[[BR]] 37 * On read of geometry, the code should check the geometry to see if there are multiple loops. If there are multiple loops, determine if there are more than one outer loops. If so, change the output geometry type to FDO multi-polygon, otherwise, leave it as polygon with interior rings.[[BR]] 38 * If any loops of a geometry are not closed, then the current behavior of not changing the geometry at all is followed. The geometry is returned as-is.[[BR]] 47 * the DBF to FDO datatype mapping (physical to logical conversion) needs a small refinement. In the case of DECIMAL(precision, scale) check the scale value. When the scale is 0 (zero) then return an FdoInt32 rather than an FdoDecimal. Note SHP doesn't support FdoInt64 or FdoInt16 datatypes therefore the mapping to FdoInt32 is unique. 39 48 40 == Implications ==49 == Implications == 41 50 42 * The code for this is mostly done, just turned off. We will need to measure and work on any performance impact, but the extra processing would only apply for cases where there are multiple loops. The most common case of a single loop polygon would not be processed any differently and would not have a performance impact.51 * In the case of physical DECIMAL(precision, scale) column the corresponding logical FDO property type will be set according to the scale. The caller must expect either a FdoDecimal or a FdoInt32 when reading a SHP schema. 43 52 44 * Th e FDO geometry type will be set accordingly on reading. The caller must expect either a polygon or a multi-polygon regardless of original geometry type on insert.53 * This is a behavior change for the SHP provider. Before this change, SHP would return only FdoDecimal for all numerical FDO types. It would never return an Int32 except for the identity property (which actually is not stored). 45 54 46 * This is a behavior change to the SHP provider. Before this change, SHP would return only polygon types. It would never return something called a multi-polygon. After the change, SHP will return either polygons or multi-polygons. Previously a layer from a polygon SHP file would have only polygons, now it could have polygons, multi-polygons or both. This change could occur with existing data and layers, e.g. stylization rules that handle polygons and multi-polygons differently may see a change. 47 48 55 * The provider will return a FdoInt32 even for properties which originally were DECIMAL(p, 0). This issue can be mitigated by noting the SHP provider already does silent corrections on the fly in certain cases, like truncating the property names when found too long (both on reading and writing). 49 56 50 57 == Test Plan == 51 58 52 * Enhance the unit test and add roundtripping fidelity tests. 53 * Performance benchmarks on large datasets containing polygons with many rings. 54 59 * Enhance the unit test and add roundtripping fidelity tests for FdoInt32 properties. 60 55 61 == Funding/Resources == 56 62 57 Autodesk to provide resources /funding.63 Autodesk to provide resources/funding. 58 64
