I have a point featureclass of Valves. I was asked to create a script to notify our team if the geometry has changed at all, and at the end of the day send a notification. So it would find any point moved, or existing points that have been deleted, or new points created. Create/update/delete.
I created this script. It uses Feature Compare, with the Geometry_Only option. We don't care about tabular differences, just geometry. It began to run each day. We noticed it was including thousands of records that clearly had not moved. The sending email etc and overall logic are sound. It exports the Valve point layer from SDE each day and tacks on the day's date to the filename. kevinsagis/email_Notification_When_Featureclass_Changes: send email notification when an Esri featur...
I called Support. They thought it should work, too. We tested with the Feature Compare tool in Pro 3.3. https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/feature-compare.htm Same thing. Seems like it includes way too many features. I tested by moving just one point, between two copies of the layer otherwise identical. Began experimenting by Omitting fields. That seemed to have the opposite effect of not finding changes. Which doesn't make sense anyway since I'd think omitting fields or not, should not matter, if it's Geometry_Only option is True. Thoughts, all? I liked this tool because its output is a report of all the features. I elected to use GlobalID as the unique field linking them. Apparently the Support analyst said if the number of features between the two layers differs this causes issues. Well what is the point for a Geometry comparison option? Of course the number will differ if it's two copies of the same layer and over time features are added.
Before I cut over to using another tool I was wondering if in fact I'm "doing it wrong" or if I am not understanding the Feature Compare and it was never intended to compare geometry.
If either of these is true, and Feature Compare simply won't work, I'll refactor the script and publish an update to share with everyone. I found a thread which suggests Data Interoperability Extension has a tool Esri published which would do exactly this. https://pm.maps.arcgis.com/home/item.html?id=834e3ba8034e4e7f83d9fc4fcfb5713c However, we don't have that Extension, at least not yet.
I was hoping maybe I am just not understanding Feature Compare? It would be surprising if there was not a built-in way to compare two copies of a layer and flag which feature or features are different, spatially (Based on having the same ID like a GlobalID or unique feature ID primary key) Thanks all!
UPDATE: this logic could be useful in another way, to almost every customer. If you have versioned SDE databases, for example multiple analysts editing; or field workers with offline replicas which post as versions. Let's say you want to QA and review changes between a version and the Default. Well reconcile will show Conflicts. But what about new features? Reconcile won't show that. To my surprise, the data team in support noted that there's no way to know this. You just have to trust versions and blindly post them into the Default. However I realized this is the exact concept as above. Rather than compare a feature class to a copy of itself from a previous day, we are comparing a feature class, to its archived state from a previous archive snapshot. So we can see 'what changed and where'. "Change Detector" and Interoperability should work. I hope I will be able to acquire the Interop extension so I can test this. But ... this would solve that problem for every Org with SDE and versions. If you want to QA data edits, especially on versions coming in from the field, and know what changed so you can spot check it. (all changes, not just conflicts. So, you can see where new features were created.) More to follow, after testing. In a perfect world, Reconcile would show what changed and where; and Archiving would let you roll back. I'll suggest to Product teams at UC. Apparently archiving is just for viewing, and is a spatial view where it combines the shape field and the delta tables; but, with SQL Server Management Studio access; one could restore a DB backup if there were a lot of changes, or just copy and paste out of the 'correct' archived version with good data, directly into Default, to fix a data edit error. And so, Archiving, in combination with Change Detector look like the perfect way to QA version posting in SDE.
