The best practice to join\relate\connect 4 feature class together

3756
6
01-28-2015 01:44 AM
AhmadSALEH1
Occasional Contributor III

What is the The best practice to join\relate\connect  communities\UMP\BuiltUP\Admin boundaries,

 

Could you please consider the following scenario:

 

1. I have a feature class with a name “community “ which I consider it the main layer in may work, so I relate it to more than one table and it has many information about the community.

 

Clip_3.jpg

 

2. Then I have three other feature classes each one is stored in a deferent file geodatabase ( built-up area, UMP urban master plan, and Administrative boundary).

Clip.jpg

 

Now how could I join\relate\connect the three feature classes (built-up area, UMP, and Administrative boundary) to the (community) feature class so that when I identify the community point I can get the whole results from all feature class?     

Clip_2.jpgMany thanks,

Ahmad

0 Kudos
6 Replies
AhmadSALEH1
Occasional Contributor III

How could I joint the layers together such as when I identify ANY layer ( communities, UMPs, Builtup, Administrative boundaries) then I can GET ALL data form other layers

0 Kudos
RichardFairhurst
MVP Honored Contributor

I do not know if you mean that you want the Identify tool to make the information visible or if you want some other method of identifying a feature to give you this information.  If you use the Identify tool and the features have a common field value in each (primary and foreign keys), then you could create 6 relates (Community to the other 3 FCs, built-up areas to UMP and Admin, and UMP to Admin). When you identify any of the features you can drill down to the others by expanding the relate tree.  With those 6 relates you should be able to go up or down to any related feature.  But it will cut off circular relates by only going up to relates that are parents of the current FC or each other or down to the FCs that are children of the current FC or each other.

Some possible relate chains are shown below for my data.  As you can see, the relate tree supports all relationship types (1:1, 1:M, M:1, M:M):

RelateTree1.png

RelateTree2.png

Using Spatial Join you can create a new feature class that combines the attributes of all the feature that touch each other while retaining the shapes of a chosen primary parent feature class.

0 Kudos
AhmadSALEH1
Occasional Contributor III

Many thanks Richard for your help,

But How could I relate the 4 F.C together while they are not stored in the same file geodatabase ?

Clip_17.jpg

What I want to do is to access to all records for the other 3 F.C when I identify ONE of them.

For example :

If I identify the community F.C I need to see the attributes of the builtup area , Admin boundary, and UMPs. and the same way when I identify the BuiltUp I should be able to see  the attributes of the thee other F.C and etc.

Thanks,

Ahmad

0 Kudos
RichardFairhurst
MVP Honored Contributor

I don't use relationship classes.  I just use the relate option in the Joins and Relates option of the layers and tables.  That kind of relate does not require the related layers or table to be in the same workspace with each other.  It cannot be set up in ArcCatalog, but it is easy to set up in Desktop in any map.  To me it does what you need through the tree view.

What you are wanting is a live two way join or query table, but that either is not practical or not possible.  A query table basically only works if the FCs are all in the same workspace.  But I don't use them even then, because they perform horribly and are no better than a static geoprocessed FC once you set them up.  A standard Join only works for 1:1 and M:1 relationships and only can be done one way, because once two FCs are joined you cannot do the Join in the opposite direction.

Relating objects to derive new workflows is fundamental to everything I work on, but I have never seen anyone do anything remotely like what you seem to be describing.  You would have to show me a mock up picture of what you think you should be able to see for me to even understand you (especially if there are any 1:M or M:M related features involved).

Another solution I see is to run a geoprocessing operation that does Spatial Join 4 times with each serving as the primary join parent.  Each Spatial Join would retain the shape of the parent FC.  They could be stored in any of the existing workspaces, or in a new workspace set up for them.  For the attributes you could either use the 1:M option of the Spatial Join and duplicate objects whenever more than one feature in the other FCs needs to have its attributes combined, or use the 1:1 option and combine attributes from multiple features into text fields using the Join list option.  The four new FCs would be static, but could be refreshed for end users when you publish new edits.  Editors would not be able to see these related objects without rerunning the geoprocessing operation and managing the workspace locks.

The final solution I see, since an attribute relationship is already in place, is running a python script using dictionaries and cursors to do the attribute transfers into the parent FCs periodically after doing edits.  Each FC would continue to have their original attributes, which would be edited directly, but in addition you would add all of the necessary attribute fields to hold all attributes maintained in the other FCs, which the editors would not touch.  In many cases those fields would be text fields that could hold lists.  Then I could write a python script that could fill in the related fields, including doing any needed summary operations or list creations for 1:M and M:M relationships.  The FCs could be stored in any or all of the workspaces, and the only restriction is that each FC that receives updates would have to be closed by all editors while the process runs.  This script would probably only take under 5 minutes to run for 4 FCs with 30,000 features each.

0 Kudos
AhmadSALEH1
Occasional Contributor III

Many Thanks Richard,

I am trying here to publish the 4 F.C as map services so that every single F.C in a different map service, then to receive them in a web mapping applications.

Clip_8.jpg

And then the end user of my web mapping application can get all data of other services if he identify just one of them.

Clip_7.jpg

Clip_9.jpg

Thank you I hope I clarified myself much better.

Thank you

0 Kudos
RichardFairhurst
MVP Honored Contributor

I doubt you can do anything without programming it yourself.  I don't work with web service programming, only desktop.  Since desktop has no built-in solution to accomplish what you want (unless you are just describing the Identify result that comes up when you use the Show All Visible Layers option with the Identify tool), I doubt you can overcome the additional limitations of performance and reduced out-of-the-box functionality to get a web service solution.  If you become a programmer and figure out a solution post it.