Latest Contributions by KenHartling

Thanks Dan. Sorry for the delayed response.  I was able to reproduce the bad output with the bad inputs... I see the same bad output using 3.1, 3.1.1, 3.2 and the soon to be released 3.3. We'll do some due diligence to make sure there were no internal errors that we missed.  We will not be repairing bad geometries each time we encounter an input geometry.  All we can do is raise any errors that occur if the bad geometry causes a failure. To reiterate what I've already posted above... always ensure the input data is good before using in analysis. Checking the inputs for issues should be a step in every workflow prior to analysis. It should be a part of every data providers workflow as well.  Bad input = errors, crashes or worst case scenario bad output with no error.  Thx. Ken  ... View more

Hi Dan. There are no new requirements as far as the correctness of input data geometry.  The same high standards apply.   Bad geometry always has the possibility of affecting the processing of data, regardless of tool.   For your third question it's not clear to me what you are asking. Identical geometry can be a valid output to an overlay operation. There are tools (Find/Delete Identical) that can detect and remove identical geometry if they are not desired.  If you are referring to whether we have code in place to detect when bad geometry is being used and could potentially cause an issue... we do not. Checking and Repairing all input geometry during analysis is performance adverse and many issues may require manual intervention (In particular, bad Spatial Reference properties can cause 'good' geometry to be 'bad' and 'bad' geometry to be worse once applied during analysis. Repairing a Spatial Reference requires recreating of the feature class. See https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/geoprocessing-resolution-tolerance-and-hair/ ). If errors are thrown while using 'bad' data we catch and report the errors.  From the the doc I provide below: The onus is on the data's consumer to ensure that the feature class contains valid geometries before the data is used for projects or analysis.  Please see https://pro.arcgis.com/en/pro-app/3.0/tool-reference/data-management/checking-and-repairing-geometries.htm for the documentation on checking and repairing geometry in preparation for analysis. If you have a copy of the data prior to repair that I can take a look at it would be appreciated.  I can confirm a few things. Thx. Ken   ... View more

I would second moving from shapefiles to FGDB for very large features or very large numbers of features. Large individual features (10's of millions of vertices) can take a fair amount of time to check/repair, especially if using the ESRI method.  Sometimes using the OGC option can be faster. Large numbers of features can be processed faster if you use the parallelProcessingFactor GP environment prior to running the tools.  If you would like us to take a look at your data to see if there is anything further we can do to improve the performance against your specific data you can either attach it here or call your support analyst and submit a request with them. Doc references https://pro.arcgis.com/en/pro-app/3.1/tool-reference/data-management/check-geometry.htm https://pro.arcgis.com/en/pro-app/3.1/tool-reference/data-management/repair-geometry.htm Thx. ... View more

Our folks responsible for the tutorials had this to say about this particular data - "The course, Learning ArcGIS Desktop (for ArcGIS 10.0) was retired back in 2017. This data should no longer be used in other Esri Academy content and should not appear in any newer Pro courses. "   ... View more

I don't know who that would be... but maybe I can find someone that does know. Stay tuned... ... View more

If you are wondering how to fix the spatial reference and geometries... this article gives you the steps to follow to rebuild your feature class and repair the geometries - https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/geoprocessing-resolution-tolerance-and-hair/ ... View more

Thanks Tomek and Dan.  Definitely issues with this input data that will impact the analysis results that need taking care of.  Bad data in, bad data out. Once I repair all the issues... spatial reference, bad geometries... it appears to work as it should. Spatial Reference set incorrectly: Checking Spatial Reference... XYTOLERANCE ISSUE - NOT set to default. Current: 1.9384789092521745e-05 | Default for this SR: 0.001 XYRESOLUTION ISSUE - NOT set to default. Current: 2.423098636565218e-06 | Default for this SR: 0.0001 And as mentioned lots of geometry issues: (300+ bad geometries reported) Thx. Ken   ... View more

Thanks for reporting this.  We are unable to reproduce the issue you are reporting from the info provided so there may be something going on with the data you are using or something in the DB itself. You can contact your support analyst with the info to get in person help or if you'd like please provide a copy of your data (copy from the EGDB to FGDB should be fine to start) as well as sending us the exact parameters and any environments set prior to the running of the tool. Also of help will be the version of ArcGIS Pro you are using, the DBMS client and DBMS server versions being used. Thx. Ken ... View more

@ThomasHoman   My understanding is that the pairwise (very odd name) Buffer is just the buffer tool enabled for parallel processing. Would that be correct? This is not correct. PairwiseBuffer uses the underlying GeometryX libraries to perform buffer operations and is a completely separate algorithm.  Buffer uses something called the Topology Engine (as well as another engine under certain circumstances) to perform buffer operations. Both are enabled to work with parallel processing. Please see each tools respective documentation for details on how they use the arcpy.env.parallelProcessingFactor environment to control parallel processing. We have spent a number of releases improving the quality of the Buffer tool side/end type buffer output as well as optimizing performance for side/end type buffers when run with parallelProcessingFactor ON.  Side/End type buffers are not true buffers. When designing the PairwiseBuffer tool it was very apparent that the side/end type options should not have been included directly in the Buffer tool when they were added a few decades ago since from a geometric perspective the output of side/end type is not a true buffer and the complexity of the buffer code as a result of having added these options directly to the tool has been very problematic.   suggesting that Pairwise Buffer is in any fashion 'enhanced functionality' In our opinion the Pairwise Buffer tool does provided enhanced functionality. It uses a more up to date technology to perform the buffer operations, we are able to get it to perform much faster in many cases, we give the user control over the precision of the output buffer shapes (see Maximum Offset Deviation parameter)...  If you have a specific case of the Buffer tool using side/end type options, run with parallelProcessingFactor ON that is not running in a satisfactory manner could you please send us the data and exact parameters you are using in the tool so we can take a look and have a chance at improving these options? We'd appreciate it. Thanks. Ken     ... View more

This was implemented in ArcGIS Pro 2.6. ... View more

We will not be providing side/end types in the PairwiseBuffer tool as we feel we have provided improvements to the Buffer_analysis tool and added a new tool, GraphicBuffer, that addresses most users requests related to non standard buffer creation. Performance - Buffer_analysis can be run parallel which in many cases has improved performance drastically.  From Buffer documentation  Parallel Processing Factor This tool honors the Parallel Processing Factor environment. If the environment is not set (the default) or is set to 0, parallel processing will be disabled; parallel processing will not be used and processing will be done sequentially. Setting the environment to 100 will enable parallel processing; parallel processing will be used and processing will be done in parallel. Up to 10 cores will be used when parallel processing is enabled. The Parallel Processing Factor environment is only supported when buffering line and polygon features. Quality of output For the past 3 releases we have focused on improving the output of Buffer side/end type output. Many issues have been addressed to improve the buffer features being created when side/end type buffers are created. New tool to address most user requests for end and corner shapes GraphicBuffer was created specifically for creating non standard buffer output. Please see the GraphicBuffer documentation for more information. If you have specific end/side type cases you feel can be improved, please contact your support analyst with examples so we can take a look to see what we can do.  Thanks!       ... View more

Hi Alexander. From your description I believe we may have fixed this in Pro 3.2. https://support.esri.com/en-us/bug/in-arcgis-pro-the-pairwise-dissolve-tool-splits-certain-bug-000154784 has a description of what we've fixed in 3.2. Does it appear to be what you are describing? If you are able to provide an example I can try it in Pro 3.2 development version to verify your case it also taken care of. Thx. Ken ... View more

Thanks for confirming. Using data like may lead to other issues later in the workflow. Failures, crashes as well as workflows that appear to have completed without a tool erroring but resulting in bad analysis... having a process appear to have completed successfully when really it did not could be very dangerous to any analysis if there are not stringent checks to make sure everything worked correctly.  Every project should begin with an analysis of the validity of the data to be used (lots of doc on this), as well as an analysis at the end to determine if the analysis is working. To get a better understanding of how spatial reference properties affect your analysis you can read more at the following: https://pro.arcgis.com/en/pro-app/tool-reference/appendices/spatial-reference-and-geoprocessing.htm https://pro.arcgis.com/en/pro-app/help/data/geodatabases/overview/the-properties-of-a-spatial-reference.htm https://support.esri.com/en/white-paper/1301 Ken ... View more

Glad I could be of help. What is still a mystery is that ArcGIS Pro 2.6 and 2.7 didn't seem to mind the XY-Tolerance = 0, but 2.8 does.  Was that a bug in 2.6 and 2.7 (that happily allows my software to work correctly in those versions)? Could be two things... are you 100% sure the feature class being created by GDAL back when you were using 2.6 and 2.7 was exactly the same with an xyTol of 0? The other thing is this may have been failing silently, risking a crash. We've been working hard to plug those sorts of holes in our code to avoid the possibility of crashing. Thx. Ken   ... View more

Hi Karen, I'm a product engineer with ESRI on the geoprocessing and geometry teams. I was asked to consult on a part of the issue you are running into. The trigger to the problem is the input feature class having 'bad' spatial reference properties.  I found that your xy Tolerance was set to 0. This causes the failure. If you recreate the feature class following the the instructions here - https://www.esri.com/arcgis-blog/products/arcgis-pro/analytics/geoprocessing-resolution-tolerance-and-hair/ you should be able to fix your feature class and avoid the failure.   It would be very helpful if you could share how this feature class was created in this way with an invalid xy Tolerance Spatial Reference property.  If it was one of our tools... it would be something we would like to fix. Thanks. Ken ... View more