0

Background:

At 10.8.1, ArcMap attribute joins run without complaint, yet generate incorrect results.

As shown in the screenshot below, the tables component (parent) and chorizon (child) are joined 1:1, each via the field cokey.

Both are file geodatabase attribute tables, stored in the same FGDB.

I have conducted the join using two different techniques:

  1. From the attribute table window dropdown > Joins and Relates > Join... (both with the Keep all Records and Keep only Matching Records options, always using the Validate Join button)
  2. Using the Add Join tool (with Keep All Target Features unchecked)

Problem:

When reviewing the output, I notice that some of the child table values are incorrect following the join. For example, the screenshot shows two selected rows where the joined sandtotal_r values are different than the source table (6.8 vs. 63.7 and 13.5 vs. 29.5). In fact, 6.8 and 13.5 do not exist anywhere in the source attribute table!

The incorrect values always appear, regardless of the join method used.

When I conduct the join using QGIS 3.18.2, the output is correct. Thus it appears that the problem is with ArcMap, not the data.

Any thoughts?

@FelixIP suggested I try the Join Field tool, which worked correctly. However, the original problem still exists. I suspect a bug.

enter image description here

Improve this question
4
  • 1
    Have you tried Join field? It will update first table with fields of your choice from second
    – FelixIP
    Commented Apr 26, 2021 at 4:48
  • 3
    Have you confirmed that the cokey values in the chorizon table are unique? Sort the table by cokey (double click on that column header), and scroll down to that value(s) again to confirm.
    – Son of a Beach
    Commented Apr 26, 2021 at 5:37
  • 1
    That's my first thought (@SonofaBeach) the values are not unique. Another way to see if they are not unique is to run the summary statistics table, count on ObjectID and case is cokey. Advantage of this is that you can sort by count and find all the duplicates.
    – Hornbydd
    Commented Apr 26, 2021 at 12:19
  • Which soil survey is this, so I can try to replicate the problem?
    – Bjorn
    Commented Apr 26, 2021 at 12:29

1 Answer 1

Reset to default
2

I queried one of my friends at the National Soil Survey Center. Here is their response:

There isn’t a bug.

The problem is that SSURGO is a relational database and you can’t use simple joins in ArcGIS on any of the tables with the exception of ‘muaggat’ and ‘mapunit’. All of the other tables are one-to-many. This issue is discussed in both the gSSURGO and SSURGO documentation.

They can also see the relationships by clicking on a soil polygon with the Identify tool. The Identify window will allow the user to drill down through the mapunit->component->chorizon->.. tables and see the related records that way. The only way to generate a soil map for a horizon-level soil property is to run some sort of summarization process. The ArcToolbox on the following gSSURGO website should allow them to do that using the ‘Create Soil Map’ tool.

https://www.nrcs.usda.gov/wps/portal/nrcs/detail/soils/survey/geo/?cid=nrcs142p2_053628

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.