Arcade projectAs Geometry Function

[JacobFougstrupNicolajsen]

Working primarily with data in UTM projection, I often need ways to convert UTM coordinates to WGS to create deep links to various online services. 

Having to create duplicate datasets, or running python scripts as regular intervals is tedious and time consuming.

And arcade equivalent of the python projectAs method would solve almost all these issues.

[DavidColey]

Yup, so there you go.  If the webmap basemap is using an ArcGIS Online web mercator basemap like the World Topo you will not get proper results because, like  posted above, the outstanding work by  @MDB_GIS does not - nor should it have to - account for a geographic transformation. 

For NAD 1983 HARN StatePlane Florida West FIPS 0902 (US Feet) I use the NAD_1983_HARN_To_WGS_1984_2 transformation in the Pro desktop software.

Below, I have a StatePlane Florida West vector tile layer that I have used as the webmaps basemap, and you can see that the coordinate expression is a pretty good match:

Hope this helps

[DavidHorwood]

@DavidColey, just a minor point. I was going by the WKT of 2868. 2882 appears to use the same geographic transformation:

TOWGS84[-0.991,1.9072,0.5129,-1.25033E-07,-4.6785E-08,-5.6529E-08,0]

This appears to correspond better to NAD_1983_HARN_To_WGS_1984_3 than NAD_1983_HARN_To_WGS_1984_2

From ArcGIS Pro 3.6 Geographic and Vertical Transformation Tables :

The difference in the shown rotations are due to fact that the WKT definitions are in radians and the table shows arc seconds.

In practice, the difference is likely only a couple inches based on my eyeballing the parameters.

Not to diminish the excellent work by @MDB_GIS in any way, if you did want to get a NAD83 HARN latitude and longitude from WGS84 Web Mercator it would just require a different function and include the geographic transformation. If you are using Enterprise and your own cached webmap in 2882 (or 2868), you are quite correct, the function provided is great, no geographic transformation required.

[BlakeTerhune]

Thank you to everyone who has contributed to this discussion. I was able to get the function from @MDB_GIS working in ArcGIS Online. I had been testing in a web map that used a basemap in state plane, but I could never get the calculations to come out right. I finally started over with a new web map, adding the basemap and layer services again and then it worked! I guess something from the other web map was still holding on to Web Mercator somehow.

[DETCOG_GIS]

I greatly appreciate all the work done by @MDB_GIS, @TomNeer, and others on this thread!  And, while I completely agree this would still be very useful for there to be a function in Arcade to support this... I did want to provide another partial workaround I found for anyone else who ends up coming across this thread.

As has been discussed above, the various formulas do no work the same in ArcGIS Pro and ArcGIS Online.  A function built into the arcade would allow a single function to work seamlessly between the two platforms hopefully.  And the formulas provide by other above appear to work in ArcGIS Pro (provided you update to your coordinate system and your coordinate system works with that formula).  However, if you're going to use this in the context of an ArcGIS Online map exclusively (ex: in a feature's pop-up in a web-map), then you can also just change the basemap's projection and then access the geometry directly without any further manipulation. 

Ex: If you have data in a local projection but want the Lat/Long coordinates, such as in WGS 84, then you can also apparently just switch your basemap to a WGS 84 basemap.  ESRI even provides WGS 84 versions of their core basemaps available at https://www.arcgis.com/home/group.html?sortField=relevance&sortOrder=desc&searchTerm=+wgs84&id=db3f9....  Even though I had a web-service with data in NAD83 based UTM 15N Meters, all I did was change the basemap to one of the WGS84 ones linked to above and then used Geometry($feature).x  and   Geometry($feature).y  in an arcade expression in the pop-up and got the Lat/Long, and not the feature's actual native UTM15N coordinates.  NOTE: This will NOT work the same in ArcGIS Pro, so you'll still need the previously provided conversion formulas if you're trying to do this in ArcGIS Pro or can't change your AGO basemap.

Again, just providing this in case it helps someone else stuck with this same problem... at least until ESRI hopefully makes some changes to improve the workflow.

[MDB_GIS]

@DETCOG_GIS Definitely agreed. This was just a painful workaround that was needed for some of our local CAD datasets. Would definitely much prefer it get added as a native functionality to arcade!

[DETCOG_GIS]

@MDB_GIS Oh, make no mistake, I've already stolen your code and believe I have it modified for my coordinate system for use in Attribute Rules to keep dedicated Latitude and Longitude fields populated with the WGS84 coordinates rather than the feature's local coordinates that the Shape field stores!  Unfortunately, my short-cut workaround is only good if its only in AGO.  So, thank you again!

And ESRI team, if you're reading this, let me reiterate... I didn't mean my post in any way to suggest this work-around was cause not to add this functionality to Arcade.  I concur with the others, it's definitely needed.  Especially since it appears all the workarounds that have been posted on this thread grind to a halt if you're trying to use a service in both ArcPro and AGO and your AGO Org uses the default out of the box basemap group.

[BlakeTerhune]

@DETCOG_GIS

...you can also just change the basemap's projection and then access the geometry directly without any further manipulation. 

I agree, this might work. However, there are some artifacts in my experience doing this. I noticed that all selection highlights (including when the pop-up is displayed) are visually/spatially distorted compared to the displayed geometry and it looks really confusing for users.

[DETCOG_GIS]

@BlakeTerhune It would definitely depend on the specifics of the dataset, area, and coordinate systems involved.  In my particular case, for the intended use case, at least in the area I tested it on, it didn't appear to cause distortion that was noticeable enough.  But I can definitely see that being a bigger concern depending on the skew caused by reprojecting on the fly.  Thanks for pointing that out.