Over Query Limit

Thank you for the information. You should add this information to your plugin before someone decides to purchase.

Can you please let us know if you found another solution? or a cheap hosting alternative?

Thank you.
P.

The ONLY solution is to get approved as a Google Maps Business account. Many will not qualify. Outside of that you are at the mercy of Google. It is a free service after all.

As for information before purchase, it is readily accessible on my website and the main SLP plugin is free.

Whether or not your server will overload the queries is all about how many people your provider crams on one server and what percentage is doing ANY kind of Google API interaction. “Cheap hosting alternative” and non-shared servers are diametrically opposed.

What about adding fields to the bulk upload that allows you to enter the lat & lon coordinates yourself?

Our database of stores already has the locations, but best I can tell it is choking on the limits.

Is there any way to just feed the coordinates to the database using the bulk upload without having Google do the Geolocating?

Thank you for all the help

@nomad1109 – simple solution… I like it! Might even be able to get that in without too much work.

Not THE solution, but until/unless Google starts playing nice it will provide one more option.

As a follow up, after all the testing yesterday I of course ran over the limits pretty quickly for a 24 hour period.

The biggest problem I was having was during the import I was getting MANY that either came back as ‘could not geolocate’ for an address, or it was on about 50% of the bulk upload items putting the phone number in the email field (but only on half the entries, and they were all in the same column. Was a very weird problem.

So I broke up the full import into three separate files of 500 stores each and it solved all the problems with the import.

Out of 1449 total stores we only had 7 that couldn’t geolocate, and of course that is probably just bad data that needs to be fixed, and I didn’t run into any of the phone numbers ending up as email addresses.

V3.8.14 is coming shortly with a lat/long field in the bulk upload (CSV) file. If the fields are filled in the geocoding is skipped for that location. Useful for data feeds with location info already within the data set.

https://www.charlestonsw.com/support/documentation/store-locator-plus/pro-pack-add-on/bulk-data-import/

I broke up a file with about 2500 stores into 4 .csv files with Retries set to 5 and just uploaded the first one with only 2 missing geocodes and no over limit messages. I plan to upload each of the 3 others one per day. (When I first tried uploading all 2500 stores about half got over limit messages.)

My question is: Are the geocodes required for Store Locator to include stores in the search?

If I enter locations manually, geocodes aren’t needed and it still works. But the first time I used the bulk upload, with all 2500 stores, the ones that weren’t geocoded didn’t show up in the search results, even when searching for the specific zip code (and checking that the zip code was accurate).

This time, though, the 2 with missing geocodes do seem to show up.

If it isn’t needed for Store Locator to work, why use Google Geocodes at all?

thanks,
Pat

Geocodes are required, it is how all store results are returned.

Non-geocoded entries return location 0,0 on the map so if your origin search point is 0,0 (very unusual, but possible) you will see those locations. Same if you set your radius so large as to cross into that 0,0 region on the globe (something around 13,000 miles would to that).

I added more info on the Geocoding situation with new info from Google:
https://www.charlestonsw.com/support/documentation/store-locator-plus/troubleshooting/geocoding-errors/

Until/unless I can get a business API key to test with I won’t be able to get the default limit of 2500 lookups/IP address removed. With business API you get 100,000 lookups but you need to be approved for a special business account.

BTW, plain ol’ Google Maps V3 API keys have NOTHING to do with geocoding. At this point I’m not sure what purpose it even serves in the SLP plugin. It is passed on map searches only but is not even a supported parameter for Geocoding. If you leave it blank the map search works perfectly well. In fact I’m considering removing the Google Maps API key completely in the next release.

I’m confused because I don’t know what Google Maps API key is or does and so I haven’t used it in SLP.

But since manually entered store data (we don’t have lat/long data) seems to work, maybe SLP gets the geocodes some other way, or the way you described (which I didn’t understand)?

Because another clue – for you, not me, since it’s working for me now, so far – is that for one of the two stores that turned up “uncoded” with a red highlight, the store actually shows up in search results. And when I clicked the edit button to add lat/long, those data were already there!

No need to respond to this message or educate me on Google Maps API key; I’m just hoping my (admittedly clueless) clues help you decide whether to remove the troublesome Google Maps API key in the next release.

Meanwhile, I’m also hoping my plan to upload 25% of the total store locations a day (roughly 650/day) continues to work. The data is very simple (4 columns), very complete, and very clean.