I have to apologise.
I fully misunderstood the usage of the {lat,long} here.
I will also update the older thread.
So here is how this thing works:
1. First, we have the actual field value. That is stored in the postmeta table (in case of post fields), or termmeta/usermeta tables (in case of term or user meta).
The field itself stores a single string.
So far I was on the correct track.
2. That string can be in one of two formats:
- An adress string. In an example of my current living place:
Malaysian Nature Society, Bukit Persekutuan, 50480 Kuala Lumpur, Wilayah Persekutuan Kuala Lumpur, Malaysia
If we are lucky and this value was set using the Google Maps autocomplete for the address field (which in my case it was), it will match one "named" address for Google Maps.
Otherwise, it will be an address string that Google can try to match to a location.
- A pair of latitude/longitude values, stored in the format {latitude,longitude}.
In my same above example, it would be something like {5.990770999999999,116.07876680000004}. That is indeed a valid address field value, and we display that exact location instead of the closest "named" address.
NOTE:
This {lat,long} is entered in the Address field and stored as postmeta, NOT as an option.
3. What I mentioned (and we analyzed together above) in the Options table is not the field value, but the cache Toolset Maps stores, that matches a "named" address with its coordinates.
Toolset Maps does so to avoid the need to ping Google every time we want to display that address to get the actual coordinates.
4. There is no connection between the post custom field and the options data but the "named" address itself.
That means that when we need to get the coordinates for an address field value, we check:
- Whether it has a {lat,lon} format, and get it from there
- If not, whether it has a "named" address format, and in this case, we check whether it is cached in the options table
- If not, we ping Google for the coordinates
5. To conclude, you do not need to access the options value at all.
The address field value is a normal, native, string postmeta value.
You can access it by using the post ID and the address field key, just use the native get_post_meta.
We are not making anything simpler because it is stored as simple as it can be: a field value of {lat,lon} or an address stored as a string.
This is what Toolset Maps provides, and it works.
Thank you for your patience.