This is implemented in ArcGIS Pro 3.3. See Your Ideas in ArcGIS Pro 3.3 for a full list of all user ideas you can look forward to! And be sure to check out the release blog and what’s new help topic and video to learn more about all the new features and functionality in the release.
Kory Kramer, unfortunately we can't stop geoprocessing history from writing to the metadata when using Python packaged with Pro due to #BUG-000128506 Arcpy.SetLogHistory(False) is inconsistent when running in a python script in a Python 3 environment.
On the second point, based on testing reported by Esri Technical Support, exporting the metadata from Pro without Sensitive Information or Machine Names and then importing it back into Pro will not remove this information from the source metadata. We need to redact the embedded metadata.
Please let me know if you find either of these not to be the case, or have additional thoughts on point #2.
Thanks!
1. Allow users to enable/disable storing geoprocessing history in the metadata
In ArcGIS Pro, see Geoprocessing history—ArcGIS Pro | Documentation
2. In the metadata editor, allow the geoprocessing history items to be deleted in mass and one by one
It looks like in the metadata's Geoprocessing History, one could individually choose to export (or not) processes.
If the main use case is when sharing exported metadata, see Export metadata to a standard format—ArcGIS Pro | Documentation
I'll add that this could be considered a security issue by some organizations. Full file paths, including network drives, are included in metadata and some groups might not be keen on inadvertently publicizing this.
In addition, I would appreciate the option to add the geoprocessing step that was used to generate the initial feature class. This has been requested in another form, as in to carry forward geoprocessing history from input feature classes that result in new features. In my example, we'd like to see the configuration parameters for our annotation feature classes show up in the metadata without having to manually transfer them. The create annotation from feature labels tool runs, and provides the details on reference scale, cardinality, etc in the annotation layer's properties, but none of this info is included in the metadata, nor is it formatted in way that is easy to cleanly copy/paste from the feature class Properties.
Great idea. I believe the default should be on, though. I have figured out the what and where hundreds of files just from the GP history. Most of the field calc history is a waste of time to read, but the appends are useful. None of these files had real metadata (documentation), and you can't count on most people to create any metadata, especially non-GIS non-IT people.
Having realised a need for relatively opposite case, as mentioned in Allow IN_MEMORY datasets to store metadata generated by geo-processing tools , I think there could be an interim option instead of on/off switch which let users to control the amount of history to keep with the data items, say the last 20 geoprocessing actions. This history info is just auxiliary most of the time but sometimes it may become critical, particularly if a data item has a lineage related to the source items and their locations (say intersect operation applied and accompanying datasets to control source data versions, instead of rerunning a long intersect operation to make sure you used correct source datasets).
We have several Python scripts that perform daily geoprocessing tasks. Since geoprocessing history is automatically logged, the GDB_ITEMS table in our geodatabases bloats considerably and affects performance significantly. I discovered the effect on performance by first taking the workaround code suggested by ESRI and modifying it so that I could run it at the geodatabase level to affect all objects in the geodatabase (the original workaround would take a VERY long time to actually perform if I had to go to each feature class individually). Once I had cleaned up over two years of geoprocessing history from the GDB_ITEMS table of all of my geodatabases, I found that: 1) The reserved disk space for all of the SDE databases on my SQL Server dropped by nearly 11 Gb. 2) My automation scripts run MUCH faster. For instance, one job that performs a DB compression and updates statistics went from taking 4 hours and 13 minutes to taking 8 minutes! Another script that deletes several point feature classes and recreates them using X/Y coordinates downloaded from a business database went from taking 2 hours and 25 minutes to taking 15 minutes. Having some method to manage logging to the GDB_ITEMS table would be an excellent enhancement!
Inicia sesión para publicar, seguir contenido y más. ¿Nuevo aquí? Regístrate gratis.
