In Tableau 10.2, we have a new data type that is read from spatial files – the GEOMETRY field. Right now, it would seem there is not much we can do directly with these fields other than display them.
The GEOMETRY field is presented as a measure object with a single aggregation function COLLECT(). This aggregation makes a group of polygons and/or points – GEOMETRY fields can contain both – act together as a collection (hence the name) based on the dimensions included in the viz. This means they are coloured, labelled, selected, highlighted, etc. as a single mark.
Right now there are no other built-in functions for GEOMETRY fields but we can use them in calculated fields. Here’s a simple, yet interesting application allowing us to dynamically select different levels of detail.
Australia’s Bureau of Statistics reports their data spatially via Statistical Areas (SA). There are multiple levels of detail in this model from SA4 down to SA1 (and further down to mesh blocks). The boundary definitions for these areas are available from the ABS website in ESRI and MapInfo formats.
To bring this data together, we can download and join the shape files together in a single data source:
With some cleanup this results as follows – with a GEOMETRY field sourced from each file, containing the boundaries of the associated SA level:
We can create a parameter that allows the user to select which level they would like to display:
We can use this parameter in a calculated field, returning a different GEOMETRY field based on the parameter value:
CASE [Select Level] WHEN "SA1" THEN [SA1 Geometry] WHEN "SA2" THEN [SA2 Geometry] WHEN "SA3" THEN [SA3 Geometry] WHEN "SA4" THEN [SA4 Geometry] END
Double-clicking on this calculated GEOMETRY field and exposing the parameter allows the end user to display the required SA level dynamically. However, because there is no dimension in the viz, the COLLECT() aggregation makes all the polygons act as a single mark. To have each area act as a separate mark, we can use the parameter again to create a dynamic code dimension:
CASE [Select Level] WHEN "SA1" THEN [Sa1 7Dig16] WHEN "SA2" THEN [Sa2 Name16] WHEN "SA3" THEN [Sa3 Name16] WHEN "SA4" THEN [Sa4 Name16] END
Check out this workbook for an example of this technique.
I look forward to finding more cool things to do with this new spatial capability in Tableau 10.2, and reading about your tricks as well.
Enjoy!
The Last Data Bender 
This is amazing Alan, I´m from Brazil and just yesterday I was playing with the Geometry Field as Kent Marten did in his post here https://www.tableau.com/pt-br/about/blog/2017/2/tackle-your-geospatial-analysis-ease-tableau-102-66018.
I was able to replicate what he did with data from Instituto Brasileiro de Geografia e Estatística (IBGE): comprehensive administrative and census data for Brasil very similar to Australia’s Bureau of Statistics for Australian (ABS).
I´m a big fan of you blog and with this new map feature on Tableau , maps will be easier them ever.
Congrats Alan
Thanks for the kind feedback, Juracy. I’m glad to know my scribblings are of use. 🙂
Alan,
Thank you for this post! I’m glad to see that geometries can be used in calculations to the extent of doing things like swapping them or checking for NULL values, etc… I’d love to see even more! (hence this idea: https://community.tableau.com/ideas/7191 )
Best Regards,
Joshua
Hi Joshua – thanks for the feedback. I can’t comment on timelines, but I can say that the product team have these requests (and more) on their list. We really want spatial analytics to be an area where Tableau shines. So watch this space for future enhancements, and keep the ideas rolling in through the forums.
Cheers,
Alan
Pingback: How to geocode thousands of addresses and make a Tableau custom polygon + point map, with a little help from FME » Tableau Picasso
To take things one step further, our data is generally by postal codes, which we link to our geometries via a reference Table ie 0H0 H0H -> North Pole if we use similar logic and a data blend instead of a join we can let users aggregate their postal code while still retaining the ability to swap geography levels with a parameter!
Using a join didn’t work well as we had a single Shape file with every geography level merged together resulting in many joins and duplication of data.
Hi Eric,
Agree – joins are not always the right approach. It very much depends on the nature of your data. Blending is still a very powerful technique so long as you are working at a suitably aggregated level and not linking on high-granularity fields.
Thanks for sharing your experience.
Cheers,
Alan
Pingback: Data + Science – The Open Bootcamps