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.
Accepted Solutions
