This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Alteryx Gallery is experiencing a problem in which system emails are not being sent out. As a result, if you are attempting to sign up for a new account, you may be unable to verify your email address. We are working to solve this as soon as possible and will remove this notice once resolved.
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.
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 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.
@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:
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):
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.
@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.