Brooke, thanks for reaching out to the Tableau community. I'd like to suggest you first 'fix' a couple of things with your basic product before expanding your offering. Namely:
1. Align your zip code boundaries with Tableau's filled zip code boundaries. The mismatch makes your zip codes completely unusable.
2. Give us a 100% bright, vibrant map, and allow us to choose the wash-out level. It seems you currently give us a wash-out map, and then allow us to wash it out more. (This is our client's #1 complaint.)
3. Make the labels larger and darker. Or better yet give us control over the label sizes and darkness and color.
Thanks again for giving us a chance to give you feedback.
Thanks for the suggestions on the colors, "wash-out levels" and labels. I look forward to further suggestions from the community on how we can increase the visual impact of maps with suggestions such as these.
Regarding the zip code boundaries, I'll start investigating this immediately, but would appreciate some more detail. Exactly how does this issue manifest itself? Are there particular zip codes or zip code areas that show this mismatch? Can you give us a map scenario that causes this to occur? Feel free to include a sample data set in an email to email@example.com to demonstrate this (just be sure to reference the issue in the email). Anyone else is also encouraged to give support in this area as well.
Brooke, that was fast! Nice to be heard.
As to the ZIP code mismatch issue I'm sorry to say that it's ALL of them. I have yet to find any ZIP code where Urban & Tableau matched perfectly. Some are sort of close, but these are still unusable:
The colors are Tableau ZIPs; the light-grey borders are Urban ZIPs. The reason it's important that they match is then we could use your boundaries to show where all the ZIP codes are, and use Tableau's filled maps to show data of interest for particular ZIPs. Like I said as it stands now we can't combine the two. (Also it's a bit disconcerting that the boundaries are so mismatched! Which ones are right?)
Also note the labels. The large ones are furnished by Tableau (and therefore adjustable). The itty-bitty ones are furnished by Urban. Again, it's one of those situations where we can't use any of your labels, they're all just too small.
I've attached to sample workbook. It's Albuquerque, but it could be any city. Thanks for looking into this.
EDIT: So what's with the broken image links?
Message was edited by: DataViz Dude
Brooke Sample.twbx.zip 32.8 KB
What you are seeing is the result ZIP data being used in different ways—Tableau Desktop makes some optimizations to shrink the size of the ZIP code polygons in the client, whereas our API overlays with full resolution. We also (currently) use different vendors and are working to harmonize one one vendor per layer which should minimize the differences.
Your other concerns are more related to map styling, and we take queues from Tableau. I know they value feedback and we regularly share it with them and engage in deep discussions around cartography, so happy to add this to the list!
Brooke thanks for the investigation & reply! I suspect that most of what I'm seeing is your "different vendor". If it were a difference in overlay resolution, the two polygons would have very similar shapes, which in most case they don't. But great to hear you're trying to work this out between you.
Also glade to hear you have deep discussions about cartography, but please don't lose sight of the ultimate goal: producing maps that can be read! Almost universally, my customer can't read your labels, and always require me to put in Tableau labels. I hope at least some of your team(s) spend time working in higher resolutions; then you'll better appreciate the impact your lowest-common-denominator approach has.
Please, please make your label layer scale-able. Thanks again,
I just wanted to chime in to say that overlays and data for Canada would be appreciated. We often look at information at the FSA (first 3 letters of the postal code) level and the CMA/CA (census metropolitan area/ census area) level.
I am also curious about your point on Custom Overlays. Can you tell us more about how this feature would function and what sort of data (if any) would be available?
Great feedback--FSA and (possibly) LDU for postal codes and other administrative boundaries in Canada are on the list. We're trying to get a sense from the Tableau community what overlays have the broadest interest-- for instance, administrative boundaries (province, city, postcodes) in Europe would likely be more in demand than Israeli telephone codes. We're trying to figure out the balance of what is best to offer to all Tableau users v. layers to serve specific/more narrower needs.
For custom data, we can ingest any data you provide us and have it available as a custom layer (the map UI would have new layers with checkboxes). This could mean your custom sales territories, demographics, customer locations, data you might wish us to source (eg, Israeli telephone area codes) or anything from our data catalog. This could be a list of (say) ZIPs or country names that you wish us to convert to custom boundaries, we do some magical processing, and voila--new overlays are yours for the viewing!
The service is currently available, but we're working on productizing this over the summer but are eager to work with additional Tableau customers over the summer to flesh out details. If it is of interest, please do contact me or Brooke.
I'm not particularly clear on where Tableau's code ends and Urban Mapping's begins, so these might not all be applicable to your work:
- All 50 US states on one map, i.e. Alaska and Hawaii are tucked in, like this: http://www.united-states-map.com/usa-conic-1094.gif
- Town/city names - where I live, most every town only has one zip code so we tend to use town and city names more than zip codes. The Place Names cover only a small number of town and city names.
- Town/city borders - same
- Zip code placename labels - to get around the town/city issue, I've had to use a separate database that maps zip codes to placenames, if they could be available as an alternative to the 5 digit numbers that would be great.
- More accurate geocoding for zip codes. The zip codes for at least a few of the southern Maine towns are geocoded in the wrong locations.
- Ability to integrate Data Layer data into calculated fields and other views. Given that this data exists, I'd love to be able to use that to do some evaluation with our data to create scatterplots, bar charts, etc.
Thanks for asking for feedback!
Nothing terribly exciting or complex, but hugely painful for me in terms of a feature. I would like to have a distance scale appear on the maps right, left, center, wherever like you see on any map including Google Maps. I get more queries from people asking me about distances between two points and I have gone to significant lengths to get around this basic missing feature.
+1 on the scale. Definitely needed!
I'm in the middle of a project creating a SHP file for our campus here for a cloropleth map, and I'm using RIchard Leeke's shapetotab code & GDAL mapserver to achieve this.
So, I'd like to be able to import local raster files (saves the need to connect to WMS and setting up background images), create vector files (SHP) and be able to re-project on the fly within Tableau (i.e. I am stuck with WGS84).
At the moment - I have QGIS open, making my shapes, simplifying the geometries, adding feature IDs - couldn't all this be done in Tableau GIS?
One issue I've found is that I can't seem to pan around the map, I'm sure that is a fairly easy GUI tweak!
Hi All. Thanks for your suggestions. We subscribe to this board and are logging all of your requests.
Alan - Some clarifications may help us understand your needs. Is your data in raster format, or have you already converted it to SHP? What type of projection are you using, and can you post your data here for us to see?
I believe your panning issue can be solved by holding down the Shift key while dragging the map with your mouse.