Link Analysis by location is missing a key piece - tool-generated meeting places

[DonBarker]

The Pattern of Life Link Chart is innovative, because it uses co-location as a "relationship" value:

The problem with this tool -- if I understand it right -- is that the analyst must already have a polygon layer of  precisely-named locations to make this work.  The linkage relies on a simple table join, which requires "location name" values to match precisely.  I think this is what's demonstrated at the Esri Defense and Intell Showcase in this clip which I posted on YouTube.   

At 7:55 in the video, the analyst specifies the names of the Key Fields for source and target layers.  These are required for a simple table join by attribute - matching values in each table:

I discussed this with @JamesJones4 at Esri.  He indicated that analysts can "add notes" to a location layer (is there a tool for this?) to create that target entity key field for the table join.  This seems impossible for the analyst who has lots of data or who does not know in advance which places are important.  (This advance knowledge of barracks, guard shack, and mess hall in the Showcase demo seems to be an unlikely scenario for most analysts.)

A better idea?

The input data -- masses of it -- could be run through the Optimized Hot Spot tool to automatically generate the meeting places.  (Or use the Find Meeting Places tool?)  Use those uniquely identified polygons with a spatial join, not an attribute join as demonstrated, to enumerate all the players who are linked by location.

Or, maybe I'm missing something.  I hope so.

[DonBarker]

I discussed this with @JamesJones4 at Esri.  He indicated that analysts can "add notes" to a location layer (is there a tool for this?) to create that target entity key field for the table join.  This seems impossible for the analyst who has lots of data or who does not know in advance which places are important.  (This advance knowledge of barracks, guard shack, and mess hall in the Showcase demo seems to be an unlikely scenario for most analysts.)

A better idea?

The input data -- masses of it -- could be run through the Optimized Hot Spot tool to automatically generate the meeting places.  (Or use the Find Meeting Places tool?)  Use those uniquely identified polygons with a spatial join, not an attribute join as demonstrated, to enumerate all the players who are linked by location.

Or, maybe I'm missing something.  I hope so.

[DonBarker]

I discussed this with @JamesJones4 at Esri.  He indicated that analysts can "add notes" to a location layer (is there a tool for this?) to create that target entity key field for the table join.  This seems impossible for the analyst who has lots of data or who does not know in advance which places are important.  (This advance knowledge of barracks, guard shack, and mess hall in the Showcase demo seems to be an unlikely scenario for most analysts.)

A better idea?

The input data -- masses of it -- could be run through the Optimized Hot Spot tool to automatically generate the meeting places.  (Or use the Find Meeting Places tool?)  Use those uniquely identified polygons with a spatial join, not an attribute join as demonstrated, to enumerate all the players who are linked by location.

Or, maybe I'm missing something.  I hope so.

[Anonymous User]

Hi @DonBarker - first, thanks for all the feedback! We appreciate you taking the time to write it up.

On this issue, I agree with you that the workflow in the video wouldn't work for an analyst that has a ton of data and/or doesn't have prior knowledge of known/significant locations. That said, having matching "locations" isn't required - having a matching key is. That key (lookup, join field, etc) could be any unique ID that is found in both the source and target entity tables. Some examples we've seen: ssn, phone number, xref, anonymous id (device id), enumerated polygons (your meeting locations example), names (though this could get messy with lots of data and potential variations), account numbers, etc.

The scenario you described is exactly the reason we added the 'meeting_area_id' field to the Find Meeting Locations output.

Using this unique id for each potential meeting area, you can link it to the "meeting participants" (which in this notional example are parolees). 

[DonBarker]

Thanks for this clarification.

It appears, then, that the Pattern of Life demo simply omitted (or I missed it)  a preparatory step - to run the event data first through the Find Meeting Places analytic.