Is Spatial Join Capable of this?

[BrockWahl]

I'm using a PLSS land grid as a base map layer.  This grid is "Sections" ( 1 mile X 1 mile grid over the entire state).  I have a second layer that has a hundred or so features and these features all consist of 3 sections (layer has been snapped to lines and vertices)


[ATTACH=CONFIG]25268[/ATTACH]

What I would like to do is extract the section numbers that each of my features comprises of into a field or 3 fields.  So for instance the picture I've attached.  I would like this new field(s) to contain sections 20, 21, and 28.

I've tried spatial join but it either concatenates all the sections or just gives me one section ( the first)....any other way to do this?

[DaleHoneycutt]

I think so.  Take a look at this blog post about 1:M joins and the merge rule "join" in Spatial Join.  Although the blog post is about something different then your scenario, the basics, I think, are the same.  You'll do a ONE_TO_ONE join, but you'll specify a new output field with a merge rule of "Join" as shown in the blog post.  You'll specify a delimiter, such as "&".  You'll end up with one field with the sections delimited by an "&" (i.e., "20 & 21 & 28").  Once you have this information in one field, you can start busting it apart into several fields (such as SECTION_1, SECTION_2, SECTION_3) using Calculate Field and some simple Python list processing.  For examples of list processing, such as counting number of sections, or finding the 1st, 2nd, and 3rd 'thing' in the list, see this blog post on building a street intersection list.

This is all pretty high-level, but if you can write a bit of Python for Calculate Field, there's hardly nothing you can't do with processing a delimited list like "20 & 21 & 28" (doesn't matter what the delimiter is as long as you're consistent; you can use '-' or '+', or ',' or 'whatever').  Let me know if you need more help; I'll need some specifics about layer and field names.  But I think this'll get you where you want to be.

[BrockWahl]

I think so.  Take a look at this blog post about 1:M joins and the merge rule "join" in Spatial Join.  Although the blog post is about something different then your scenario, the basics, I think, are the same.  You'll do a ONE_TO_ONE join, but you'll specify a new output field with a merge rule of "Join" as shown in the blog post.  You'll specify a delimiter, such as "&".  You'll end up with one field with the sections delimited by an "&" (i.e., "20 & 21 & 28").  Once you have this information in one field, you can start busting it apart into several fields (such as SECTION_1, SECTION_2, SECTION_3) using Calculate Field and some simple Python list processing.  For examples of list processing, such as counting number of sections, or finding the 1st, 2nd, and 3rd 'thing' in the list, see this blog post on building a street intersection list.

This is all pretty high-level, but if you can write a bit of Python for Calculate Field, there's hardly nothing you can't do with processing a delimited list like "20 & 21 & 28" (doesn't matter what the delimiter is as long as you're consistent; you can use '-' or '+', or ',' or 'whatever').  Let me know if you need more help; I'll need some specifics about layer and field names.  But I think this'll get you where you want to be.

I did all of this and used & for the delimiter and CONTAINS as the merge rule.  The problem has now become that if the "shapes" do not match perfectly it only takes the ones that do match.  For instance if the snapping isn't 100% accurate my output will not include the sections that are not accurately snapped.  My output field has 3 sections in some and 2 in others...etc.  For what I'm doing I don't need to be so accurate that I need to go snap hundreds of features perfectly.  There has to be a way to say... create a field and any section that you over lap at all, throw those sections into this field.

[curtvprice]

if the snapping isn't 100% accurate my output will not include the sections that are not accurately snapped.  My output field has 3 sections in some and 2 in others...etc.  

Have you tried specifying different search distances with INTERSECT?

[RichardFairhurst · Accepted solution]

I did all of this and used & for the delimiter and CONTAINS as the merge rule.  The problem has now become that if the "shapes" do not match perfectly it only takes the ones that do match.  For instance if the snapping isn't 100% accurate my output will not include the sections that are not accurately snapped.  My output field has 3 sections in some and 2 in others...etc.  For what I'm doing I don't need to be so accurate that I need to go snap hundreds of features perfectly.  There has to be a way to say... create a field and any section that you over lap at all, throw those sections into this field.

It all of the shapes are more or less similar, such that centroids of the sections would always be covered when you consider it to overlap, extract the centroids of the sections and then do the Spatial Join to that with the multi-section polygons.  Use the Feature to Points tool to get the centroids.

[BrockWahl]

It all of the shapes are more or less similar, such that centroids of the sections would always be covered when you consider it to overlap, extract the centroids of the sections and then do the Spatial Join to that with the multi-section polygons.  Use the Feature to Points tool to get the centroids.

Worked!  Not all of my features took to this tool but the few that didn't it was easy enough to add the attributes manually.  I did a spatial join with the CONTAINS and it worked wonderfully!  Thank you so much for your help it was greatly appreciated!