Latest Contributions by GIS_Spellblade

As we're all aware, there's a thousand ways to skin the GIS cat. Having an ability to measure the resource consumption of a GeoEvent Service (ideally with a pre-programmed & repeatable feed) would allow users to better optimize their GeoEvent Services and pursue different implementation strategies. This can be encapsulated into the following thought; should you pre-program your geofences or create them ad-hoc within the service? Obviously the answer is, it depends. Which is kind of a non-answer. We can whiteboard and conceptualize different ways to accomplish a task and list likely considerations but most users will not have a great understanding of which operations are more performant. While there is an argument for, if it works, it works. There are plenty of shops what would like to minimize resource utilization, a tool to measure that would help them achieve that goal through better prototyping. ... View more

The current service designer has extremely limited layout controls and are almost useless for organizing flows. This idea is to suggest some level of parity with the ArcGIS Pro Model builder in terms of Groups and Auto Layouts. Current State of GeoEvent Server: Current Layout Controls Proposed to have similar functionality as model builder: https://pro.arcgis.com/en/pro-app/3.1/help/analysis/geoprocessing/modelbuilder/grouping.htm ... View more

The ability to split incoming data based on groups or geotags seems a fairly standard process-- --especially if you are trying to populate downstream applications with the ability to filter based on a single attribute. Since much of the data streams are outside of a user's control, these processors are invaluable to split up data into a way that is usable within the downstream apps (experience builder, dashboards, etc.) which are not well-designed to ingest multi-categorical data. Since this tool is already Esri supported, let's add it into the standard installation and allow users to utilize it without the need to install the GeoEvent SDK. https://www.arcgis.com/home/item.html?id=68238a93e5fd4043ad0bbb501b265566 https://github.com/Esri/field-splitter-for-geoevent https://github.com/Esri/multi-cardinal-field-splitter-for-geoevent   ... View more

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