I have a feature dataset that is using the GCS_WGS_1984 as the geographic coordinate system. It includes a few feature classes.

This feature dataset is itself in a file geodatabase that contains a few more feature classes in the root of the gdb. One of these is a feature classes called "points" that is also using the GCS_WGS_1984 as its coordinate system.

I thought it would be trivial to use ArcCatalog to drag the feature class from the root of the gdb into the feature dataset since they have the same coordinate system. Unfortunately ArcGIS gives an error dialog that says:

Failed to paste points
The spatial references do not match

Why does this fail? If the GCS of the feature class and the feature dataset are the same, shouldn't it just work? I've verified this is the case via the dialogs as well as exporting the prj file for both the dataset and the class and using a diff tool to compare the two. They are identical.

Is the spatial reference of a feature class different than the coordinate system/projection?

Attemping to copy the feature class into the feature dataset by holding ctrl while dragging results in ArcCatalog crashing each and every time (shame on ESRI).

I guess I could try alternate means of moving feature classes. Use CopyFeatures into the dataset. Project from the feature class into a new feature class within the feature dataset?

Can you post the file gdb some where? Maybe delete all or some of the features if it is big, sounds like it could be reproduced even with empty featureclasses.
–
Kirk KuykendallJun 8 '11 at 17:44

4

I wish I had time to run down every little quirk I run into w/ ArcGIS, often I just have to live with it and find the next least pleasant workaround. I used Data Management -> Copy Feature to copy into a new feature class (temp named), deleted old feature class, renamed new feature class to match old. Using ArcGIS shouldn't require a degree in software testing. =(
–
mindless.pandaJun 8 '11 at 17:55

8 Answers
8

The same coordinate system is not always an identical coordinate system. I have encountered situations where some operations and geoprocessing tools will think feature classes don't share a common coordinate system because the descriptive name of the projection differs ("Yukon Albers" vs "Albers - custom") although the parameters are identical, or because of differing decimal positions (false northing 500000.00 vs 500000.0000).

What I usually do is ensure Feature Dataset (and F.class) coordinate systems are created with our standard .prj file placed in the top of C:\path\to\ArcGIS\Desktop10.0\Coordinate Systems (makes the CS available with fewer clicks) and/or copying the CS from a master feature class template stored somewhere always at hand.

update: Partly in response to this issue, I also have an empty feature dataset (D:\s.gdb\_template) which I funnel all our data through as a first step filter before doing anything else at all with them. Among a common coordinate system this also ensures the precision and spatial domain etc. are identical.

Wouldn't these slight changes in the pretty print name or the decimal positions you mention be present in the .prj file that's exported with the Save As option? If so why does diffing prj files show nothing? I had wondered if slight differences in the x,y resolution could be causing the conflict as well.
–
mindless.pandaJun 8 '11 at 17:58

1

It might be the .prj file created with "Save As" is not exactly the same as the one stored internally. I use a feature dataset "filter" to ensure common spatial resolution etc.
–
matt wilkieJun 8 '11 at 19:17

3

I'll add one additional facet to this: Sometimes datasets from other sources will be generated as containing M and Z values when they do not actually have M or Z. I've found that some ESRI tools detect the empty Z coordinate system as not matching, despite the fact that the X/Y coordinate systems actually do match exactly.
–
DPierceJun 4 '13 at 15:26

We (Esri) do pretty strict testing of coordinate reference system names and values. The 'is equal' test will not return a fail when comparing 500000.00 and 500000.000000, but might fail if one is really 500000.0 and the other 500000.00000005. We're working on adding aliases for names so that 'is equal' will pass more.

As mindless.panda and matt wilkie mentioned, the differences might be in the other values of a spatial reference. A spatial reference includes the coordinate reference system and storage/processing values. For storage: xy, z, and measure resolution and extents. For processing: xy, z, and measure tolerance values. Any difference in these can cause a not equal error.

your response is much appreciated. I would really like to see error handling, particularly in what is reported to the user, improve in ArcGIS. More informative errors are needed, with the option to get even more detailed information if desired. Again, thank you to ESRI for taking the time to respond.
–
mindless.pandaJun 9 '11 at 14:31

1

I second the proposal to provide more information about the errors. Over the last two weeks I have got the same error (Error code: 999999: Error executing function. Description: This is a generic error for which the cause of the error does not have an appropriate error ID. ) due to a range of issues. This is an infuriating message to receive as I can do nothing except try running what I did a second time to see if the error is repeated, or give up and use another method (or software, which is increasingly the case).
–
djqSep 28 '11 at 21:15

I had this problem when simply wanting to move a feature class into a feature dataset in a GeoDatabase. I made my Feature Dataset and ensured it had the same coordinate system. Over and over again I recieved
"Failed to paste xyz
The spatial references do not match"
The quickest work around I found was to import the identical spatial reference in my newly created dataset from the feature class i wanted to import into it.
On the second step of the "Create New Feature Dataset" wizard.

I still frustrated that I don't know why the spatial references differ.
Alan

Hi Alan, the create new feature dataset/class wizard isn't always pulling all of the storage/processing values when "import coordinate system" is used. We're working on fixing it. I think this is what you're running into.
–
mkennedyJul 21 '11 at 16:42

I'm seeing this problem - even if I create the Feature Dataset and use the import mechanism and selected the feature class, I still can't drag/copy the feature class into the newly created Feature Dataset without the aforementioned error.
–
mindless.pandaJan 5 '12 at 18:08

This problem was killing me! After saving a bunch of feature classes from a CAD file, I tried a number of times to define their coordinate systems then organize them into feature datasets. I tried both defining all the necessary f.classes and f.datasets from the official WGS_1984_UTM_42N projection from ESRI, as well as setting the projection for the dataset then importing that projection for the f.classes using the Define Projection tool. Either no f.classes would paste in, or 1 would and the others would not.

Much thanks to @Matt Wilkie over in this post, the Feature Class to Feature Class tool seems to have solved the problem. It successfully imports the f.classes into the desired dataset, even if I have not yet defined the coordinate system for the f.class in question.

Additionally, I found that the Feature Class to Geodatabase (multiple) script works great for moving f.classes into an f.dataset in bulk, except this must be done from Geodatabase to another (not into an f.dataset within the same geodatabase). This appears to be because the script does not automatically rename the f.classes when they are copied (or ask the operator for a new name, as in Feature Class to Feature Class). However, as pointed out by others (same thread linked above), the error given is a generic 999999.

I think one of the messages to ESRI is to provide more specific parameter differences debug information when this error occurs. I too have encountered this error even after carefully controlling for spatial reference systems and projections, as I think most GIS users do.

I have found the procedure of using the ArcToolbox Copy Features to remedy error messages that occur when the import or copy mechanisms are used. Here we are depending upon the Copy Features toolbox procedure to correctly resolve the reference or projection differences before introducing the feature class into the feature dataset.

I have even tried creating the feature dataset with a projection system defined at the dataset creation time, and then projecting feature classes into the feature dataset using the ArcToolbox projection tool with the same projection, and still received the error described here when I try to import or copy the feature class into the dataset.

These coordinate system problems become masked when you use data in ArcMap. Since ArcMap performs on-the-fly projection, multiple feature classes each with differing projections can be added to an ArcMap map without the user becoming aware. ArcMap will warn about differing coordinate reference systems.