I just want to move my hard work from a supplied Shapefile to File Geodatabase then into the Enterprise Geodatabase. However the geography is moving around like it’s in the wind. My cadastre now has all sorts of sliver polygons and the attribute table reports different areas and distances to the original data sets.

Never fear there’s a few basic things you can do to begin to mitigate these drift issues.

Each spatial data type stores the geometry differently and each storage method can have vastly different limitations. In addition the projection and datum defined on the spatial data impacts significantly on geometry drift. Assumption and ignorance can be the step mother of many issues. Drift is specifically caused by:

- The underlying spatial datatypes:
- XY Resolution,
- XY Tolerance and;
- Projections

**To mitigate drift:**

- Standardise your projection and datum
- Standardise your transformation equations
- Standardise your XY Resolution
- Understand your data’s geometry

Vector geometries typically come in three major classes: Points: consisting of X Y Z coordinates, Lines: Many X Y Z coordinates linked together with mathematical equations and Polygons: are akin to a line, but the last mathematical equation links back to the first XYZ in the sequence. Theses XYZ’s and their math are stored differently between all vector formats. The common factor is that an XYZ coordinate must be located at the intersection of a coordinate grid (figure 1). When an attempt is made to place an XYZ at any other location it is moved to the grids intersection (figure 2). This movement is like a magnetic force sucking the XYZ into the correct location, this concept is called “tolerance”.Coordinate grids can be fine like figure 3 or coarse like figure 4, this is called “XY resolution”. When a coarse XY resolution dataset is moved into a fine one (figure 1 moved into figure 3) there’s insignificant physical adjustment. However when a fine XY dataset is to moved into a coarse one (figure 3 to figure 4) things move. The XY tolerance moves the XY’s to the intersections of the coarser coordinate grid and error is introduced.

Each data type for example: Shapefile, CAD, Mif and Geodatabase have different XY resolution abilities, in addition the XY resolution capabilities change depending on the projection and datum.

**In the scenario of importing shapefile data into a File Geodatabase and then into SDO_Geometery (a class of Enterprise Geodatabase):**

Esri Shapefiles store XYZ’s in a “Shape field” of a double type. This format has no controls over the XY resolution or tolerances. A shapefiles geometry is impacted primarily by the projection and then the double field. Shapefiles are better than Esri Coverages, which have a single type “shape field”. The precision of these geometry fields affects the way XYZ’s are stored.

In a ArcGIS 9.2 File Geodatabase and above, when you create a new feature class the user can specify the: Projection, the XY Resolution and XY Tolerance. The Default XY Resolution for GDA_1994 Zone is 1mm. This resolution is not suitable for some GIS purposes (Roads, Geology, Rivers, Cadastre, and so on).

Oracle Spatial (Enterprise Geodatabase) stores its XYZ’s in a SDO_Geometry type field. This data type can not ‘typically’ store an XYZ resolution finer that 5cm. Therefore bringing a sub millimetre file geodatabase feature class or CAD file into Oracle will result in drift.

If you constantly go between Shapefiles, File Geodatabase and Oracle than you should set up your Geodatabase Feature classes to cater to the lowest common known denominator. Prescribe an XY resolution of 5cm to feature classes.

Projections and datum’s influence the XYZ resolution, therefore it is wise to standardise the Geographic and Cartesian systems. Transformation equations that take one data set and re-projects it to another system impacts on the XY resolution. For example the NVT2 transformation, transforms AGD 66 to GDA 94. This transformation has a XY resolution of 10cm. Therefore there is drift. It is prudent to research the transformation equations that you use, then standardise their use.

**Interesting Ideas from the Esri help:**

*“- To keep coordinate movement small, keep the XY tolerance small. However, an XY tolerance that is too small (such as 2 * XY Resolution or less) may not properly integrate the line work of shared boundaries. (So for us let’s not make a cadastre in the sub millimeters)*

*- Conversely, if your XY tolerance is too large, feature coordinates may collapse on one another. This can compromise the accuracy of feature boundary representations. (So let’s not make a cadastre this in the meters)*

**Your XY tolerance should never approach your data capture resolution.**

*For example, at a map scale of 1:12,000, one inch equals 1,000 feet, and 1/50 of an inch still equals 20 feet – a data capture accuracy that would be hard to meet during digitizing and scan conversion. You’ll want to keep the coordinate movement using the XY tolerance well under these numbers. Remember, the default XY tolerance in this case would be 0.003281 feet.”*

*http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//001w0000000q000000.htm*

**File Geodatabase XY Resolution Workflow:**

- Run a repair geometry geo process on the Shapefile (repeat until no reports of errors)
- Create a new File Geodatabase (not personal)
- Create either a new feature dataset or new feature class
- Import or select the Projection (In my case: GDA 94)
- On the XY Tolerance Window: Change the defaults: ie 0.001 Meter to 0.05 Meter, as below (these should always be a magnitude above the resolution)
- Un Tick “Accept default resolution and domain extent”
- On the XY resolution box: Change the defaults: ie 0.0001 Meter to 0.005 Meter
- Finish the rest of dialog
- Import the repaired shapefile into the new feature class (try the simple data loader)

Alternatively you can directly import the shapefile (or other formats) into the file geodatabase. However ensure the environment settings specify the XY Resolution and Tolerance of 5cm or the equivalent

Pingback: File Geodatabase Admin | gisintelligence