Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!

Alteryx Designer Desktop Discussions

Find answers, ask questions, and share expertise about Alteryx Designer Desktop and Intelligence Suite.
SOLVED

Non overlapping Trade Areas of different sizes

mstern
7 - Meteor

I have built a workflow that dynamically sets trade area radii based on an average of how far people drive to a given store. I know there is an option to "eliminate overlap" in the TA tool, but that only works if the radii are the same.

 

Below are 2 images demonstrating my issue. The image on the left is an example of what I'm trying to accomplish (but with my dynamic TA radii). On the right you can see what my TA's look like. 

 

 DesiredOutput.jpgDynamicTAs.jpg

As one work around I thought about summarizing all TA objects (excluding the TA for that specific record) into a separate single object so I can do a Spacial Process to separate them, but that didn't work because it created an area of intersection that drops off. See example below. 

 

SpatialSplit1.jpgSpatialSplit.jpg

 

Any other creative ideas or hacks for achieving this? Maybe there is a tool that does this already that I'm not aware of. Unfortunately the non overlapping  drive time won't work for me, but that type of functionality is what I'm hoping to achieve. 

 

Thanks,

Mike

18 REPLIES 18
patrick_digan
17 - Castor
17 - Castor

@mstern I see what you mean now. Hmm... Nothing is coming to mind.

mstern
7 - Meteor

No problem @patrick_digan, thanks for trying. 

Ned
Alteryx Alumni (Retired)

It turns out this is one of those problems that is much harder than it appears at first.  First you have to decide what you want.  The most logical algorithm (to me) will end up with a smaller trade area being included as an island in a nearby trade area with a larger radius.  The other logical algorithm will end up will end up with some surprising corners and area not in any trade area, even though it is within the radius of a farther trade area.  It also ends up with some subtle round off error that will result in really small (a few feet) slices and overlap between the trade areas.

 

I will see if I can find some time to write a workflow to demonstrate what I am thinking.

Ned
Alteryx Alumni (Retired)

NonOverlap.png

So this is the most logical solution to me.  It keeps the dividing line between 2 trade areas such that the area that is nearest to a location is in that locations trade area unless it is greater than the radius.  If you are looking to change the relative dividing line between the locations based on their relative weights, then you are looking for a gravity model.  Definitely more complicated, but supported by Alteryx with the location optimizer macros.  Anyway, I hope this helps.  The workflow is attached. 

 

It required a batch macro to build, since each different radius needed to be calculated as a separate non overlapping trade area on its own.

 

 

mstern
7 - Meteor

@Ned, This is fantastic!!! The way you separated the TAs based on relative radius size is much better than my approach. I really appreciate you working on this and providing a solution so quickly. 

 

@patrick_digan and @Philip, thanks so much for your input too. This is a great community board and I really appreciate all of the quick feedback!!!

 

Mike

Ned
Alteryx Alumni (Retired)

@mstern No problem.  I love spatial problems.  And I think that sometimes the capabilities of the spatial tools in Alteryx get overlooked.  In this case, the use of the Summarize tool in "Intersection" mode is super cool - it allows you to consolidate a bunch of versions of a polygon that each have a chunk taken out of it.

patrick_digan
17 - Castor
17 - Castor

@Ned I used your workflow to get a better understanding of the spatial capabilities. I've only just begin to realize how powerful these spatial tools are, and your workflow opened my eyes to several neat concepts.

 

As I poked through your workflow, I noticed that RecordID= 5 and 6 still had some overlap:

Capture.PNG

 

I decided to see if I could start with your workflow and try to fix this small overlap. Here is what I came up with to first replicate your results (bottom path) and then fix that overlap (top path):

Capture.PNG

 

I think I've now fixed that slight overlap on records 5 and 6. As someone who's new to spatial tools, I'm not sure if my workflow would perform slower when used on a normal sized dataset compared to yours.

Ned
Alteryx Alumni (Retired)

@patrick_digan That is a very subtle issue.  That is a really clever use of the multi-row formula to solve it!  I do think that solution is going to be slow for large data sets though.  Any time you are making really large complex polygons for an entire data set you end up in a N^2 type algorithm.  Fine for small data sets, not so good for really big ones.

 

I suspect that you could do the same thing with a second spatial match and a filter to make sure that you are always cutting in the proper order.  Since you might have multiple overlaps and hence multiple "bites" out of some polygons, you will need another summarize tool in intersection mode to apply all the "bites" to a single version.  In essence it will be my original solution in a second pass to resolve the overlap created by the first pass.  Since it will only be looking at objects that overlap, it won't get much slower (per record) as you go to larger data sets.

Drewmeister
5 - Atom

 

 

 

Labels