In Esri geodatabases, there is a property of feature datasets known as the XY Tolerance.  The best explanation of the XY tolerance property that I have ever read is, “the minimum distance allowed between XY coordinates before they are considered equal.”

The property is used by a great number of geoprocessing functions, and once it is set for a feature dataset it can never be undone.  Ironically, there is an Esri function that allows you to upgrade a dataset’s spatial reference from low precision to high precision, which makes the XY Tolerance go from a higher number (the default XY Tolerance for datasets in feet is 0.00328) to a lower number (i.e. 5.48 x 10^-8 feet), yet the opposite is not allowed.

This rule is based on the coordinate math.  Basically you can fit multiple high-precision coordinate “cells” into a low-precision coordinate cell, thus a low-precision dataset can be converted to a high-precision dataset without altering any coordinate values (except for the addition of a bunch of zeroes).

There are concessions that must be made when storing data using higher precision.  First of all, the shape fields of higher precision datasets take more storage space.  As you might imagine, this is due to all of the coordinate numbers having more digits after the decimal place.  Secondly, drawing data with higher precision coordinates takes longer because it takes more time to place features on a grid with smaller cells.  Lastly, geoprocessing functions take longer due to the additional math that needs to be performed.  I will provide an example of this in the paragraphs that follow.

Due to these three reasons, Esri recommends that data be stored with an “appropriate” level of coordinate precision.  What I have found during the execution of all of my GIS projects, products, and services, is that the default XY Tolerance setting is usually good enough unless you intend to model the spatial organization of microchips with GIS.

Recently, I inherited a group of datasets that had been created using high precision XY Tolerance values.  I didn’t even notice at first.  As many GIS implementations go, one dataset gets copied to another, and on and on.

Shortly before the production deliveries were to be made, complaints about drawing times were getting louder and louder.  One of the people employed with my client pointed out that he thought setting the XY Tolerance to a less precise number would help tremendously.  He even went as far as performing tests on drawing times with data stored in datasets with standard and high-precision coordinates.  You might guess that the standard precision data drew faster.

With the production delivery date looming, we decided that the end users of the system would not tolerate drawing times that were slower than the 15-year old system they were currently using.  I was charged with creating two new standard-precision datasets to store the data in, and moving the data into those datasets prior to making the production delivery.

After making the change on the very large electrical system that I was working with, the time it took for creating a geometric network went down from over two days to less than 11 hours.

As I was going through the dataset conversion effort, we decided it would be a good idea for me to write this article for you readers.

Following below, I have outlined the steps that must be done in order to move your data to a dataset that has coordinate values stored with a higher XY Tolerance property and less precision.  Once again, the benefits here are related to drawing times, geoprocessing times, and data storage sizes.

1. Seriously consider getting someone else to do it for you.  You don’t need the aggravation.  It is tedious and time-consuming.
2. Remember that you are going to lose all of your relationship classes; document them before you start.
3. Add a field to every feature class attribute table and object class that are involved in any relationship classes to hold the old ObjectID values.
4. Add fields to every feature class attribute table and object class that are involved in any relationship classes to hold each of the old foreign key OID values.
5. Run update queries (in ArcCatalog, using ArcToolbox, or directly in your RDBMS), to set the values for the new fields you have added.  In my particular case, there were hundreds of updates to run.
6. Only after all of these fields for holding the old ObjectID values and foreign key IDs are populated can you move the data into your new dataset.
7. Create your new dataset with the new, less precise, XY Tolerance.
8. Move the data into your new dataset.  As I stated above, “Feature Class to Feature Class” is the function to use for this.  You can try skipping steps 1 through 6, and copying and pasting the data into your new dataset, but you won’t have any luck.  This is just like re-projecting data; the spatial references are not the same.
9. Once all of your data is in the new dataset, you will need to update all of your foreign key ID fields with the new ObjectIDs from the related records.  To do this, you can join your child tables (whether they are feature class attribute tables or object classes) to your parent tables, by linking on ForeignKey_OID_Old to the ObjectID_Old field.
10. Next, you will run another set of update queries where you will reset all of your foreign key OID fields to the new ObjectID from the parent tables.
11. Feature-linked annotation can be re-related, despite what Esri says.  There is a trick to it.
12. Lastly, you will rebuild all of your relationship classes.  The datasets that I was working with had no more than 75 each.
13. Test, test, and test.  You want to make sure your new data model is that same as your old one, especially if you have custom code.  Broken relationships are bad.  You’ll have to go back to the original dataset, recalculate your old ID fields, re-import the data into your new dataset, re-join the tables, re-do your updates, and rebuild your relationship classes.

Now, you’re done.  Get back to work!