Latest Contributions by RichardFairhurst

‎07-08-2024

After further investigation, the strange behaviors I was observing all seems to be due to using a corrupted project. Bringing the data into a fresh project seems to have eliminated the issue with the true curves. The behavior was primarily being observed in ArcGIS Pro. I am now no longer as certain that the exact same behaviors were appearing in ArcMap, or if I was assuming they were on the basis of some behaviors that I may not have investigated as thoroughly as I thought. Bottom line, if a project begins to act strangely try building a fresh one.

‎07-04-2024

During preparations for migrating to a Parcel Fabric, I am examining the results from the Simplify by Straight Lines and Circular Arcs (SLACA) tool in some detail. I have several instances of strange results that I want to discuss with Esri technical support to see if these are expected behaviors or more likely signs of bugs. I am using ArcGIS Pro 2.9 and ArcMap 10.8.1. This is an example of an original densified polyline that makes up part of a polygon boundary shown next to the results of running the buffer tool on the same polygons with a negative 1-foot buffer (-1’). Everything is as expected. The dark red line below shows the output of the SLACA tool using a 0.5-foot distance tolerance allowance from the polyline edges. The curves generated are clearly farther than 0.5 feet away from the original polyline edges (exactly 5’ offset rather than 0.5’ offset in the most extreme case as far as I can tell) and visibly cross into the -1’ buffer polygon. However, when I use the Select by Location tool to find the set of SLACA lines that intersect with the buffer polygons, none of these lines are selected. I created a copy of the SLACA lines and ran the Densify tool using the ANGLE option to only alter curves with a vertex placement at every 0.5-degree change. The output line in purple is nearly restored to the original form of the polyline before I ran the SLACA tool when it did not intersect with the buffer polygons. This is apparently the way the radial bend/curve geometry is being interpreted by the Select by Location tool which would explain why that tool did not identify any intersection between the two features. The Densified Output Shown By Itself The Original and Densified Polylines Overlaying Each Other. When I build polygons using the SLACA lines the output is visibly identical to the SLACA lines. If I select one of those SLACA polygons (the bulb in the center of the picture) it looks like this relative to the negative buffer polygons: If I run the Select by Location tool using this selected polygon to select all intersecting buffer polygons, it only selects the buffer polygon that makes up the center of the bulb and nothing else. This would seem to indicate that there are bugs either affecting the depiction of the radial bend/curve on the screen so that it does not accurately represent the underlying geometry formula being stored with the feature or an error in the way the geometry formula is being processed. I think it is most likely that the screen depiction is not an accurate representation of the underlying geometry formula being stored with these features, but either way the disconnect between what the user sees and how the feature behaves using standard geoprocessing operations clearly will cause confusion for the viewer and the analyst (like it did for me). The good new is that apparently the fundamental true curve geometry being stored in the feature is correct within the geoprocessing tolerances I set using the geoprocessing tools and is not apparently being corrupted by any of the geoprocessing steps I did. Otherwise the Densify tool could not have created an output that met my tolerance criteria and virtually restored the original shape. But the bad news is that the depiction of the true curve is visibly distorted in a way that would lead the user to believe that the geometry has been corrupted to not match the tolerance settings. Additionally, interacting with the geometry on the screen behaves as though that distortion being depicted is really there, i.e., the user has to click on what they see on screen to identify the feature they are viewing, even though in reality the coordinates being clicked would not touch the underlying geometry. If the screen depiction and interactions were corrected to actually match the stored underlying geometry the geoprocessing tools are actually generating, this would likely resolve many of the frustrations users have expressed over the years about how true curves behave. Additionally, only a relatively small subset of curves are exhibiting this behavior. That suggest that this is only affecting one or perhaps two subroutines of the drawing module that are only triggered under specific circumstances. This would explain the seemingly random appearance of gaps or overlaps on screen in the aftermath of inputting geometry that should perfectly align, because the behavior is not universally occurring. As proof that this is the case is the fact that no gaps/overlaps were created between any true curves when I created my polygons using only a single polyline to define the shared boundary between every left and right polygon, whether the boundary contained one or more true curves or not. Artificial gaps/overlaps can only be created when separate polylines define the shared boundaries between two polygons and can be depicted using different drawing subroutines. Such randomness leads users to mistrust the results even more than an easily explained universal error that everyone understands, because it is both harder to detect/predict and harder to explain. But in reality this means to me that the overall routines involving true curves are trustworthy and the effect is actually less damaging to our actual data outputs than what we feel we are observing. The correction of this behavior should have a much greatly impact on user perceptions of the trustworthiness of true curves than it is actually having on the true curves themselves in reality. At the same time, this bug may never be fixed. The performance requirements of the Drawing module and the Geoprocessing module are so different that any resolution of this bug that results in a noticeable degradation in drawing performance will likely not be implemented. The number of users that would tolerate a noticeable drawing performance drop is certainly far less than the set of users that would continue to tolerate the production of these small sets of features with these apparent distortions and geoprocessing behavior disconnects. This geometry appears and performs the same way in ArcMap and ArcGIS Pro, so this seeming bug has apparently not been detected or has been detected and rejected from being fixed since the original incorporation and implementation of true curves in Esri's products.

‎05-23-2024

Without knowing your data or what field is being referenced in the field list it is hard to determine the cause of this behavior. Can you confirm that the field in your field list for the update cursor is never Null? If any record contains a Null value in the first field in your list, the behavior is what I would expect. Potentially, you need to add the ObjectID field to your update cursor field list and use a modified index expression for the update loop to avoid updating that field, and then only use that field index in your output for the condition of an unmatched record. In any case, without the full field list and a clear understanding of what values are possible in the update target key field you are referencing, I can only guess at what is causing this behavior. However, there are ways to modify the code to accomplish what you want to do, but they may require a little more sophisticated field index handling in the code than the relatively straight forward examples I provided in my Blog. I often build a new dictionary in the condition where records are unmatched and iterate through it after the update loop is finished. I use multiple loops frequently to process an update cursor, followed by looping through a dictionary of records for an insert cursor, followed by another loop of another dictionary with an update cursor that deletes records to acheive a complete update, adds and delete synchronization process of a target to match a source. Each of these loops have to be kept separate to avoid causing locking conflicts. I also include logic to not touch records that are validated as already synchronized to avoid the performance hit of doing unnecessary edits with my cursor processing, which is slower than reading and comparing a record in memory. Rich

‎05-20-2024

As an illustration of a common workflow I do with the ArcMap Attribute Transfer Tool, I need to reshape building permits which were originally created as overlapping shapes based on the underlying common lot, because at the time of intake the condo parcels did not exist. I need to resshape these permits to match the final condominium parcel. In the picture below there are 10 overlapping permit shapes and each condo parcel overlaps a single common lot parcel within the same feature class. Without the ArcMap dialogs, this task would be nearly impossible, but with them it is easy to match up the legal descriptions contained in the permits to the desired condo lots. The final permit shapes. The ArcMap Transfer Attribute Tool dialogs are the key to this entire workflow which results in a dramatic increase in the resolution of my permit data and greatly enhances my ability to understand the arrangement of the permits that can lead to better analysis results and opportunities. If I used the ArcGIS Pro Attribute Transfer Tool I would have to first filter out the common lots as source features, since they have the lowest object ID and would prevent me from selecting the condo lots as my source feature. I then would have to select every source feature in the order of the object IDs of the target features to match them up correctly rather than by the logical and natural arrangement of the legal descriptions of the source features. Being forced to know the order of the target features that ArcGIS Pro will pick in order to select my source features operates exactly backwards to the way I need it to work, which should naturally be driven by the source feature I choose, not the target feature it will force me to choose. ArcMap does not require me to work through the features in the random order of the target permit Object IDs, nor does it require me to take any preliminary steps to filter out the source common lots with lower ObjectIDs before I can start editing. I can simply choose the desired condo parcel from the source dialog and the desired permit from the target dialog in whatever order makes the most sense to me (in this case the order of the condo lot numbers) rather than the arbitrary ObjectID order of the target permits. It is typical in ArcMap for me to tackle workflows like this involving hundreds of overlapping features in my target feature class. The amount of forethought I would be forced engage in and the number of QC steps I would have to add to prevent errors to accomplish the same task in ArcGIS Pro seems intentionally designed to make my head hurt or to prevent me from even attempting to enhance and maintain my data in the way that I want it. This workflow alone makes it impossible for me to justify taking advantage of any ArcGIS Pro enhancements that would block my data from being backward compatable with ArcMap, since none of the enhancements Esri has provided is as vital to my data's usefulness and integrity as this ArcMap Attribute Transfer Tool behavior.

‎05-20-2024

Another important aspect of the dialog behavior in ArcMap is that when the user clicks an item in the list in the left-hand pane, the feature in the map flashes. This allows the user to visually confirm that they have selected the correct item in the list that they want the transfer to affect before they commit any change by hitting the OK button to proceed. The current behavior of the ArcGIS Pro tool carries with it the strong potential for silently introducing data corruption and confusion rather than being reliable as one of the primary tools for correcting it, and for that reason is virtually worthless for replacing any of my ArcMap workflows that rely on this tool. Additionally, as it currently stands, ArcGIS Pro has no alternative editing workflow that can serve as a passable substitute for the Attribute Transfer tool provided in ArcMap.

‎05-20-2024

Using Python in the Field Calculator is notorious for this type of troubleshooting. Knowing which row it failed on would speed up the process of correcting the Python expression or refining the record selection to avoid triggering the error and having the calculation stop working midway through the calculation.

‎05-15-2024

I suspect the example from the Riverside County parcels data probably caused some confusion. That is because the Book and Page fields actually represent the Recorded Book and Page from our Recorder's office for our Tract or Parcel Map recordings. They have nothing to do with the Book and Page of the Assessors Parcel Number. In fact there are no fields in the parcel schema that directly contain just the Assessors Book or Page of the parcel. To correctly extract the Book and Page of the Assessors Parcel you should have instead parsed the first 6 digits of the Name field (Book is digits 1-3 and Page is digits 4-6) and done the feature selection based on an SQL expression of: "NAME LIKE '" + Name6Digits + "%'" then you could take the max NAME value of the set of returned features and increment that parcel number by 1 to correctly generate the next parcel number in the sequence based on the parcel that the user clicked. Arcade and ArcGIS Pro are actually especially useful for this data because they allow me to use parsing expressions to generate symbology for this data based on the Assessors Book, the Assessors Page, or the Assessors Book and Page without any need to create fields that directly contain any of those values. In ArcMap I would have alter the schema or create a view that generated actual fields for those parsed values to be able to symbolize the data based on them. Arcade can also convert the original string value of the NAME field to numeric values so I have the option to display the symbology based on the range of numeric values rather than being limited to only using unique value symbology for a set of discrete string values.

‎01-31-2024

I agree about the parentheses. As my original post indicated, the code was untested. The post was intended to show the structure of how I typically tackle this kind of problem, but I must not have had time to design a real world test case to do an actual debug of the code at that time. Anyway, I hope you have gotten what you needed.

‎01-31-2024

As I recall, the sorted function may fail if any value it is trying to sort is None, since the sorted function must compare all values to each other to determine the order of the values, and None cannot be compared to other actual values the way that underlying function is written. Since one of the fields making up your tuple key is a date field I imagine it can contain None values. In any case you could print the keys prior to the sorted function to determine what the actual key values are to see if this may explain the code behavior. You can try using a value substitution in your list comprehension as shown in the top reply to this post: https://stackoverflow.com/questions/30976124/sort-when-values-are-none-or-empty-strings-python

‎10-06-2023

Thank you for implementing this enhancement and the video demonstrating how it works. The behavior is much more like the way the Create Features template works and it makes it much easier to quickly create a set of single course features that all need to be classified using the same attribute/symbology.

‎09-30-2023

@MichaelVolz I have not used services in any of my workflows and am retiring next week, so you will have to do the experimentation on that yourself.

‎09-30-2023

@MichaelVolz I have not done a lot of experimentation to determine the best available options for overcoming this problem under the current ArcGIS Pro limitations. I can say none of the options appear to be worth the effort unless the tool is transferring the shape of the source feature to the target or the number of attributes being transferred is very large and difficult to transfer using standard manual value copy and paste operations between attribute tables. I have found that the tool respects layer definition queries, so if a query can be written to ensure that the desired source or destination feature is available to be clicked and all other overlapping features are filtered out is a possible solution if the user is careful not to click the boundary of multiple features. This assumes the user anticipates that overlapping features would otherwise occur and can figure out a query that ensures only a single desired featured is clicked. The tool won't alert the user if they actually still had overlapping features exposed to the tool in their layer, so it is wise to first verify that only the desired features are clicked using the Explore tool first before doing any transfers. Some suggested definition queries that may be useful for restricting the available source or destination features include setting the area or length of the features to be less than or greater than a certain size or setting the ObjectID to be above a certain value. Other query options would be specific to the data the user is working with. For example, in some cases setting the available features to be above a certain date in a date field or greater that a certian alphabetical value in a text field could work. The user still has the responsibility to verify that only the desired source or destination layers are selectable and only the desired destination layer is editable before doing the transfer and should avoid having more than one tranfer set up configured at a time. If I discover any other options, I will post them here, since even if Esri adds equivalency to a future release of ArcGIS Pro they won't implement it in any of the other releases for users that are not ready to update their release.

‎09-30-2023

I also should mention that if multiple Attribute Transfer mappings have been set up that the number of dialogs that can appear for both the source and destination features can increase if the user cancels these dialogs to bring up another transfer mapped feature set. Pressing the escape key can also cycle through the available source features when a single source feature is clicked and the dialog doesn't appear, but this is not true when a single feature is clicked in the first available target layer. This behavior can also occur when a feature class in the transfer mapping set up is used for multiple layers containing different definition queries which can lead to multiple dialogs appearing if the user cancels any of the dialogs and features in any of the other layers were clicked. The dialogs appear in the Table of Contents order of the available sources or destinations beginning with the top most layer and continuing to the lowest layer clicked that is used by the transfer set ups. It may be difficult to replicate this behavior in a single dockable window, which is typically the favored approach for tools in Pro as opposed to using multiple dialogs, which is the favored approach in ArcMap desktop. However, in order for true equivalency to be achieved, these behaviors are additional requirements that the ArcGIS Pro version of the Attribute Transfer tool needs to provide. Obviously as the complexity of the transfer set up configurations increase, the user must assume greater responsibility to understand the tools possible behaviors and spend more time controlling the selectable layer and editable layer settings to manage their edits, but without the behavior I described in my original post, the tool becomes next to impossible to use when multiple features are clicked in a single layer in ArcGIS Pro even with the absolutely simplest transfer set up configuration in place.

‎09-28-2023

The Attribute Transfer Tool behavior in ArcGIS Pro is not equivalent to the behavior of this tool in ArcMap Desktop. The tool behavior is only equivalent when the user's clicks on a single feature for both the source and the transfer targets, in which case no dialogs appear in either program. However, if the user ever clicks on more than one feature for either the attribute transfer source feature or destination feature in ArcMap Desktop, a dialog listing the features by their layer Display tab expression that provides access to a list of feature attributes appears to allow the user to select the exact feature they want to use as the source or destination feature. Clicking on more than one feature can occur when a user clicks on the boundary between two adjacent features in feature classes that aren't designed to have actual overlapping features and can't be avoided in feature classes that are designed to have overlapping features. An example of the dialogs that appear in ArcMap Desktop when more than one feature is clicked for either an attribute transfer source feature or destination feature is shown below: In ArcGIS Pro when the user clicks on more than one feature for the source or the target no dialogs appear and the tool always uses the feature with the lowest ObjectID to do the transfer. If the user didn't want to use the feature with the lowest ObjectID for either the source or the target, the tool behavior nonetheless does a transfer based on that rule and results in data corruption. The ArcGIS Pro version of the Attribute Transfer tool needs to provide an option for the user to choose the source or destination feature they want whenever they click on more than one feature that provides the same functionality that the ArcMap Desktop Attribute Transfer tool dialogs above provide.

‎09-09-2023

The overall file geodatabase is still compatible with ArcCatalog/ArcGIS Desktop, but the individual feature classes and datasets within it can be rendered incompatable with the enhanced features listed by Ayan. While all editing has to be performed in ArcGIS Pro to take advantage of the enhanced capabilities as intended by the data designer, it is still possible to create a simple feature class in that file geodatabase or in SDE that duplicates the schema without the enhanced capabilities and use the Truncate and Append tools in ArcGIS Pro to create a feature class that can be opened in ArcCatalog/ArcMap for a version of the feature class used for viewing publication only purposes. Of course it then has to undergo scheduled updates to periodically be synchronized with the edit version thereafter and cannot otherwise remain current with the edit version.

Online Status	Offline
Date Last Visited	a week ago

My Ideas

Latest Contributions by RichardFairhurst

Re: True Curve Likely Bug

True Curve Likely Bug

Re: Turbo Charging Data Manipulation with Python Cursors and Dictionaries

Re: Attribute Transfer Tool Equivalency in ArcGIS Pro

Re: Attribute Transfer Tool Equivalency in ArcGIS Pro

Re: When GP tool throws an error, indicate what row/ObjectID the tool got stuck on

Re: MeetUp: The Use of Arcade With The Parcel Fabric

Re: Custom Sort Fields and Iterate through to Assign Sequential Sort IDs

Re: Custom Sort Fields and Iterate through to Assign Sequential Sort IDs

Re: Allow me to choose the editing template of the starting course of the Traverse tool.

Re: Attribute Transfer Tool Equivalency in ArcGIS Pro

Re: Attribute Transfer Tool Equivalency in ArcGIS Pro

Re: Attribute Transfer Tool Equivalency in ArcGIS Pro

Attribute Transfer Tool Equivalency in ArcGIS Pro

Re: File Geodatabase Compatibility

Re: Turbo Charging Data Manipulation with Python C...

Re: Turbo Charging Data Manipulation with Python C...

Re: Turbo Charging Data Manipulation with Python C...

Re: Turbo Charging Data Manipulation with Python C...

Re: Turbo Charging Data Manipulation with Python C...

Addressing