Select to view content in your preferred language

Unable to define projection on undefined coordinate system in ArcGIS Pro version 3.5

1761
23
06-10-2025 04:44 PM
Labels (1)
MollyJackson
Regular Contributor

Last week I logged a bug with ESRI (or so I thought). With the upgrade to ArcGIS Pro 3.5, I am no longer able to use some of the templates and schemas we regularly use, as the Define Projection tool no longer works on datasets with undefined coordinate systems and returns Error 000146.

We use a number of empty geodatabases with undefined projections (some we've designed and some we've received from clients such as the FAA and the US Navy) when beginning new projects. Some of them are complex and contain domains and rules. The first step in this process is to assign the project's coordinate system. Now, with the advent of Pro 3.5, we can't do that any more.

Although I was initially told that this was a bug (BUG-000176807), and others have had the same issue, I was later informed that it is a "Known Limit" instead, with no plans to fix it. Here's the explanation I received: 

"These are the public explanations provided by our development team:
 
"Geodatabases are not designed to allow changes to the coordinate system after a feature dataset or feature class has been created. In earlier versions, it was possible to change the coordinate system of a feature dataset, but this was actually an unintended behavior. Starting from ArcGIS Pro 3.5, this loophole has been intentionally closed to prevent issues.
 
The reason behind this is that the coordinate system plays a crucial role in setting important parameters such as the spatial domain (range of coordinates), XY/Z/M tolerance, and resolution values. If a coordinate system is left undefined initially and then set later, those spatial properties might not align properly — which can lead to data integrity problems."
 

I’m truly sorry that you’ve had to encounter this issue.

There is currently no official workaround provided by our development team. That said, after discussing this internally, we would like to suggest the following alternatives for your consideration:

  • Export the features and assign the correct coordinate system during the export process, or

  • Continue using ArcGIS Pro 3.4, where the previous behavior is still allowed.


To clarify, in ArcGIS Pro 3.5, the Define Projection tool cannot be applied to a feature class with an Unknown Coordinate System. It can be used if you are specifying a known coordinate system, such as changing from NAD 1983 Colorado to NAD 1983 Virginia — but only when the dataset already has a defined system."

 

So for now, I've reverted back to ArcGIS Pro 3.4.

Am I nuts for finding this unworkable? It seems to me that as GIS professionals with full awareness of the limitations of undefined coordinate systems (I nag my co-workers to define EVERYTHING), we should at least have the choice to maintain and work with them. As it stands now, I will have to maintain an empty "template" or schema with an improperly defined coordinate system and THEN change the projection using Define Projection tool. I'd much rather start with an undefined coordinate system.

But I'm open to arguments and suggestions.

23 Replies
cmathers
Occasional Contributor

I knocked this together. It works as a script tool in a toolbox but for some reason ignores the overwriteOutput environment setting which is irritating. Didn't test if it does the same in a notebook. If you make a tool from it and set the sref parameter to look for a spatial reference you get the nice GUI to pick which one you want. This does not carry over data though, Schema Reports are just the structure. It might need to be tweaked to work in a different environment, I wrote it quickly and tested it on a single database. Instead of parsing the JSON and searching for the spatial references I just search the text of the file with regular expressions for the lines with 'kid": number' and swap in the new wkid for that number.

 

import arcpy, os, re
def script_tool(inFGDB, sref, outLoc, outName):
    arcpy.env.overwriteOutput = True
    projobj = arcpy.mp.ArcGISProject('CURRENT')
    if outLoc == None:
        outLoc = projobj.filePath
    arcpy.management.GenerateSchemaReport(inFGDB, outLoc, outName, 'JSON')
    wkid = sref.factoryCode
    with open(os.path.join(outLoc, outName + '.json'), 'r') as schemaFile:
        schema = schemaFile.read()
    schema = re.sub('''(?:kid)" ?: ?(\d*)''', f'''kid": {wkid}''', schema)
    with open(os.path.join(outLoc, outName + '.json'), 'w') as schemaFile:
        schemaFile.write(schema)
    arcpy.management.ConvertSchemaReport(os.path.join(outLoc, outName + '.json'), outLoc, outName, 'XML')
    arcpy.management.CreateFileGDB(outLoc, outName)
    arcpy.management.ImportXMLWorkspaceDocument(os.path.join(outLoc,outName +'.gdb'), os.path.join(outLoc, outName +'.xml'))
    return
if __name__ == "__main__":
    inFGDB = arcpy.GetParameterAsText(0)
    sref = arcpy.GetParameter(1)
    outLoc = arcpy.GetParameterAsText(2)
    outName = arcpy.GetParameterAsText(3)
    script_tool(inFGDB, sref, outLoc, outName)

 

javalos
Occasional Contributor

I am also finding this incredibly frustrating. I am using the Tax Parcel Data Management Solution to create a parcel fabric for my Equalization department, but I can't get passed a Task step THEY created. The GDB they include for editing is undefined** and you have to set your spatial reference, but because of this, it doesn't work. It instructs me to use Project instead and copy the dataset. Why close a loophole you use as a step for publishing Solutions?

** It is actually defined, it's just in WGS1984 Web Mercator. Our datasets are in the South FIPS Michigan projection. It's just frustrating. Using Project like they suggest DOES NOT copy over attribute rules OR relationship classes, so you have to go through each feature class one-by-one to re-assign those rules. This is unacceptable for a pre-built Solution.

RichardDaniels
Honored Contributor

The ability to define a coordinate system is a fundamental 1st step in creating any dataset. I discussed this issue with the ESRI Coordinates team at the User Conference, that being stated this is what happens when you higher programmers who can't spell 'GIS' and given them veto authority over the GeoScientists in the room. Breaking a tool that has existed since ArcInfo 9.0 without appropriate error messaging shows they were not doing regression testing.  A user should not have to come 'HERE' to see why the DEFINE command failed.

javalos
Occasional Contributor

Exactly! The error message provides no real explanation as to why it doesn't work. I don't want to create a copy dataset every time I need to alter an undefined or defined projection. It's absolutely fundamental and honestly GIS 101. Changing it like this is beyond flabbergasting.