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

[MollyJackson]

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.

[MollyJackson]

An update: it appears that I can't use "Define Projection" on any previously projected data. If my dataset or feature class are undefined OR defined, I can not use "Define Projection" to redefine the projection. 

[ChristalHigdon_USFS]

Yes, we use this in a python scripted build process to migrate to Parcel Fabric. We take an empty gdb and change the "incorrect" coordinate system to the correct one after the copy. It is blank of any data but has a complex structure with relationship classes and related stand-alone tables. This is a huge "bug" from my perspective and a blocker for going to 3.5, which we need for the enhanced attribute rule functionality. The "proper" way to change the projection is to use the Project tool, which leaves behind much of our data. Maybe that is the "bug" in 3.5. I am trying to open an Esri case on this myself but have to go through the proper channels in my organization. 
GDB before using Project, with 'incorrect' coordinate system:

After using the Project tool to 'correct' the coordinate system:

Some of the relationship classes made it through, some did not - even the out of the box relationships inherently created by creating the Parcel Fabric geodatabase. The related tables also did not come through.

[javalos]

I have this exact same issue. My attribute rules and relationship classes did not transfer over. I have to go through the feature classes one-by-one to re-assign them. This is from an ESRI promoted and produced ArcPro Project. How did they not think about this?

[RTPL_AU]

Hi @MollyJackson, everyone. 
This type of thing directly intersects my Idea for Esri to change the release approach of Pro.  Please have a look and upvote if found agreeable.
https://community.esri.com/t5/arcgis-pro-ideas/change-pro-development-to-use-a-more-conservative/idi...

I have upgraded to 3.5 to get bugfixes for severe issues in earlier versions. In my opinion, bugs should be fixed in the version they occur and and having a long term support version will see that it happens for a decent period of time.

Breaking features such as these MUST be in a feature release version, not a stable/LTS version, so that we can decide if we want bugs fixed or need a shiny new feature.  There are already a couple of issues in 3.5/3.5.1 that have been marked as 'fixed' in 3.6!! 

I have experienced this issue the other day but I don't do the undefined > defined thing often enough to not realise it wasn't me making a mistake..... 

I can't remember this "Loophole fix' getting a mention in the Release Notes?

[ChristalHigdon_USFS]

I searched through the 3.5 release notes and saw no mention of this 'loophole fix'. It really throws a wrench in my workflow, using it as described in the Help Docs to correct and incorrectly assigned projection.

[MollyJackson]

After two cases with support services, I've basically been told there's nothing they can do, and I should submit my request to ArcGIS Ideas. So here it is. The more kudos an idea gets, the more visible it is to developers:

https://community.esri.com/t5/arcgis-pro-ideas/allow-define-projection-to-work-like-it-used-to/idi-p... 

[javalos]

Thank you for posting this. I thought I was going nuts.

[MollyJackson]

Glad to validate your concerns. Frankly, I'm surprised this hasn't gotten more traction. I've come up with some workarounds on our end, but they are clunky and cause us more work--the opposite of what an update should do.

[cmathers]

I'll reply here but put the same on the Idea. The workaround I will use for this since we apparently have to use a workaround now is:

1. Export the template FGDB to a JSON with the Generate Schema Report tool.
2. Edit the spatial reference of each item with python. 
3. Convert the Schema Report to an XML Workspace with the Convert Schema Report tool.
4. Create an empty FGDB.
5. Then apply that to a new FGDB with the Import XML Workspace Document tool.

"spatialReference": { 
    "wkid": 102660, 
    "latestWkid": 2238
},​

That will appear in every dataset included in the Schema Report. Grab the wkid values from the spatial reference object you want to change to and swap the values throughout the file.

Parameterized as a tool in a toolbox the spatial reference parameter would present you with the normal projection picking GUI. You could skip a step by going straight to a XML Workspace Document and editing that but I hate parsing XML in python, JSON is easier to deal with to me. Its a new development burden placed on the end users but that shouldn't be more than a couple dozen lines of code. A lot of the heavy lifting is done by existing toolbox tools available at all three license levels. 

[ChristalHigdon_USFS]

Thank you for this helpful workaround. I will give it a try but generally going to/from XML Workspace Document with a Parcel Fabric dataset doesn't work well, for whatever reason. Worth a try since Esri killed our years-long established and well-working workflow of Define Projection to correct an already defined projection on a dataset.