Latest Contributions by Bud

Regarding the Densifiy() function in Arcade: It looks like we only have the option to densify using maxSegmentLength. We don't have a way to densify using an angle. Could ESRI consider adding the option to densify using an angle too? ... View more

Curves can be a headache when working with features.  Idea: Could an optional property be added to feature classes that would allow us to prevent users from creating true curves in polylines? Related: True Curves = True Evil ... View more

 What are the pros & cons of database triggers vs. calculation attribute rules?  Example: a trigger or calculation attribute rule that would modify the M-values of polylines after edits (in real-time). SDE.St_Geometry; Oracle 18c; versioned with moving edits to base   Database Triggers: Pros: Don't need to worry about users locking data -- which seems like it would be a problem with calculation attribute rules. Lots of functionality available in the DB: There are more St_Geometry functions than there are Arcade functions. And SQL has a lot more functionality in general than Arcade. Oracle trigger functionality will never be deprecated. Whereas there is a chance ArcGIS functionality like attribute rules/arcade will be deprecated at some point. I know it's hard to imagine that happening in the foreseeable future, but deprecation does seem to be something that happens in Esri applications. So it's not beyond the realm of possibility. Fast performance. Cons: Only SQL developers (with SQL client software) can manage triggers.  We consider triggers to be customization...we try to avoid customization if we can. If the triggers use St_Geometry functions, then that means we are married to St_Geometry. (We've always dreamt of moving to SDO_GEOMETRY, since it has a lot more functionality, including linear referencing functions. And Oracle Spatial is now free. So if we wanted to switch to SDO_Geometry, we would need to consider how much it would impact any existing St_Geometry-based triggers.) No access to true curves information -- since it's hidden in the CAD BLOB. Although, Arcade doesn't seem to be much better. Accessing all of a feature's vertices is difficult.  Calculation Attribute Rules: Pros: Anyone who's a data owner can make attribute rules right in the application. No need to be a SQL developer. Although, basic JavaScript skills are still required. I wouldn't consider attribute rules to be customization, which is good. (There is a benefit to putting logic in the application, where it is visible and accessible to everyone.) Not specific to a certain database vendor or spatial data type. Easily prevent a field from being edited. I imagine Esri would be quick to provide support for a problem with attribute rules. And reluctant to provide support for DB triggers, especially on versioned data. Editing related FCs is relatively straightforward. "Rules can be targeted for specific subtypes in the rule definition. This is helpful when you want a rule to only apply to a subset of features in a dataset." Link We can use attribute rules to enforce domains Cons: Can't manage attribute rules if data is locked. I imagine a table would be locked if even a single user has the table in their map. I'm a data owner, not a geodatabase administrator, so I think that could be a pain. Arcade has limited functionality -- for example, geometry has limited functions and properties.  There is a chance attribute rules/arcade could be deprecated at some point. We saw that happen with Python add-ins. People lost a lot of work when that happened. Performance might be relatively slow -- for batch scenarios. Note: Attribute rules require a GlobalID field. That's not really a problem, just worth noting. No direct access to true curves information. Polylines get automatically densified (similar to ST_Geometry). Arcade doesn’t handle nulls properly. We can't develop scripts in a proper IDE -- and test them right there in the IDE. Batch calculation attribute rules seem clunky. They have lots of very specific requirements: the FC must be in a feature service, the feature service must have validation capability, and the FC must be branch versioned. For my notes: Batch calculation rules are not to be confused with a scheduled job that calculates an entire field. Batch calculation rules are more about deferring slow edits until later. What do you think? What did I miss?     ... View more

To anyone who's interested: Oracle Spatial is now free (as of December 5, 2019). Oracle Advanced Analytics and Oracle Spatial and Graph Licensing Change Effective December 5, 2019, Oracle Advanced Analytics (OAA) and Oracle Spatial and Graph (OSG) options are included with Oracle Database. This affects Enterprise Edition, SE2 and Database Cloud Service (DBCS) Standard Edition and Enterprise Edition.  This licensing change encourages and enables more customers and prospects to use the full breadth of Oracle Database. Technologies like machine learning, graph analytics, and spatial intelligence should be part of almost every modern application, and Oracle believes that these technologies should be broadly available to all Oracle customers. While these capabilities are widely used today, the added cost of the database options have prohibited adoption for some customers. The removal of cost as a factor, combined with recent additions of developer and data scientist-friendly Oracle Machine Learning Notebooks and self-service tools like Spatial Studio with Oracle Autonomous Database, offers a more all-inclusive data platform for developer and data scientist communities. That's a big deal for organizations like ours. We currently use the St_Geometry spatial type, but St_Geometry has some significant limitations like the lack of a GetVertices function and the lack of linear referencing functionality. Moving to SDO_Geometry / Oracle Spatial would solve those issues. Hopefully that's helpful to some people. Oracle didn't seem to advertise that change -- so a lot of people didn't know about it (including us, at first). Cheers! ... View more

I'm a data owner in an Oracle EDGB, but not a geodatabase administrator. When I want to modify the design of my tables via ArcMap/ArcGIS Pro, I spend a lot of time coordinating with users and geodatabase administrators to get them to remove locks on the tables. It would be better if the geodatabase administrator had a way to optionally allow me to remove locks on my own data. Could Esri consider adding functionality that would allow data owners to remove locks on their data? ... View more

It would be helpful if ESRI could add a hasCurve geometry property to Arcade. Use case: When using Calculation Attribute Rules to update the shape column of features, it would be helpful if we could check if polylines or polygons have true curves or not.  https://developers.arcgis.com/arcade/guide/types/#polyline Thanks. ... View more

It would be great if there were an easy way to update the geometry of existing features in real time / after an edit is made. It would be the equivalent of a DB trigger, but using logic similar to the Python field calculator script below: #Updates the vertices of existing features def new_shape(geom): spatial_reference = geom.spatialReference geom = geom.densify("ANGLE", 10000, 0.174533) parts = arcpy.Array() for i in range(geom.partCount): part = geom.getPart(i) points = arcpy.Array() for j in range(part.count): point = part.getObject(j) point.M = geom.measureOnLine(point) points.append(point) parts.append(points) return arcpy.Polyline(parts, spatial_reference) Currently, there doesn't seem to be an easy way to do that in ArcGIS Pro, without customizing via a .NET add-in. And unfortunately, it's not possible in the DB either, since the SDE.ST_GEOMETRY (Oracle) functions are too limited. ... View more

The answer in this post describes it best:  Why does "for point in part:" work in a standalone ArcPy script, but not in the Field Calculator? The difference in behavior is due to the fact that objects within geoprocessing tools are not the same as objects within ArcPy. The pattern of directly iterating over items in a container, for point in part:, is a Python use pattern that is implemented in most ArcPy classes but not in ArcObjects classes being used by geoprocessing tools. The geoprocessing array does not implement the __iter__ special method while ArcPy Array does implement it. Idea: Could ESRI please enhance the geoprocessing array so that we can directly iterate over items in a container? Examples: for part in geometry: for point in part: Thanks.   ... View more