Select to view content in your preferred language

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

1231
4
03-15-2022 12:48 AM
Labels (1)
Bud
by
Esteemed Contributor

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. 

Bud_1-1647329756592.png

Bud_2-1647329774141.png


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.

Bud_8-1647330481957.png

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

Bud_6-1647330088835.png

Bud_7-1647330135904.png

Question:

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

Thanks.

 

Tags (1)
4 Replies
Bud
by
Esteemed Contributor

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? 
DuncanHornby
MVP Notable Contributor

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.

Bud
by
Esteemed Contributor
0 Kudos
Bud
by
Esteemed Contributor

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.

 

0 Kudos