Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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?

share|improve this question
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 Kuykendall Jun 8 '11 at 17:44
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.panda Jun 8 '11 at 17:55
"shouldn't require a degree in software testing", chat.stackexchange.com/transcript/message/1116371 –  matt wilkie Jun 8 '11 at 19:39

8 Answers 8

up vote 16 down vote accepted

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.

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.

Update: See Andy's answer about using python, only 2 lines, to copy the Feature Dataset spatial reference system from a template feature class. This worked for me in ArcCatalog 10.3 when the interactive method of defining the SR by selecting a feature class to import one didn't work.

share|improve this answer
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.panda Jun 8 '11 at 17:58
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 wilkie Jun 8 '11 at 19:17
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. –  DPierce Jun 4 '13 at 15:26

Here's what I did to resolve the issue (using arcpy in ArcGIS 10.0) -

This assumes the following:

  • FGDB - C:\gisdata\Test.gdb
  • Feature Class - C:\gisdata\Test.gdb\bldg

You can modify your paths and object names in the code and paste it into the python window in ArcCatalog.

sr = arcpy.Describe(r'C:\gisdata\Test.gdb\bldg').spatialReference
arcpy.CreateFeatureDataset_management(r'C:\gisdata\Test.gdb', 'MyFeatureDataset', sr)

After the feature dataset is created you can drag and drop the feature classes in.

share|improve this answer
Thank you! This worked for me today in a situation where using the interactive tool to define the new feature dataset coordinate system by selecting an existing feature class did not work (v10.3). –  matt wilkie Apr 1 at 18:39

Try using the Copy Features tool under Data Management Tools/Features. Otherwise I kept getting an error no matter what I did.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
Hi, @Alan! Thanks for sharing your experience and welcome to our site. –  whuber Jul 21 '11 at 13:38
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. –  mkennedy Jul 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.panda Jan 5 '12 at 18:08

This is an explanation rather than an answer.

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.

share|improve this answer
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.panda Jun 9 '11 at 14:31
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). –  djq Sep 28 '11 at 21:15

Have you tried bring it up to ArcMap and set the layers as your GCS_WGS_1984 and then export all of your layers to a file geodatabase ?

If you have one or several layers that are in different projection, you can export them but change the data frame to GCS_WGS_1984 ?

I am not sure for that in ArcGIS 10. I don't have them yet but am using 9.3.1.

share|improve this answer
Could you please clarify points 1 and 2? These do not appear to be accurate. –  Aaron Apr 1 at 19:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.