As well as tips for writing reusable macros…
I have been continuing down my path of writing a general interest post about Food Deserts. Most maps you find online of Food Deserts, or any other phenomenon that happens primarily in rural areas make the issue look much larger than it really is. Looking at a map of the 2008 US presidential election, you would never guess that the blue team won. Rural areas are a larger portion of the map than they are of the people and so it is very easy to create a misleading map. I wanted to explore mapping methodologies that properly shows the scope of an issue – not exaggerating it by making it look bigger or smaller than it actually is. You can click on all the maps in this post for a larger version.
When you map the raw census block polygons that are part of a food desert – the map on the right– it appears that most of the state of Colorado is in a food desert. While that may be true in a geographic sense, it is far from true in terms of the number of people. I tried to theme the map in order to de-emphasize areas with lower population, but because the rural blocks are so much bigger it just makes the problem look much bigger than it actually is.
Another visualization method some people have used is to draw lines from the people (or the block centroid in this case) to their nearest grocery store – again only for people in food deserts. This has the advantage of conveying the distance and direction that people are travelling, but it still has the issue of being overwhelming on the map. I think this map is better, but it still might make you think that most of the people in Colorado live in a food desert.
So the question becomes how to we fairly portray the issue, without making it look bigger or smaller than it actually is. The technique I settled on is dot density maps – see 1st map on right. The general idea of this technique is to paint a dot that represents a specific number of people. This way a dot in an urban area counts exactly the same as a dot in a rural area. With this map, the map becomes about the people, not about the geography. You can see in the map (at the right) a more realistic portrait of how prevalent this issue is (or isn’t). If we wanted to be the most fair possible, we could also show all the people who are not in a food desert in a different color (see map below). While this final map is perhaps the most balanced and fair, it is not very aesthetically pleasing because it has too much going on. It does show very clearly the full scope of the issue.
There are many techniques for generating a map or any other visualization; choosing one that properly conveys the message is important. Choosing either of the 1st 2 maps might be good if you are trying to make an issue seem bigger than it really is. It’s not that there is anything wrong with either of those techniques, it’s just that they may not be appropriate to show an issue that primarily affects rural people.
I created a macro to make creating dot density maps easy – you can download it here.
The actual process of creating the points is very easy (but fairly hidden) in Alteryx. There is a formula function: ST_RandomPoint([SpatialObj]) that creates a random point within a spatial object. All I needed to do was to use a GenerateRows tools to create the correct number of rows and then for each row create a random point. When adding the points layer to the map tool, I set the size to 1 and the border size to 0. It ends up looking like a thematic map, but it actually doesn’t use a theme at all. Again this is a great illustration of the big data power of Alteryx – you can do almost anything you want to if you are willing to string a few tools together.
As a macro author, there are a few things you can do to make the consumption of them easier.
- Don’t require the user to rename their fields.
- If you are going to be passing the user’s fields through – don’t rename them. In this case it means to NOT use a field map. You can see in the attached macro that I needed a few extra actions to set field names in the filter and the formula. Also if you are inserting any field into the stream of user fields that will later be removed, make sure to name them so they are unlikely to conflict with the user’s field names. I use __ (2 underscores) as a prefix on my fields within a macro.
- If you are only outputting a fixed set of fields, by all means, use a field map. It is way easier.
- Tell the user if the data doesn’t fit your assumptions
- You can use either a Test tool or a Message tool to do this. The test tool only returns errors, you can return informational (or warning) messages with a message tool.
- If using a message tool, make sure to set the priority of the messages to at least medium so the user of the macro sees it. Otherwise, it will only be seen if the macro is run as a module.
- In this particular macro I have 2 message tools – 1 to error if there are no polygons and another to warn that non-polygon records are being skipped.
- Keep it simple. If your macro has more than a couple of tabs or too many questions, it makes it difficult to use.
- In this case, consider breaking your macro into multiple parts. Even if the end user is going to consume all of them, they probably know Alteryx and it might make their module more clear to see the different parts explicitly.
- Don’t do too much.
- This goes along with the keeping it simple. Presume your users know how to use Alteryx and can combine different functions together.
- When I first wrote the macro in the article, I had the map tool in the macro. This reduces the usefulness because the user can’t easily add other layers. The 4th map above would not have been possible. I presume the consumer of my macro knows how to use the ReportMap tool.
Thanks for reading,