Spatial Join by Attribute (Match Fields)

3301
9
06-24-2022 04:56 AM
Status: Implemented
Labels (1)
MiguelMartinezYordan
Frequent Contributor

When doing a Spatial Join to get attributes from a line and transferring them to the point, sometimes the point is closest to the wrong line, and the wrong attribute is passed to the point. Example, a line representing a road has a lot of segments with traffic volume data (ADT). And you have a point layer with the name of those roads. The line layer also has the names of the roads, but each road has a lot of segments with ADT. You want to transfer the closest ADT value from the road (line) to the point. But, there is an intersecting road with other name that is closest to the point. You want to be able to only transfer the closest ADT value from the line to the point without taking into account other roads. This will be awesome if you guys can develop a Spatial Join by Attribute in the next patch of ArcGIS Pro 3.0

As an example, there is a geoprocessing tool that do this. Is call the Align Features. This tool align a line from one layer, spatially to other line layer taking into account the same attribute field so a line only align with the correct line and not other. So if you can add the Match Fields from this tool to the Spatial Join it will be great!!!

9 Comments
AlfredBaldenweck

So if I'm reading this right, the idea is to use fields for an extra validation step? A combination of Select by attribute and Spatial join, in which you select by attribute first, then spatial join?

DrewFlater
Status changed to: Under Consideration
 
MiguelMartinezYordan
Hi, you will be doing the Spatial Join only but with an additional capability to Match Fields. Like the Match Fields in the Align Features tool.
[cid:image001.png@01D88B98.853236A0]
MiguelMartinezYordan
EXCELLENT!!!
[cid:image002.png@01D88B9E.7C729F90]

MSeanHills

I agree this is a much needed enhancement to this tool.  For instance,  When trying to aggregate pavement condition to HPMS sections without further dissection of sections, the Merge Rule 'Join' allows a delimited list of pavement  condition.  Inevitably the tools assigns data from all 'Shares a line segment' relationships.  An inaccurate, unuseable result.  A useful result would be only where RouteID of pavement layer matches RouteID of HPMS Sections.

RoseF
by

Sounds like a great idea to me that I could potentially use! Right now, I think my approach would be a Definition Query on the lines (roads) and then do the Spatial Join. It might also work with a Select by Attributes on the lines instead of the Definition Query but I haven't tried this in Pro yet, so I don't know if the selection on the lines will work. I'm only thinking it worked many moons ago in ArcMap.

MatthewLeonard

This would be immensely helpful to me. Another example: Say you have two sets of point features, and you want to join attributes from the nearest point in the other set, but only if a certain attribute value matches. The nearest point of all may not have the matching value, so you only want to join the one that does. @DrewFlater please make this happen! @MiguelMartinezYordan excellent suggestion!

DrewFlater
Status changed to: In Product Plan

The ArcGIS Pro 3.2 release will have a new Match Fields parameter on the Spatial Join and Add Spatial Join tools that can be used to accomplish what is described in this issue. When looking at set of join features that match the desired spatial relationship to a target feature, the match field values will be evaluated to see if they are the same. If the match field values are the same, the spatial join will be made. If the match field values are not the same, those join features will be excluded from the spatial join.

DrewFlater_0-1692654776334.png

 

 

MargaretCrawford
Status changed to: Implemented

This Idea has been implemented in ArcGIS Pro 3.2. Please check out this blog to learn more about how to use the new Matching Attributes parameter in Spatial Join & Add Spatial Join.

Also, see the What's New documentation for more new features in Pro 3.2.