Latest Contributions by DrewFlater

The Largest Overlap option was added to Spatial Join only, as Spatial Join does a one by one operation for each target feature, where each target feature is examined to determine if any join features have a spatial relationship with that target feature. If many join features have the spatial relationship with the one target feature, Largest Overlap joins the join feature that has the largest overlap to the target feature.  Thinking about Select Layer By Location is different. Any input feature gets selected if it has the spatial relationship with any selecting feature. There is no handling about what if an input feature overlaps multiple selecting features, or if multiple input features overlap the same selecting feature. Imagine this case, where a green feature overlaps a big orange feature (id=1) and a small orange feature (id=2).   If the green feature is the input and the orange features are the selecting feature, a Largest Overlap relationship doesn't make sense - the green feature is going to get selected because it overlaps any orange features. If the orange features are the input features and the green feature is the selecting feature, first orange 1 is evaluated for a spatial relationship with green (it overlaps) then orange 2 is evaluate for a spatial relationship with green (it overlaps) -- so both orange would get selected. There isn't a mode of select layer by location that would unselect orange 2 because orange 1 has a larger overlap with a single green feature.  If you can graphically describe what your expectation is between two feature layers and how a selection could be performed based on a Largest Overlap relationship, please share the details to get this issue reopened for votes/consideration. ... View more

This one slipped between the cracks, it has been available for several release of ArcGIS Pro. The option is labeled Open messages window automatically after running a tool and is documented here. https://pro.arcgis.com/en/pro-app/latest/help/analysis/geoprocessing/basics/geoprocessing-options.htm#ESRI_SECTION1_2E90671803584D91AFD6E5A747B5C339   ... View more

@Bud the condition with duplicate OIDs caused by a 1:M join cannot be known until the data is completely read, so this is not possible to "disallow" such layers from being used as input. We have found that some tools error under this condition, while others use the first record in the set of duplicate OIDs, while others do other things. All of these specific behaviors based on different tool implementations cannot be explained in full detail in a documentation topic like you highlighted from Add Join, thus the generic "can produce unexpected results".  We have internal development enhancement issues logged to support dynamically generating unique OIDs for the case of 1:M joins, which will work around any limitations there may be for geoprocessing tool algorithms that require unique OIDs. This idea in the current state is not actionable, but if you want to change the idea or enter a new idea for some tools that you have used to support 1:M join layers as input without duplicating the OIDs, we can make a match to our internal development issue.   ... View more

@rgeorge9935 all geoprocessing tools, including XY Table To Point, leverage a system in ArcGIS Pro called the text file workspace for reading CSV, TXT, and other delimited files as a table. The same text file workspace is used when you open the attribute table in ArcGIS Pro for a standalone table with the same delimited file source. If you were to add the same delimited files to Pro, the attribute table would not recognize that the column headers are located in a different row. For consistency and code maintainability, we will not introduce tool-specific changes as you described to a tool like XY Table To Point.  Depending how you want to move forward there are two options for managing the feedback you raised in this idea: 1. Edit the idea title and label so that the requirement is more generally that Pro's delimited file/table handling should allow the user to specify the row header, and not specific to the XY Table To Point geoprocessing tool. 2. If you prefer, this specific Idea can be closed, since as-written it cannot be implemented, and you can raise a new Idea with a similar theme about Pro generally supporting delimited files where the column header is not in the first row. ... View more

The Copy tool can copy data elements between workspaces of the same type, for example copying a valid annotation feature class from one file geodatabase to another. The documentation for Copy will be clarified.  ... View more

@Bud Sweeping ideas that cover multiple functional areas like this cannot be tracked or implemented. It takes specific effort per tool to support a processing extent. I suggest you update the idea to be specifically about the tool Register with Geodatabase, which will be assigned a Geodatabase label and can be left open. If you prefer to enter a new idea to cover that, this idea will be closed.  ... View more

@MErikReedAugusta as others indicated, using SQL as the expression type for Calculate Field is the only way to improve the performance of calculations done with hosted feature services. Either the Python or Arcade options require Pro client-side calculation, which as you indicated is slower to read and write the updates to the hosted data source, compared to local geodatabase data.  The Calculate Fields (Multiple) tool also can use SQL expressions for batches of calculation, which will be even faster than running several sequential Calculate Field tools in a script.  ... View more

The idea was marked as Already Offered based on the arcpy.metadata command to delete geoprocessing history, which has been available for several releases. The enhancement in Pro 3.3 supports a UI to accomplish the same goal through the metadata editor.  ... View more

I want to bring up that the default output location for geoprocessing tools is by default set to the project's default geodatabase, but this can be configured to any location by setting the Geoprocessing Environments workspaces. A few folks that described what they want in this thread could benefit from setting their scratch workspace to their preferred location, which will make the default output paths generated in that location rather than the project geodatabase. https://pro.arcgis.com/en/pro-app/latest/tool-reference/environment-settings/scratch-workspace.htm     ... View more

@Zameskalo  @SteveCole the new idea you submitted and commented on has been merged with this existing idea, and like @SSWoodward points out it was implemented in ArcGIS Pro 3.1.  ... View more