Latest Contributions by GIS_Spellblade

TLDR: ArcPy Cursors do not universally respect Context Managers; Add Appropriate Methods to the Cursor Class to enable graceful exits (discard, disconnect, close) as part of the __exit__() call.   Recently an Esri blog was published detailing a relatively common "gotcha" pertaining to cursors applied against a file geodatabase: https://www.esri.com/arcgis-blog/products/arcgis-pro/data-management/locked-by-another-application-using-arcpy-and-a-file-geodatabase/ The given solution was to embed a del call within a context manager (a with statement). This idea runs contrary to the syntactic sugar abstraction that is a context manager, or put otherwise, we use a context manager to not have to worry about some of the nitty-gritty of programming details like closing files and cursors. The suggested solution is problematic as it requires a user to have in-depth knowledge of what is likely an oversight due to the long-lived nature of the ArcPy library; further compounded by the lack of documentation outside of the blog's reference. https://realpython.com/python-with-statement/ This idea is to add in certain methods within the ArcPy Cursor Class to have it conform to the Python DBA Specification (https://peps.python.org/pep-0249/); while this sounds like a lot, in reality the additions would be fairly minimal and would be similar to the solution discussed in this blog post: https://dev.to/c_v_ya/sql-cursor-via-context-manager-2gc7 Having an implementation would make the ArcPy library more robust and allow the ArcPy Cursor to behave the same way regardless of the underlying data source-- --which would be the expectation for any other library, a function to behave the same way for all the inputs it is programmed to accept. This would benefit the users as they would not need to have an arcane understanding of a library that is possibly older than some of its users; they would be able to trust that ArcPy cursors comply with context managers which is a common usage pattern since Python 2.5. ... View more

I've noticed that some queries seem to be too complex within the SQL Expression Editor; previously I had issues running a calculation from a datefield that would not work on anything less than 6 months. Here's an example that I'm running into today: I have a map that needs to be updated bi-weekly, it's based on the following query: 2 week range >= and > a diff that calculates one business day turnaround according to two complaint flags OpenDate >= '2020-07-27 00:00:00' And OpenDate < '2020-08-10 00:00:00' AND (DATEDIFF(Day, OpenDate, CaseInspectionDate) - DATEDIFF(Week, OpenDate, CaseInspectionDate) * 2 <= 1 ) AND CaseReported IN ('Citizen Complaint', 'City Council')‍‍‍ Then when I go to make a simple edit, changing the string for date: OpenDate >= '2020-08-10 00:00:00' And OpenDate < '2020-08-24 00:00:00' AND (DATEDIFF(Day, OpenDate, CaseInspectionDate) - DATEDIFF(Week, OpenDate, CaseInspectionDate) * 2 <= 1 ) AND CaseReported IN ('Citizen Complaint', 'City Council')‍‍‍ It flips out like so: Pretty horrible right? Is this a bug? Now if I were limited to the GUI that would be bad. So I went ahead and used the new mp module in ArcPy, because I'm in the process of automating this map anyway: import arcpy old_query01 = "OpenDate >= '2020-07-27 00:00:00' And OpenDate < '2020-08-10 00:00:00' AND (DATEDIFF(Day, OpenDate, CaseInspectionDate) - DATEDIFF(Week, OpenDate, CaseInspectionDate) * 2 <= 1 ) AND CaseReported IN ('Citizen Complaint', 'City Council')" old_query02 = "OpenDate >= '2020-07-27 00:00:00' And OpenDate < '2020-08-10 00:00:00'" old_query03 = "OpenDate >= '2020-07-27 00:00:00' And OpenDate < '2020-08-10 00:00:00' AND CaseReported IN ('Citizen Complaint', 'City Council')" new_query01 = "OpenDate >= '2020-08-10 00:00:00' And OpenDate < '2020-08-24 00:00:00' AND (DATEDIFF(Day, OpenDate, CaseInspectionDate) - DATEDIFF(Week, OpenDate, CaseInspectionDate) * 2 <= 1 ) AND CaseReported IN ('Citizen Complaint', 'City Council')" new_query02 = "OpenDate >= '2020-08-10 00:00:00' And OpenDate < '2020-08-24 00:00:00'" new_query03 = "OpenDate >= '2020-08-10 00:00:00' And OpenDate < '2020-08-24 00:00:00' AND CaseReported IN ('Citizen Complaint', 'City Council')" aprx = arcpy.mp.ArcGISProject(r"C:\Users\gisspellblade\Desktop\ArcProjects\SolidWaste_EnergovDemo.aprx") for m in aprx.listMaps(): print(f"Map: {m} Layers") for lyr in m.listLayers(): print(f"\t{lyr.name}") if lyr.supports("DEFINITIONQUERY"): if lyr.name == "Complaint Response One Business Day:": lyr.definitionQuery = new_query01 print(f"Defintion changed for {lyr.name}: {lyr.definitionQuery}") if lyr.name == "Cose Total: ": lyr.definitionQuery = new_query02 print(f"Defintion changed for {lyr.name}: {lyr.definitionQuery}") if lyr.name == "Complaint Total: ": lyr.definitionQuery = new_query03 print(f"Defintion changed for {lyr.name}: {lyr.definitionQuery}") aprx.save()‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Which at first blush, also did nothing. I ran this several times with no resulting changes in the map. I restarted the program and still nothing. Then, I left the program closed for more than 10 minutes, and when I get back, I have these results: So now I have three questions: If I'm changing the value on lyr.definitionQuery, then I'd think it would be an over-write and not an append? and if lyr.definitionQuery is a read/write; how does one access multiple queries to appropriately delete/add what they need? the documentation here is pretty light; Alphabetical list of arcpy.mp classes—ArcGIS Pro | Documentation unless there's more detailed information lurking just past my level of google-fu Why are these values not showing up immediately within the project? and why do I need a long cold restart to view changes made with ArcPy? this is an issue that I've seen before of needing to close a project for a ArcPy-derived result to appear in previous Pro versions What's with the GUI not accepting changes to complex queries, or refusing to write them in the first place? In ArcGIS Pro 2.6 arcgispro2.6‌ arcpy #definition expressions‌ #set definition‌ #sql clause‌ #sql query builder‌ ... View more