How to calculate nearest neighbor metrics for each point in a dataset?

[Draper_GIS1]

Hi all, I'm using ArcGIS Pro licensed with spatial analyst.

The dataset is about ~100 points/GPS  coordinates. I want to calculate the nearest neighbor distance (euclidean) for each point in the dataset but am having difficulty finding a way to automate this.

The Nearest Neighbor Analysis tool takes all points in the dataset and returns an observed and expected value based off the euclidean distances for all points in the feature class. But I want to know what the nearest neighbor distance is for each point. I found the Calculate Distance Band from Neighbor Count Tool, which sounded promising because it returns the mininum, maximum, and average distances but again it does it for the dataset as a whole and only returns one set of values.

Is there a tool to automate calculating what the minimum distances are between every point within the dataset? I recognize there will not be unique values for every point (e.g., the nearest distance for point A and B might be identical if clustered closer together than other points) but I still am interested in getting this metric for each point in the dataset.

Thank you in advance for your feedback.

[DanLee]

Try Near tool with the layer as Input Features and Near Features. 

https://pro.arcgis.com/en/pro-app/latest/tool-reference/analysis/near.htm

[Draper_GIS1]

Thanks @DanLee but I have more questions than answers with the near tool. Running the Near analysis seems to change the Point_ID field? I must be missing something here.

The FID remains, but it returns a different Point_ID. Am I to interpret that the reported/returned Point_ID is the identified nearest neighbor? Or am I falsely assuming that the Near_FID field would be the returned nearest neighbor? I would like to label the identified nearest feature by the "Point_ID" field. Returning an FID adds an additional step to try and match up with the feature point /Point_ID system.

I've uploaded a couple images of the confusion. In the first image FID number "4" corresponds to Point_ID number "5" before the near analysis tool is run. After running the tool, FID number "4" is assigned to Point_ID number "3" despite having the same coordinates, the Near_FID is also reported as "3" but I know for a fact, that indeed Point_ID 4 and Point_ID 5 are in closer proximity than either are to Point_ID 3 so I'm a bit confused here...

In the second image the distances between Point_IDs 4 <--> 3 and 4 <--> 5 are shown. 4 is much closer to 5 (2.68 miles) than 4 is to 3 (5.08 miles). Also, in the image shown, 31 would be the nearest neighbor to 3, between the labeling and the distances I'm a bit thrown off.

[DanLee]

Near tool by default adds NEAR_FID and NEAR_DIST fields. In recent Pro versions (can't remember since which version on top of my head) the tool allows you to specify alternative field names.  Which version of Pro are you using? 

I cannot tell why your Point_ID field values are shifted.  Do you mind sharing your data here or with me at dlee@esri.com?

[DanLee · Accepted solution]

I just did a quick test. The result seems good to me.

[Draper_GIS1]

The Near tool as described above yields two fields, the nearest object as identified by its FID or ObjectID and the distance of that object in the same units as the input layer. This does resolve my issue and am marking the post as solved.

I am unsure why I received the altered FID/ObjectIDs shown in the screenshot. I was not able to reproduce this issue at will, perhaps for the better. One addendum that would make the solution better is if the user is able to customize the display field of the nearest neighbor output in the attribute table. For example, the field is reported as the FID/ObjectID, which are numbered sequentially from 0-N. These data are different site numbers, which happen to not be sequential. Reporting the output in FIDs/ObjectIDs instead of the data field of interest adds an additional step in matching the nearest neighbor output to the preferred identification label.

Thank you @DanLee for reaching out and providing the solution to this issue.