Coord Tool reads local GCS and not GCS_WGS_1984 - issues for interoperability

[JSibbald]

The Coord Tool assumes that the local GCS is GCS_WGS_1984 and makes no correction should the Data Frame be in another datum such as when the projection is British National Grid. There is no indication to the user that the coordinates are not suitable for use with other systems which would be assuming GCS_WGS_1984.

Attached is a text CSV file which has the coordinates in GCS_OSGB_1936, BNG and GCS_WGS_1984 as generated by Projection Engine and using the OSGB_1936_To_WGS_1984_7 transformation.

Coords.txt

[topowright-zz]

@mcalamito I need to know if this is an issue that you have seen with customers. If so what do they expect the behavior to be. I

[nfeuerstein]

@JSibbald Thank you for readdressing this at the TEM this week. We are going to address this in this release as a high priority bug.

[nfeuerstein]

@Dbarnes1 @dfoll @NatalieCampos has the fact that the tool assumes/requires GCS_WGS_84 been fully documented in a way that a user cannot miss?

[Dbarnes1]

@nfeuerstein I'm thinking that this will be part of the overview blurb for coordinate conversion. Implementing it now.

[jmhauck]

When a user enters a coordinate we need to understand the appropriate spatial reference to use. This definition could potentially come from a variety of places...could be user defined, based on the map, or could be hard coded. Currently it is based on a mix of hard-coded and the map. Please see the following comment for additional details: https://github.com/Esri/coordinate-conversion-addin-dotnet/issues/213#issuecomment-271682102

[topowright-zz]

@JSibbald We have been working to replicate this issue and we have found the following to be true. Coordinate conversion makes the following assumptions:

• When using the Map Point Tool and the default map units are set in the edit properties on the coordinate conversion pane, the input coordinates are in the map’s spatial reference. • When using the map point tool and display coordinate types other than default map units are set on the edit properties on the coordinate conversion pane, input coordinates are WGS_84 • If coordinates are entered manually, input coordinates are assumed to be WGS 84.

Would you be willing to verify if you are experiencing what is stated above in ArcGIS Pro 1.3 or 1.4?

[topowright-zz]

@jmhauck @dfoll Derek and I took an extensive look into how to document this problem and ran into some concerns. The three statements are correct:

• When using the Map Point Tool and the default map units are set in the edit properties on the coordinate conversion pane, the input coordinates are in the map’s spatial reference. • When using the map point tool and display coordinate types other than default map units are set on the edit properties on the coordinate conversion pane, input coordinates are WGS_84 • If coordinates are entered manually, input coordinates are assumed to be WGS 84.

One concern we have is at times the animation will flash in the correct location of the coordinate when we have placed it in the wrong location using the manual input. This is how you would recreate this problem:

1. Insert three new maps into ArcGIS Pro 2.Change the spatial reference to

• GCS_OSGB_1936
• Web Mercator Aux Sphere
• GCS WGS 84
  3. Enter 51.5 0 into all three windows using the map point tool and the manual entry method
  4. Show the flash on each of the maps and how the flash animation differs.

[topowright-zz]

To explain this issue further here is a image that explains what the tool is doing:

The animation happens at the xy provider location (the B blue dot in the image). This is the correct output that we want.

The challenge that we are seeing on the collect tab is the location is placed on world location (the C green dot) , which is the WGS84 location. The issue can be fixed by having the collect tab drop the location in the xy provided location (the Spatial Reference of the map) and not the world location.

I am also not able to replicate the following statement that we have said to be true:

• When using the map point tool and display coordinate types other than default map units are set on the edit properties on the coordinate conversion pane, input coordinates are WGS_84

No matter what units are set in the edit properties they show the correct location.

[topowright-zz]

All testing has been done in ArcGIS Pro. I need to test in ArcMap

[topowright-zz]

The issue laid out by @JSibbald is still an issue in ArcMap.

[nfeuerstein]

IF ArcMap doesn't honor spatial reference AND Pro does honor spatial reference THEN Remove collect tab IF NOT We need to talk

[csmoore]

Removed from ArcMap in: https://github.com/Esri/coordinate-conversion-addin-dotnet/pull/263 https://github.com/ArcGIS/military-tools-dotnet-single-add-in/pull/17

[topowright-zz]

@nfeuerstein being that the ArcMap functionality works the same in the Convert and the Collect tab can we keep it in for ArcMap? @kgonzago @csmoore FYI.

[nfeuerstein]

@topowright I didn't see the results from your tests, is the following statement true? ArcMap doesn't honor spatial reference AND Pro does honor spatial reference

[topowright-zz]

@nfeuerstein

ArcMap doesn't honor spatial reference (always drops the coordinate in WGS 84 location). The covert and collect tab show the same location and flash is also the same location

ArcGIS Pro Collect tab doesn't honor the spatial reference (always drops the coordinate in WGS 84 location); however , the convert tab does. They flash the coordinate location in the same place, but the collect tab drops the location in the WGS 84 location.

[topowright-zz]

@kgonzago @csmoore Please take the collect tab out of both ArcGIS Pro and ArcMap

[kgonzago]

@topowright collect tab has removed. Please verify.

[topowright-zz]

This is still an issue that we are currently addressing with documentation. We allow the user to understand that we only support WGS84, but we are looking at supporting more in later versions.