Geometry comparison problems

2606
8
Jump to solution
02-28-2014 07:56 AM
CodyScott
Occasional Contributor
Hello,

I am having some troubles comparing geometries between two line features and I am wondering if anyone might know a solution.

Basically i would like step through each object in one table and then compare it to a corresponding object in another table to detect if a change has occurred in the geometry of the item.

The problem i am encountering is with the geometry object generated from the "SHAPE@" in the arcpy.da.SearchCursor.
When comparing two pipes that I know are identical, the two geometries return as being not identical to one another, but if i use a "SHAPE@JSON" or simply compare all the XY attributes of the two features, then they do return as being equal as expected.

Has anyone had experience with geometry objects not returning equal when other checks of the same data return being equal?
Further, would simply using "SHAPE@JSON" be a suitable substitute for confirming geometric differences within a pipe?

Thanks for any help!

Here's the code in a nutshell. the mPipes and oPipes are the modified and original features respectivley.

             with arcpy.da.SearchCursor(mPipes,["OID@","SHAPE@","SHAPE@JSON"]) as scursor:         for row in scursor:             print row[0]             expression = '"OBJECTID" = {0}'.format(row[0])             ogeom = None             for part in row[1]:                 #row 1 for geometry object, row[2] for json                 mgeom = row[2]             with arcpy.da.SearchCursor(oPipes,["OID@","SHAPE@","SHAPE@JSON"],where_clause=expression) as check:                 for i in check:                     for p in i[1]:                         #i[1] for geometry object, i[2] for json                         ogeom = i[2]             if ogeom == mgeom:                 print "Equals!"             else:                 print "Not Equals!"             print ogeom             print mgeom             print ''
Tags (2)
0 Kudos
1 Solution

Accepted Solutions
XanderBakker
Esri Esteemed Contributor
Hi Cody,

When I export a single feature twice (to different feature classes) and compare both feature geometries, it results in:

shp1 != shp2
shp1.WKT == shp2.WKT
shp1.JSON == shp2.JSON
shp1.__dict__ != shp2.__dict__
not shp1 is shp2


Even if I read the same feature from the same feature class twice, they will not be the same.

Although one may assume that the geometry is the same, since we are comparing objects, these objects are consuming different parts in memory and for that are considered different. Only if it's the same instance of an object it will test equal.

Kind regards,

Xander

View solution in original post

0 Kudos
8 Replies
XanderBakker
Esri Esteemed Contributor
There is something I don't quite understand yet: your are looping through the parts of a geometry, but for each part you compare the geometry as JSON...

What you should realize is that the JSON will not contain any information on Z and M values. Since you are working on pipes the chances are that your geometry will have Z and/or M values. So, the question is, is your data Z or M aware? And if so, are there any changes in Z and/or M?

See below the JSON and WKT output of a Polyline ZM feature (with M undefined).

geometry WKT:
MULTILINESTRING ZM ((91742.483000000226 427736.20099999971 1.8999999999996362 NAN, 91743.589999999676 427733.00599999959 1.8999999999996362 NAN, 91744.996000000538 427730.98500000004 1.8999999999996362 NAN, 91746.835999999574 427729.51300000038 1.5100000000020373 NAN, 91756.677000000025 427722.87599999964 1.3600000000042201 NAN, 91759.524000000223 427716.44400000037 1.3600000000042201 NAN, 91785.322999999873 427225.90999999986 -1.1399999999994179 NAN, 91785.823000000179 427205.91399999958 -1.0899999999983265 NAN, 91785.973000000376 427195.91200000024 -1.0400000000008731 NAN, 91783.874999999971 427190.82400000002 -1.0400000000008731 NAN, 91782.969999999477 427189.89800000004 -1.0400000000008731 NAN, 91764.613999999478 427166.16899999959 -0.40999999999985448 NAN, 91749.388999999865 427146.43199999968 -0.40999999999985448 NAN))

geometry JSON (no Z or M values):
{"paths":[[[91742.483000000226,427736.20099999971],[91743.589999999676,427733.00599999959],[91744.996000000538,427730.98500000004],[91746.835999999574,427729.51300000038],[91756.677000000025,427722.87599999964],[91759.524000000223,427716.44400000037],[91785.322999999873,427225.90999999986],[91785.823000000179,427205.91399999958],[91785.973000000376,427195.91200000024],[91783.874999999971,427190.82400000002],[91782.969999999477,427189.89800000004],[91764.613999999478,427166.16899999959],[91749.388999999865,427146.43199999968]]],"spatialReference":{"wkid":28992}}

What you could do is using the geometry's WKT for string comparison, but be aware that the WKT does not hold any spatial reference information. You should also look at the attributes to check for changes.

It might be wise to have a look at the "Feature Compare (Data Management)" tool.

Kind regards,

Xander
0 Kudos
CodyScott
Occasional Contributor
In the initial post i explain why i am using the JSON to compare the features.

what i was interested in is understanding that when two features are compared based on a geometry object they don't equal one another as opposed to a JSON or even XY for each vertices of the same identical feature.  

There is no Z or M information in the fields.

I have looked at the feature compare tool before but I need to perform more granular work on the objects when they do differ at the time of search.
I also already compare the attributes, but opted to not include in the code for simplicity and specificity.
0 Kudos
XanderBakker
Esri Esteemed Contributor
Hi Cody,

When I export a single feature twice (to different feature classes) and compare both feature geometries, it results in:

shp1 != shp2
shp1.WKT == shp2.WKT
shp1.JSON == shp2.JSON
shp1.__dict__ != shp2.__dict__
not shp1 is shp2


Even if I read the same feature from the same feature class twice, they will not be the same.

Although one may assume that the geometry is the same, since we are comparing objects, these objects are consuming different parts in memory and for that are considered different. Only if it's the same instance of an object it will test equal.

Kind regards,

Xander
0 Kudos
CodyScott
Occasional Contributor
Hi Cody,

When I export a single feature twice (to different feature classes) and compare both feature geometries, it results in:

shp1 != shp2
shp1.WKT == shp2.WKT
shp1.JSON == shp2.JSON
shp1.__dict__ != shp2.__dict__
not shp1 is shp2


Even if I read the same feature from the same feature class twice, they will not be the same.

Although one may assume that the geometry is the same, since we are comparing objects, these objects are consuming different parts in memory and for that are considered different. Only if it's the same instance of an object it will test equal.

Kind regards,

Xander


Hi Xander,

that makes sense! Thanks for the explanation and help, i flagged your response as an answer.
0 Kudos
NeilAyres
MVP Alum
But why not just use the .equals geometry method?
Like :
if ogeom.equals(mgeom):
    # do something....

http://resources.arcgis.com/en/help/main/10.2/#/Geometry/018z00000070000000/

This is a 2D comparison, ZM values are ignored (come on esri, when are these tools going to be truly 3d aware..)
Cheers,
Neil
0 Kudos
BruceHarold
Esri Regular Contributor
Hi

The Data Interoperability extension provides some transformers for geometry comparison, such as Matcher and ChangeDetector.
You can round coordinates to soften the comparison too.

Regards
0 Kudos
NeilAyres
MVP Alum
Bruce,
Data Interop has some really clever stuff in it, but it is a little hard to get your head around.
Those FME guys think totally different to you esri people!

I have only used it in some relatively simple applications like translating CAD to geodb.

Could you give us some examples of how this geometry comparator could be used in an etl tool?

Thanks,
Neil
0 Kudos
BruceHarold
Esri Regular Contributor
Hi

Well, for example, the Matcher can find geometries that are non-unique, are unique, or are a single copy of non-unique geometries (and also optionally consider attributes during comparisons).  ChangeDetector finds Adds, Deletes and NoChanges like SDE delta tables require, with the same flexibility over checking geometry and/or attributes.

Regards
0 Kudos