Allow Define Projection to Work Like it Used to--Functionality Removed in Pro 3.5

[MollyJackson]

As of the upgrade to 3.5, Define Projection no longer works to define coordinate systems of existing geodatabase feature datasets or feature classes (whether undefined or improperly defined). It was originally explained to me that this was a bug (BUG-000176807), but later that explanation was corrected to "known issue," and it was explained to me that it is by design to "remove a loophole."

The explanation as to why this change was made is: "Geodatabase feature datasets and feature classes are not designed to have their coordinate systems changed after creation. The ability to update the coordinate system on feature dataset was an oversight and should not have been allowed. At ArcGIS Pro 3.5, that loophole was blocked. The change was on purpose. The new workflow is to make sure that a feature dataset or feature class has the correct coordinate system upon creation. Note: the coordinate system is often used to set the spatial domain (allowed range of coordinates), xy/z/m tolerance and resolution values. When the coordinate system is unknown, those values may be inappropriate for a coordinate system that is defined later."

While I understand the concerns of the developers, this is proving onerous to myself and others (My thread on ESRI Community  and Another thread). It's making the software much less usable in multiple workflows. The workarounds suggested cause me and my staff MORE work and make the product less helpful. I've been using Define Projection for years and have never run into an instance where the "values may be inappropriate for a coordinate system that is defined later." 

Here is a use case for using Define Projection on existing datasets with undefined coordinate systems:  We do a lot of airport mapping--both feature mapping and obstruction analysis. The FAA developed a complex file geodatabase to reflect the data structure required by the governing circular AC150/5300-18B. The geodatabase contains 11 datasets with a huge number of feature classes stored in them. Each feature class has a large number of attributes, many of which are governed by domains. The datasets in this geodatabase have no defined coordinate system, as the geodatabase is used all over the country.

The first step we take upon working with a new airport is to define the coordinate system for all the datasets before we begin populating them with data. With the upgrade to ArcGIS Pro 3.5, we are now unable to define the projection on those datasets, since they are undefined. It just generates an error.

Additionally, we use in-house file geodatabase "templates" daily—importing data into existing data structures. The first step in those workflows is to define the projection of the datasets within the geodatabases. Now we can no longer use those templates—a longer, more convoluted workaround is needed.

Rather than removing functionality that has been used for years, it makes more sense to me that the developers continue to allow the tool to work and instead insert some sort of warning upon execution of the tool about the possibility of incorrect spatial tolerances and resolutions.

This feels like unneeded oversight. It's making your software less useful. We are skilled GIS professionals, and the development team should trust us to understand and utilize tools. 

I've opened two cases with Support Services and have been told there's nothing they can do.

[DavidSolari]

If the Pro team is committed to leaving Define Projection in its current "fixed" state, there should be a separate tool (or a new option for an existing tool) to project the data to a new dataset with the presumption of a specific input coordinate system. That way datasets filled with unknown coordinates can be defined and projected in a single tool.

[cmathers]

That is an surprising change of function. This sounds like a push towards schema reports. They probably want you to convert your template FGDBs into JSON then use python to update the JSON before converting the JSON to an XML Workspace Document that is imported into a new FGDB. You could do it all in a script in a toolbox but that places a development burden on the end user though when a tool exists that used to do this already. I'd like to have someone from esri chime in with why the tool couldn't also update the domains, tolerances, and resolutions if the dataset is empty.

[javalos]

This actively interrupts the Solutions ESRI has published for use. Define Projection is literally a step in the Tax Parcel Data Management Solution.

[ChristalHigdon_USFS]

This "fix" disrupts a long-standing workflow that we rely on for automated Parcel Fabric builds between Alaska and CONUS with different projections. We used this tool as described in the documentation, to change an incorrectly applied spatial reference on a BLANK dataset. There is no reason to change this behavior, as that's what the tool was advertised to do. Very disappointed in Esri and hope you "unfix" this back to the way it was, and is supposed to be, from an end user perspective (and your own tool documentation). 

[DebbieBull]

I add my name here to the community of users who need this functionality, especially as we review our data in preparation to hopefully someday updating our standard to CORS.

[vBright]

I manage an archive of 30 years of GIS datasets. Over the years, it's possible that the projections for these datasets get lost, corrupted, or otherwise defined wrong. In fact, I just fixed a set of 1,950 layers using Define Projection to fix an unknown projection issue. Just ran the layers through Define Projection with a quick python script and my issue was fixed in a few minutes. I have no idea how I would have fixed the unknown projection issue without Define Projection working the way it historically has.

[VenkataKondepati]

Thanks for putting this so clearly — I share the same frustration. While I understand Esri’s reasoning around tolerances and spatial domains, removing the ability to Define Projection on geodatabase datasets feels like it takes useful control away from experienced users. For many enterprise workflows, especially those built around templates or complex regulatory schemas, this change introduces unnecessary friction and forces time-consuming workarounds.

I agree that a better balance would be to retain the functionality with a clear warning, rather than blocking it outright. Most GIS professionals understand the implications of applying a coordinate system after creation, and in many cases it’s the only practical path forward.

+1 to reconsidering this decision — trust your users and provide guidance rather than restrictions.

Regards,
Venkat

[SimonSchütte_ct]

I have a similar use case where I define projections for training datasets. I thought it was an issue on my side and wasted time to figure it out only to find this thread. 
This is a "bug" that does not need fixing. A warning "it is not recommended to...." message would have sufficed.

[EgorNozdrya]

ESRI: "We know exactly what's better for you"

[ChristopherDalu]

This change creates more problems that it conceptually caused, greatly reduces the useability of ESRI's product, constrains the ability to address legacy GIS data that was imported in to early versions of Arcmap that was set to a different coordinate system.  It would be an acceptable change if all the data we receive was created equally, which is not the case.  The first step in this conceptual goal of ESRI seems to have been back in ArcGIS when the ability to assign a different projection within ArcCatalog was removed.

The intent of ESRI to make this change seems to align with ESRI's ongoing efforts to let the software do all the transformations and projections on the fly to make it simpler for many users, but it is just totally short-sighted of ESRI to assume that we are constantly working with or receiving data in which the projections are correct.  It's also concerning to think there might be some conception within ESRI that equates redefining or defining the projection is synonymous with reprojecting, which it is not.  

There are a number of alternative solutions that have been introduced in this thread that I sincerely hope ESRI takes into consideration and quickly reestablishes the ability of users to define projections on datasets without, and to remove projections that were wrongly applied is the past and redefine those projections to bring the data into the spatial extend they were originally intended to be within.