[Thinking out loud]
I think I would tend to use a form plugin on both the main data table, and the Locations table, rather than a calc element.
This is kind of a nasty workaround for something I would like to eventually code up support for. The problem we're having here is something I've seen before. Where you want to store "fixed" (but potentially changeable) location data in one table (usually with separate lat/lon fields) and reference it through a join element on your main data table. Then use that (join related) location data in read-only map context (detail or viz view) from the main data list.
Currently we dont support that out of the box. We require a 'map' element on the main table, with the data in our proprietary format of (lat,lon):zoom, in order to display the data in any of our map plugins.
So we can't use the expected benefits of the join from main table to the location table you are using for location selection, by grabbing the the map data we need from the location table. Which is the part I'd like to modify. I'd like the map element itself to be dual purpose - either a simple map element (as it is now), or a join to a row in some other table, and some prior knowledge of how to extract the lat/lon/zoom info from that table. So we provide the options for you to specify what format the data is in (DMS, Dec, etc), and which field on the location table corespond to lat, lon, and (optionally) zoom.
However, that's not something I'm going to do overnight. So we have to work round it. And instead we have to maintain a corresponding map element on the main table, duplicating the data.
And part of the problem there is, we need to keep that duplicate data up to date. If someone edits a row in the location table, say to fix a typo in a lat/lon value, we need to find and update all the rows on the main table that use that location data.
Usually a calc might address this problem, if set with "Calc on save only" to No, so the main table calc fetches the location table data every time it is rendered, so never goes "stale". But that won't work in this case, because it HAS to be a map element, otherwise it won't be "understood" by our map plugins.
So, we're stuck with having to hack our way round this, with two form plugins. One on the main data form, which runs a query to grab the location data from the selected Location, converts the data from DMS to DD, and pokes the (lat,lon):zoom data into the (hidden) map element, on either new or edit. And one on the Location form, which (on edit only) rebuilds the map element data for any existing row on the main data table which reference the Location being edited.
-- hugh
