Skip Navigation

[Resolved] use latitude and longitude in Toolset Maps

This thread is resolved. Here is a description of the problem and solution.

Problem:
Can I use latitude and longitude in a Toolset Maps address field and where does Toolset Store the longitude and latitude if I use the autosuggested Address?

Solution:
1. You can use this form of value in the Address Field:
{lat,long}

2. Toolset does not store the Latitude and Longitude separately in a postmeta field.

3. We store only a string (address) or the entered {lat,long} in the postmeta and ping google for a location

This support ticket is created 7 years, 9 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 19 replies, has 2 voices.

Last updated by davidH-21 7 years, 8 months ago.

Assisted by: Beda.

Author
Posts
#412631

I need to access the Latitude and Longitude of geocoded Toolset Maps entries.

I looked at this thread which suggested a change was underway:
https://toolset.com/forums/topic/google-map-plugin-importing-addresses/

But, following the above and having searched through the DB, I cannot find the known lat/long combination of a stored post that has been cached by Toolset Maps - is the data hashed?

Please can you explain how to access both the post and the cached lat/long data.

#412736

The information I gave there is still valid.

1. You can display the Longitude / Latitude with the ShortCode to display the address.
(See ScreenShot)

2. We do store the Longitude and Latitude as an option in the DataBase "options" table.
It is stored with the option_name:

toolset_maps_address_coordinates

and the option_value is an array.

3. The Array is still as elaborated in the previous post.

I will query with the DEV what is planned for this.

Please let me know if you need more information in regard.

#412740

Yes, I saw the comprehensive answer you gave, although in the post:

https://toolset.com/forums/topic/google-map-plugin-importing-addresses/

you said:

In Toolset Maps 1.1 there will be a possibility to store a meta value as {1.11, 2.22}

which is what I a trying to use to create a spatial index of the posts for proximity searching.

However, I am running Toolset Maps 1.1.1 and this does not seem have been implemented?

Please can you advise.

#412742

Yes, as I stated, I see that this is still an Array as used to be.
https://toolset.com/forums/topic/storage-location-of-latitudelongitude/#post-412736 > #3

I am waiting for a reply from the DEV, to see why and what we plan here.

May I ask why you need to have that specific feature?

We are also planning a Geo Locating feature, which will also include distance respecting search and more.
But, when exactly our developers will add a new feature or not is not up-to us Supporters to determine.
Each issue reported in, whether a bug or a new feature request, is taken seriously into consideration.
It is given a high or low priority based on a number of factors.
Factors which those with the overview of all things related are in the best position to determine.
I apologize any inconvenience this may cause.

#412746

That's an issue.

I was working on the expectation that the data would be stored in this more "normal" format - it's much easier to index (and thus search) a comma-separated custom field than the way Toolset currently stores it.

Do you have any other suggestions for creating a proximity search with Toolset whilst we wait for the DEVs to come back?

#412748

Unfortunately not.
Becuase the Long/Lat is not in Custom Fields, we can not access them in a View Parametric Search.

Let's wait for the Developer to come back here. They will be responding tomorrow, but please acknowledge that also our Developers will not provide a Customized Solution for this.

They will solely respond to the status of feature request and future plans.

For your Goal it seems -unfortunately- that for now you need custom programming work which is beyond the scope of our support.

At this point I would suggest you consider contacting one of our certified partners from this link:
https://toolset.com/consultant/

You will get the custom assistance you need to get on with your project.

#412778

Ok,

Can you tell me how to get the comma separated lat/long string at time of CRED post submission which I could then hook with something like this psuedo code?

add_action('cred_save_data', 'my_save_data_action',10,2);
function my_save_data_action($post_id, $form_data)
{
if (isset($_POST['types_lat_long_data_string']))
{
// add or update post meta
if ( ! add_post_meta( $post_id, 'custom_lat_long', $_POST['types_lat_long_data_string'], true ) ) {
update_post_meta( $post_id, 'custom_lat_long', $_POST['types_lat_long_data_string'] );
}
}
}

I know this is saving the same data twice (bad practice), but I need a backup in case the developers have forgotten to update Maps 1.1 with the new data format.

Can you help with the above?

#412885

The Problem is the Lat/long Field do not hold a HTML name="" attribute in the CRED form.
They just have an input id="" which is generated and you can not guess it.

You can see what I mean when you analize the CRED Form on the front end.

That means you can not really use a Field name that would be always the same.

You could use Custom JS / jQuery and populate once more another (Types) Field (maybe a HTML hidden one) and then save that field to the Database.

For this you can use the ID and class of the above lat/long fields.

But it is requiring Custom Code, that does not directly involve the CRED API.

I am still waiting for the inputs of the DEV Team, also becuase I would like to know why we do not store this as a FIELD in the first place.
But this might be above my understanding of the Google API and Toolset MAPS.

#412967

Yes, I am surprised at how the data is being stored.

This is not typical for any WordPress Google Maps solution - I have reviewed the code of several GPL geocoding plugins and they all use standard custom fields.

If the DEVs do not reply with a way forward, can you suggest how I would use the cred_submit_complete action to retrieve the stored lat/long.

#413214

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.

#413357

Ok,

Thanks for providing some clarification. Regarding your points:

1), 2) & 4) Can you extrapolate this information into working pseudo code in my example function #412778

5) Are you saying that Toolset stores some cached lat/long values twice in the same database?

Thanks

#413371

You can use get_post_meta as in any other Function.
The DOC for get_post_meta is here:
https://developer.wordpress.org/reference/functions/get_post_meta/

Toolset does NOT store a Latitude or Longitude if NOT specified.
It does, as elaborated here:
https://toolset.com/forums/topic/storage-location-of-latitudelongitude/#post-413214

- Store a Lat/Long IF you add it to the address field
- If NOT, then you usually use the Google (existing) address and that gets stored as a string.

Both together is not stored.
The Option storage is as said only for caching purposes.

We are not storing anything twice.

Please read my explanation here:
https://toolset.com/forums/topic/storage-location-of-latitudelongitude/#post-413214

We store EITHER a {Lat/Long} value or the Address string.

Let me know if any doubts are left.

#413375

Ok,

Then I need to ensure that Toolset Maps does generate the lat/long when using a Types Address field in a CRED form.

Each post must be geocoded and the co-ordinates stored as well as the address.

How can I ensure the above occurs and then, again, please can you provide a code sample to achieve this as you have for so many others on this forum.

#413407

I can not add a Code that does not use a Toolset API or Feature.

I am sorry but the geocoding feature is under development, and I can not help you to acheive this now.

It includes Custom Code that is not covered by the Toolset Support.

I can show you how you update a Field with a CRED API code.

Converting value A to value B is not something that you would do with The Toolset API.

It requires Custom PHP code.

It seems -unfortunately- that for now you need custom programming work which is beyond the scope of our support.

At this point I would suggest you consider contacting one of our certified partners from this link:
https://toolset.com/consultant/

You will get the custom assistance you need to get on with your project.

#413417

Beda, please read (not scan) this carefully and ask me to explain or elaborate any part of it before replying with the default "Custom Programming" answer.

I do not believe this is custom code as Toolset already geocodes addresses, otherwise there would never be a lat/long entry in the database.

I am requesting assistance from Toolset support in how to achieve something in a Toolset manner, using only their current features, APIs and scripts.

What I need are the steps required to retrieve the lat/long from Toolset during the following process:

1) A user enters and selects an address into a Google autosuggest Types Address field (or pins an address using the associated map) in a CRED form
2) The completed CRED form (including other fields not relevant here) is submitted
3) The CRED form returns an error if there is no lat/long present in the fields array and requests the user to try again
4) A function similar to that which I have already written in #412778 fires to retrieve the lat/long from the CRED form submission and saves it to a Custom Field called fldLatLong

Specifically, my request for assistance relates to points 3 and 4 above as obviously 1 and 2 are already functioning correctly.

This should be straightforward for someone with Toolset knowledge. Some support operatives (including yourself) have given extensive examples of how to achieve a particular requirement.

I await your assistance.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.