topic Re: Arcade: Editing M-values not treated as change to geometry in ArcGIS Pro Questions

Arcade: Editing M-values not treated as change to geometry

Bud — Tue, 15 Mar 2022 08:48:54 GMT

ArcGIS Pro 2.9:

I have a Arcade calculation attribute rule that checks if the geometry of a feature was changed during an edit:

if (Equals(Geometry($feature), Geometry($originalfeature))) { 
    console("geometry changed = no");
    return {"result": {"attributes": {"geometry_changed": 'no' }}}
} else {
    console("geometry changed = yes")
    return {"result": {"attributes": {"geometry_changed": 'yes' }}}
}

The intent is: If the geometry was changed, then it sets a geometry_changed field to "yes". If not, it sets the field to "no".

The attribute rule works as expected in most cases. For example, in the Edit Vertices window, if I manually change an X or Y coordinate using the keyboard, the field will be flagged as "yes", as expected.

However, if I manually change the M-value in the Edit Vertices window using the keyboard, the field will be flagged as "no", which is not expected.

The same thing happens when I use the Drop Measures tool:

Question:

Why don't M-value edits get flagged as a change to the geometry?

Thanks.

Re: Arcade: Editing M-values not treated as change to geometry

Bud — Wed, 16 Mar 2022 01:56:12 GMT

I wonder if the Equals() function is the culprit.

After some testing, I found the following works (I removed the Equals() function and added the Text() function):

if ( Text(Geometry($feature)) == Text(Geometry($originalfeature)) ) {

I also tried doing it without the Text() function:

if ( Geometry($feature) == Geometry($originalfeature) ) {

But that failed in a different way. It flagged all edits, even if the edit was just a change to an attribute (not a change to the geometry). That's not what we want.

Follow-up question:

If the Equals() function is the problem, I wonder what the root cause is? Is it only comparing the X/Y of the geometries, not the M-values?
Is that a bug?

Re: Arcade: Editing M-values not treated as change to geometry

DuncanHornby — Tue, 15 Mar 2022 17:20:50 GMT

Interesting find, the API for Equals() says

Indicates if two geometries are equal, or geographically equivalent given the spatial reference and tolerance of the data.

This in my mind agrees with your findings that the Equals() function does not take into account M values.

I'm happy with that as M could represent anything: distance, time, number of donuts...

Using the Text() function I guess is converting the geometry object into a string representation and that includes the M value so making your string comparison approach work.

Re: Arcade: Editing M-values not treated as change to geometry

Bud — Fri, 25 Mar 2022 10:06:53 GMT

Arcade function: EqualsMZ()

Re: Arcade: Editing M-values not treated as change to geometry

Bud — Fri, 31 Mar 2023 20:44:33 GMT

Esri Canada Case #03305078 - Arcade Equals() function doesn’t consider M-values
Looking at the Equals documentation
Indicates if two geometries are equal, or geographically equivalent given the spatial reference and tolerance of the data. The two input geometries don't have to be clones to be considered equal.
The two geometries don't have to be identical. They're considered equal even if they're within the same tolerance, with X and Y values not identical.
If you're looking to check if geometry has changed, compare all the geometry details manually.
You can access the XYZM values of a point.