nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Ability to override transformation extents when defining transformation paths

SisselS

Working in a global company with facilites in many different countries and built over the duration of 50+ years, we have to juggle a magnitude of coordinate reference systems (CRS) and transformations, often in the same project. We use several (now) outdated CRSs and have examples of unfortunate choices of both CRS and transformation. Hence we need more flexibility when setting up the transformation path in ArcGIS Pro than the average user.

Idea: make it possible for users and/or admins to define transformation paths (in Map Properties) without concern of the recommended extent/area of use for both the CRS and the transformation. This can be implemented in such a way that it is difficult for "normal" users to do something wrong, but possible for advanced users to create the necessary path.

Example: Data in the following 3 CRSs:

ED50 (EPSG:4230)
WGS 84 (EPSG:4326)
Belge 72 (EPSG:4313)

Transformations:

ED50 to WGS 84 (24) - (EPSG:1613)
BD72 to WGS 84 (3) - (EPSG:15929)
ED50 to WGS 84 (24) + BD72 to WGS 84 (3) - this latter combination is needed when the map is set up in ED50 or Belge72 (BD72), and is currently not available for us.

Find more posts tagged with

Geoprocessing

Closed

Status: Closed

Comments

P√•l_Herman_Sund

I support this idea even if the "create custom geographic transformation" tool can produce the result you want. But then the resulting GFT binary files must be distributed to computers and/or user profiles.

A "disable extents" which would allow user to use transformation outside the extents would be nice.

br
Pål Herman

Bojan≈†avriƒç

Hi @SisselS,

Thank you for your suggestion. ArcGIS Pro’s on-the-fly transformation capability is designed to provide users with quick and appropriate datum transformations without requiring deep knowledge of the underlying methods or which transformations apply to specific geographic areas. ArcGIS Pro assumes that the transformation path listed at the top is the most likely appropriate choice.

Allowing users to override defined extents would expose them to an overwhelming number of transformation options—potentially several hundred in some cases—and make it easy to apply an incorrect transformation path to the dataset. Since many users are not familiar with the details of datum transformations, this poses a significant risk and increases the likelihood of incorrect choices that could corrupt or invalidate their data.

That said, we recognize that there are specific scenarios where bypassing extent checks may be necessary—for example, when repairing corrupted datasets, working with outdated coordinate reference systems (CRS), or correcting previously misapplied CRS and transformations. For these cases, we offer a more controlled and permanent solution that GIS administrators and data managers can use to bypass extent restrictions and fix their data appropriately.

The Project tool in ArcGIS Pro allows users to manually define custom transformation paths. The tool only verifies that the transformation sequence correctly passes through all required geographic coordinate systems but does not enforce area-of-use constraints. For instance, in the example provided bellow—transforming Austrian data from ED50 to WGS84 (via a Norwegian transformation), and then to Belge 72 (via a Belgian transformation)—the Project tool successfully applies the specified transformations.

Project Tool.png

Please note that this approach only works with mathematical transformation methods, such as position vector or coordinate frame (7-parameter) transformations. Transformations that rely on grid-based methods, like NTv2, will not transform coordinates outside the used transformation grids.

If you believe the validity of the mentioned transformations or geographic coordinate systems should extend beyond what EPSG currently specifies, please reach out to EPSG (https://epsg.org/dataset-change-requests.html) and request a correction.

Thank you,
Bojan

Valeria Chavez

Hi @SisselS!

I will be closing this Idea as per the explanation provided by @BojanŠavrič in the comments below: https://community.esri.com/t5/arcgis-pro-ideas/table-of-contents-toc-formatting/idi-p/932648/

Thank you for being an active member of Esri Community!