If you want steps in your colors, click the little arrow menu on the legend and choose "Edit Colors". Then check the box for "Stepped Colors". This works for colors on continuous ranges on all mark types, including filled maps.
I do see the color names always in English (not French). It's in our bug tracking system already.
Thanks for the feedback,
Good Day, our users who are using mapping technology, have asked to post the following questions/requests:
1) It looks like Tableau v7 supports US States to the County level - but does it support mapping to the US ZIP level? Also, we are having problems getting the filled polygon of the States to work. Can we get support on Tableau 7 functionality to get a worked example for filled polygon States and information about mapping down to ZIP level?
2) Is there a way, when drawing maps in Tableau, to draw the data in a specific order? Ideally it would be nice to plot the “big values” last so they’re not swamped by smaller values – e.g. in the example attached, say in East Florida where some big numbers (shown as pink/red squares) are swamped by smaller numbers? I’m assuming it’s something to do with the way it’s imported into Tableau and plotting “order” can’t be defined within Tableau. Please advise on this.
mapping.jpg 23.2 KB
Tableau v7 doesn't support filled maps for zip codes or postcodes yet. We hope to add it by the time we ship but it looks less likely every day. We will plan to include it in a maintenance release if it does not make the initial 7.0 release.
Unfortunately you can't control the drawing order. You can use transparency or ring shapes (instead of filled circles) to make values that are lower still be visible.
Cory, many thanks for the prompt reply. I will pass this onto our business users. I'm sure they will appreciate the suggestion provided to overcome the drawing order issue.
Another question: If the zipcode-level mapping doesn’t get included (which would be a great shame) – I’m assuming that the method required will have to be via this type of approach:
Has anyone actually attempted to do filled zipcode maps in Tableau and has it caused the software to slow up greatly?
I am not sure you got me correctly. I already succeeded to get several colors. My issue was the legend. I wanted a value written with text for each interval in the legend and not only the extrem values written at the left and the right of the spectrum.
Wait from your feedback;
The notion of mapping zip code "areas" has been around for a long time. Unfortunately zip codes are not "areas" but street addresses that are maintained by the USPS. The Census Bureau creates something called a ZCTA (Zip Code Tabulation Area) that is only updated every 10 years -- most recently 2010. According to the USPS, they make roughly 25,000 5-digit zip code changes per month. So, is the expectation that Tableau will use the Census 2010 ZCTA or create their own custom ZCTA every month to keep up with all of the changes? Just curious.
If you want to show 5/6 colors and the text associated with each color in the legend, couldn't you create a calculated field with the 5/6 ranges and then place that field on the Color shelf? I prefer that approach so that I can set my default color and sort order. I also highly recommend this site for choosing the best mapping color ranges: http://colorbrewer2.org. Just a thought.
I think I see what you want now - thanks for the suggestion for future versions. As Tim said, you could do it yourself with a calculated field, but that's not terribly elegant.
Thanks for helping out Vince. And thanks for the feedback on zip code areas. I'm aware of the issues and we do try to keep the data up to date. We aren't yet committing to a particular update schedule, but hope to at some point.
The comments about the number of US zip codes and their rate of change, together with the observation I made on one of the other filled map threads about the potential for bloat as more shapes are added set me thinking about the whole question of custom geocoding support for filled maps again. Joe originally raised this a while ago here.
I actually don't use Tableau's geocoding all that much except for the odd blog posting, so these are really just idle musings - though I have done a lot of work with spatial data in the past, so it's a bit of an interest area.
Anyway, here's what I've been thinking.
1) The way that geocoding data is currently shipped as an integral part of the product installer means that as more shape data is added, the installer will continue to grow significantly.
2) As more detail is added, the rate at which the installation becomes "out of date" will also increase (at least for the more detailed and more dynamic areas).
3) The way geocoding works currently, when you define custom geocoding, you get a complete clone of the built in geocoding database, plus whatever bits you've added. That custom geocoding database goes in your repository and gets copied into any packaged workbooks that reference it. So as the amount of detail included in the base install increases, the size of the custom geocoding database will increase, and hence any packaged workbooks using it will grow. Currently adding even a tiny amount of custom geocode data results in a 55 MB custom geocode database, which after compression adds about 14 MB to the size of any packaged workbook (and hence also chews through your Public quota more quickly if you publish it there).
I think it would be good to be able to choose which aspects of the base geocoding database were included in the custom database - simply to keep packaged workbook size down.
4) Different analysis may require different custom geocoding. Unless I'm missing something, there's currently no easy way of setting up different custom geocode databases to be used by different workbooks (i.e. it needs a bit of manual shuffling of files in the repository or repeated removal and rebuilding of custom geocode databases).
5) Different users have very different needs for various sets of geocoding data, as shown by all the responses to Dan's questions on one of those other threads. Lots of those needs are standard, well defined boundaries, but even then, very often highly localised. I may want to visualise the Local Authority Territorial Boundaries for New Zealand - but if I add those (if and when custom geocoding supports shapes) I won't want to have to carry around a copy of all the US zip code boundaries in my workbooks. The same can just as well apply to individual states in the US, or counties in England, or whatever. To do detailed analysis of New York, you don't want to have to have that same level of detail for all the other states.
Other needs are very customer specific and would never be added as part of the product.
6) Currently, support is somewhat US-centric (understandably).
7) Different users have different timeliness requirements for getting updates.
It seems to me that all of the above could be made a lot simpler with a couple of changes to the way that geocoding data is distributed and managed.
1) Decouple the distribution of at least some of the more detailed geocoding data from the main Tableau installation. Probably the Tableau release will have to continue to include everything it does now, or maybe even that could be cut back a bit. But for the more detailed data being considered, I think it would be good to deliver that as a set of optional "geocoding extension packs" (or somesuch).
2) Define a standard, open, format for such extension packs, so that people can build their own - very much like custom geocoding works now, but with the addition of shape data. Possibly that would also allow geo-spatial suppliers to offer specialist data sets directly, in Tableau "extension pack" format.
I suspect there might be a trade-off between reduced hassle and loss of control there. ;-)
3) Allow the option to select what to include or exclude in a custom geocoding database. I'm sort of imagining a treeview control which lets you explore the geocoding hierarchies, selecting what to include.
4) Allow multiple custom geocoding databases to be defined at the same time, so that different analyses with different needs can co-exist.
This is really all about how the data is grouped and managed - particularly management of change. I'm sure the basic geocoding functionality is all there and already completely extensible (at least until there gets to be too much detail to render quickly enough). In fact I bet with a bit of judicious under-the-covers hacking everything I've talked about could already be done - though of course not supported, so I'm not suggesting it.
Obviously there are a whole load of trade-offs here, and I'm sure that most or all of these issues, plus probably lots of others I've not thought of are already in the mix in the thinking about how to extend coverage. But I just thought I'd share what I'd been thinking about and see what others think.
Dan I for one am extremely glad you are committed to zip codes, no matter what the update schedule is, and no matter how "bloated" the packaged workbooks get. We will use this feature a lot!
I am not suggesting it be eliminated just well throught out, as Richard suggests. I am really intrigued by the "extension pack" idea. Nice.
Thanks for your exhaustive analysis. We've had very similar discussions among the Tableau team.
If you use data blending instead of custom geocoding, then many of the issues don't apply. It can do many of the same things, although currently not everything custom geocoding can do. I suspect whatever solution Tableau may have some day in the future will look a lot more like data blending than custom geocoding.
The other issue that concerns us is that we would end up with a bunch of users that can't open each others workbooks because they all have different extension packs. We don't want to create that complexity if it isn't necessary.
For now we'll continue to provide all the map data to everyone.
Yes, I thought about the extra complexity of missing extension packs when sharing workbooks - I meant to mention that. I can certainly see you want to avoid any extra complexity like that if you can.
I hadn't thought about the data blending approach. I can't immediately see how you will be able to allow extensibility of filled maps with a blending approach - or at least not unless you expose a geometry data type. Am I missing anything?
Anyway, I was sure you'd have been thinking hard about all the angles on this - and will watch this space with interest in future releases.