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; } } }

Clarification around Transformations in ArcGIS Pro

LindsayRaabe_FPCWA

Can anyone give me some guidance on transformations and how they work in ArcGIS Pro. For context, we have a number of feature services in ArcGIS Online published from ArcGIS Pro. There's a mix of coordinate systems in play (mainly through ignorance in the early days). In particular, some layers using the Web Mercator Aux projection (not all which has me totally bamboozled), when loaded into ArcGIS Pro and used as the source layer when going Copy and Paste into a local layer (File Geodatabase feature class) in GDA 1994 MGA Zone 50, the feature shifts. This behavior is consistent when trying to use the Append or Export Features tools as well.

We thought we had fixed this by starting to use the "GDA 1994 To WGS 1984 2" transformation.

When copying data the other way (GDA to WGS Web Merc Aux) the shift doesn't occur.

We're running 3.1.2. We downloaded 3.2.1 to a test device and the issue didn't seem to be happening there (despite all the same coordinate systems, data sources and transformations being used). After stuffing around for more time than I care to remember copying, pasting, changing coordinate systems and transformation, the "shift" issue seems to be completely inconsistent. On the test device, the feature also shifted - once, then went back to behaving the way we want it to (without changing settings).

Also on our original machines, despite loading other feature services with the same coordinate systems and datums, the shift doesn't occur.

Can anyone provide any clarity around where we might be going wrong? Are transformations a one-way thing? Is there another setting somewhere we should also be considering?

We found another transformation (WGS 1984 To GDA2020 3 + GDA 1994 To GDA2020 1) that seems to deal with the issue properly and consistently, but we thought that about the one we are using now, up until now at least.

Encuentra más publicaciones etiquetadas con

Desktop

Accepted answers

ChristopherCounsell

Yep sure can!

ArcGIS Pro is straightforward. It will attempt to project/transform layers to your map coordinate system, applying whatever transformations are set in the map properties. So be aware of default transformations and behaviours like when you add the first layer to the map, it'll change the coordinate system and potentially add transformations to your map properties. I doubt this has changed at ArcGIS Pro 3.2.

Transformations go both ways, so if it says 'GDA 94 to WGS84 2', it'll also go WGS84 to 94.

For your projection issues:

There is no actual transformation taking place 'to WGS84'. It's not considered an accurate coordinate system + stuff to do with time, so they just said that GDA94<>WGS84 is about right, +/- 3m
The same applies for 8450 GDA2020 to WGS84 (2). It's a null transformation.
So 'WGS84' data is actually just 2020 or 94 data dumped into the web coordinate system.
We therefore should consider WGS84 as WGS84@94 or WGS84@2020

So the only transformations - the shift that you are seeing - are between GDA2020 and GDA94:

GDA 1994 To GDA 2020 (1) - 7 parameter transformation
GDA 1994 To GDA 2020 (3) - NTv2 Conformal*
GDA 1994 To GDA 2020 (2) - NTv2 Conformal and Distortion*

So why do we have all these transformations? It's to help consistently align your 94 or 2020 data in WGS84. These days they are trying to get everything to align to WGS84@2020, so will encourage users to use projection paths like 'GDA94 to WGS84 (2)'. It's actually GDA94 > GDA2020 > WGS84, transforming your data to GDA2020. If you have a lot of existing data in WSG84@94, it won't line up.

In your case of picking 'WGS84 to GDA2020 3 + GDA 1994 to GDA 2020 1'

The WGS84 data is going WGS84>GDA94(null)>GDA2020>GDA94. It's also not clear if the WGS84 data is aligned to 94 or 2020 originally.

Confusing? Not really. All your data is 94 or 2020. WGS84 is just 94 or 2020, and mixing 94/2020 in WGS84 is what gives you the misalignment. identify if you're using 94 or 2020 and then follow the projection paths above to end up in the right desired coordinate system. Just note, never mix WGS84@94 and WGS84@2020, as you can't transform the same coordinate system.

All comments

Bryan_krg

Hi @ChristopherCounsell,

I have a similar problem with transformations. We might have incorrectly projected our layers and I'm not sure if we can fix it easily. An example of this is attached. There are 2 suburbs layers one we tried to project into GDA2020 MGA56 called Suburb_KRG. The other is called Suburb_NSW and is downloaded from the state. It's also in GDA2020 MGA56 however they do not match...

If we choose WGS84 to GDA2020 3 as the transformation our data matches the basemap and the state suburbs don't match.

However, if we choose GDA2020 to WGS84 2 the reverse is true. The state suburbs match the basemap and our data doesn't match.

Could you please explain what is happening here. I fear one of these layers is still in GDA94 but now says it has a GDA2020 projection. If so, is there a way to correct this?

Thanks,

Bryan

Suburb_EPSG7856.zip

LindsayRaabe_FPCWA

Thanks for the additional information. Looks like we have some work to do sometime soon clearing up all these rogue projections! We've been planning to migrate all our data from 9 to 2020 anyway, so hopefully once we kick that off we see the tail end of these issues!

ChristopherCounsell

You need to understand:

What coordinate system you are aligning your data to
What coordinate system your data is in
What transformation paths the data is taking, if any,
If working with WGS84, know if it is aligned to GDA2020 or GDA94, and take the appropriate transformation, noting that some are null and others have a hidden step through 94 or 2020
Working with a mix of WGS84 aligned to 2020 and 94 will result in a bad time (misalignment)

You also need to understand that the first three points will differ in different environments. For example, ArcGIS Online will align data to the basemap. It will use a default transformation to do this, but can also use datumTransformations specified at a service level from the time of publish. For a referenced ArcGIS Server service it's possible to have transformations between the GPS > Map > Feature Service > database.

We had a good 20 year period where the only transformation we had as a null one. Now we have options like the rest of the world, and it'll likely only get more complicated with epoch/vertical stuff.

Will this matter for you? Maybe?

End users get confused / doesn't look professional when your datasets are in misalignment
WGS84 isn't accurate anyway, basemaps are an ensemble. We get feedback about trees features not aligning to imagery, when the feature from high-accuracy GDA GPS, and the imagery location will change if you switch basemaps/imagery service providers.
Editing and snapping/geofencing/seeing if location falls within a boundary is an issue
Spatial analysis can be off if your data is not geometrically coincident

Talked about this at a Georabble event in Sydney and kicked off a few good conversations around accuracy/precision and communicating this to GIS and non-GIS stakeholders...

Easiest way to avoid all issues is to stick to one (GDA2020) coordinate system all the way through. Get high-accuracy GPS if you can afford it. GDA2020 locally. If going web, WGS84@GDA2020 in web GIS accepting some level of inaccuracy against the web GIS backdrop, and understand the implications when publishing from Pro.

LindsayRaabe_FPCWA

Thanks for the info and explanation - I think I follow it all (or close enough).

The long and short of it is that we need to look at the coordinate systems used in all the layers in the map and ensure that we don't have some with the WGS84@94 and others with WGS84@20 (if I've understood correctly). Can you clarify if this matters if we're not editing those layers and they're reference only?

ChristopherCounsell

Yep sure can!

Transformations go both ways, so if it says 'GDA 94 to WGS84 2', it'll also go WGS84 to 94.

For your projection issues:

There is no actual transformation taking place 'to WGS84'. It's not considered an accurate coordinate system + stuff to do with time, so they just said that GDA94<>WGS84 is about right, +/- 3m
The same applies for 8450 GDA2020 to WGS84 (2). It's a null transformation.
So 'WGS84' data is actually just 2020 or 94 data dumped into the web coordinate system.
We therefore should consider WGS84 as WGS84@94 or WGS84@2020

So the only transformations - the shift that you are seeing - are between GDA2020 and GDA94:

GDA 1994 To GDA 2020 (1) - 7 parameter transformation
GDA 1994 To GDA 2020 (3) - NTv2 Conformal*
GDA 1994 To GDA 2020 (2) - NTv2 Conformal and Distortion*

In your case of picking 'WGS84 to GDA2020 3 + GDA 1994 to GDA 2020 1'

The WGS84 data is going WGS84>GDA94(null)>GDA2020>GDA94. It's also not clear if the WGS84 data is aligned to 94 or 2020 originally.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.