As far as I know, there is no way in Tableau desktop to use the attribute from a selection in your calculation. However, if you have specific locations that you want to use for starting points, you could create a parameter with those location names, and when the user selects a location from a dropdown menu on the map it would update a calculation that just showed the points in / out of a set distance.
The process for this would be to make the string parameter, and have the value be a latitude and longitude pair, while the display would be the name of the location. You'd need to split the latitude and longitude pair to get the individual values in your calculation. Then you'd create a calculated field that had your distance calculation and a second calculated field that indicated 'in or out' of the maximum distance (e.g., if the distance calculation field returned 301 feet and your max distance was 300 feet, it would return false). Then drop the in/out calculated field on the viz as a filter and only show the 'in' values. Then any time you change the starting location in the parameter drop down, the points that are within a distance would be the only ones that show up.
I like the idea of being able to use a selection as an input to the calculated field though - maybe put that into our ideas forum as something for the developers to consider? Here is the link to the ideas forum: Ideas
Shawn Wallwork pinged me to look at this one because he knows I played in this space a lot a few years back.
It had me scratching my head for a while. Initially I though there was no way to do it without the ability to use selection or click coordinates in the query, as Sarah said. That is something I have been lobbying for for ever. It was one of my requests when I was first evaluating Tableau way back in Tableau 3.5 days. And I used to bleat on about it ad-nauseam when I was a zen master - but it always fell on deaf ears. I still think it would be a really powerful addition allowing for much better interactivity.
But the good news is that there is a cunning trick you can use to achieve what you want. Have a look at the attached modified version of your workbook. Click on any mark and that will become the centre of the viz (and the mark becomes a star and gets a label).
To do that I had to edit the data source so that the datasource itself returns one row for each pair of subway stations. You have 1928 rows in the original data source, so that means 3,717,184 pairs of stations. Doing that would ideally just use a CROSS JOIN - but Tableau doesn't explicitly support that (Grrr), though it is easy to fake it just be defining a column with a constant value for all rows and joining on that.
The results set from that data source contains details of two stations in each row. Think of it that one station in each row represents the centre and the other station represents any other station paired with the centre one. So if you filter to just one station for the "centre", each row will have the Lat/Long for the selected centre as well as the Lat/Long for one of the other stations. That then gives you the two sets of Lat and Long that you need for your distance calculation.
The final trick is that you need to create an Action filter which takes ID of the station that you select (by clicking it) and applies that as a filter on the "centre" station.
I just read that through and I don't think I've done a great job of explaining it - but have a look at the packaged workbook and see if that helps it make sense. In particular look at:
- The data source definition - which joins 2 copies of the sheet from your spreadsheet, with all rows joining to all other rows
- The modified version of Calc_a - using the two sets of Lat/Long
- The action filter - note that it is defined to run on single selection only and to leave the filter in place when the selection is cleared
- Calculated field [Centre?] is true for the selected mark and is used on the shape and size shelves to highlight the centre
- Calculated field [Label] is set to the station name only if [Centre?] is true.
Let me know if I need to clarify any of this.
SubwayAttempt - RL.twbx 135.4 KB
Richard - this is brilliant, and a great trick!
And, I'm definitely on the same page with you with seeing the nice benefit from being able to use selections in calculations (without having to do a massive join).
Glad to hear you agree on the use of selections in calculations.
The other part of that which I would really like to be able to do is reference the coordinates of a click, or the start and end coordinates of a drag operation (assuming continuous dimensions on rows and columns) in a calculation - irrespective of whether or not there are marks at the position of the click or the boundaries of the drag.
For example I often want to be able to drag over a scatter chart and use the start and end of the drag to define a bounding box which gets fed into calculations of filter criteria. One possible mechanism I could see for that is a new type of action which sets the values of a set of parameters (say XMin, XMax, YMin and YMax) which are then able to be used in filter criteria for a subsequent view - though there would be other weays to achieve the same outcome. Currently the only way to do that is with a filter acion to pass the set of selected marks in the bounding box - but when you have hundreds of thousands or millions of marks on the scatter chart that results in a query with a massive IN () list - often to the point where it is rejected as too big by the database engine. Or if not rejected, just unusably slow. I remember demonstrating a real-life example of that to Chris Stolte and Robert Morton years ago where the current filter action approach took over an hour to produce the result I was after, but the bounding box coordinates would have made it sub-second. Despite all my lobbying it has never made it far enough up the priority list though... :-(