Spatial Domains are inconsistent between tools

[KimOllivier]

If the spatial reference of featureclasses are not identical to a dataset then you cannot load them. You get an error message. So you can change the spatial reference and try again. Nope. So export out and compare. Identical.

The problem is actually in the DOMAIN values. Since these are now so large a default set is created in "high precision" geodatabases I have ignored these until now.... (Not to be confused with attribute domains)

The trouble is that you cannot change the spatial domain once set even it the change would be irrelevant to the data content.
Different tools create different default extents depending on the target geodatabase.  A cut/paste copy will fail if the domains between the dataset and featureclass differ.

The MERGE tool creates a slightly different spatial domain from other tools if merging from coverages to a 9.3 file geodatabase base layer. Then the output featureclass cannot be copied into a default dataset.

If the target is a defaultly defined dataset (instead of the top-level geodatabase) then the domain of the featureclass is different and correctly defined to allow the merge to be completed.

Suggested bugfixes:

Get the error message updated to mention the domain difference if that is the case, instead of blaming the spatial reference.

Maybe allow the domain to be altered on copy? Or have a special tool to fix the domain?

I hope this is of use to everyone else puzzling about the misleading error message.

[VinceAngelo]

ArcSDE coordinate references are composed of the coordinate system, the X/Y origin and
scalefactor, the Z origin and scalefactor, the M origin and scalefactor, and the precision.
The "spatial domain" is implicit from a combination of X/Y origin, scalefactor, and precision,
but incompatibility is measured from all eight components, which ArcGIS calls "spatial reference"
(to maintain consistency with Spatial Reference ID [SRID], I assume).

- V

[KimOllivier]

I see that in one context the domain is included in the spatial reference object.

However it is not included in the spatial reference projection file. So I was looking in the wrong place. Unless I looked up the geoprocessing diagram I would not have noticed that it was included.

The issue of gp.Merge creating a different domain is still a problem. We are not supposed to have to set these with high precision geodatabases any more. Surely that is a bug?

[VinceAngelo]

There are several issues here.  The coordinate system stores projection information
(PROJCS) if a projection is defined, otherwise it just stores the geographic coordinate
system (GEOGCS).  It's confusing that the file is ".prj" when there might not be a
projection, but that's the naming convention that has evolved since the original
shapefile spec was written. 

The larger problem is that the coordinate system is just a tiny part of the coordinate
reference, but that is the only part which is stored with shapefiles.  Only ArcSDE
requires coordinate references, so these properties are not carried in any transfer
format beyond SDEEXPORT.

With BASIC precision coordrefs, you couldn't define one spatial reference per
coordinate system, since you only had 31 bits available.  With HIGH precision
coordrefs, it is possible, but that possibility is also a trap -- needless storage
precision (relative to the data precision) increases the storage and slows
ArcSDE performance.  For this reason, you should not ignore the spatial
reference parameters at data creation -- instead you should generate an
appropriate value and use that for all objects (via SRID).

If individual GP commands produce unique SRIDs as a matter of course, you
should contact Tech Support to generate a defect, since the current commands
should all generate the same (somewhat inefficient) SR for any one coordsys.
The only exceptions are when you are using data outside the expected range for
that coordsys, or when you introdce new dimensionality (M/Z), for which no real
standards exist.

- V