we can do it Double time faster.
1quintana opened this issue · comments
Hello,
This is a wonderful job, I was wondering why did you use the url https://www.google.com/search instead of https://www.google.com/maps/preview/entity? which looks to be almost twice faster.
I am working on a package for PHP Laravel and It looks like google expose the population time in both urls, but I was confused about which one to use.
hey,
the /search endpoint seemed more stable and less contextual for the user session. do you have an /entity request with formatted address as input?
the main reason for /search was the ability to submit a formatted address and get the data.
Hey,
Thank you for the answer. Yes the google map url also take the q param q=somePlace%someAddress%someState. I was just wondering if there was any security reason or if they might block my requests form one or another url.
here is the result after I parse it.
Can you send an example request with the full URL?
I am using PHP for my package. Here there is an example. I am pretty sure that the position are the same than the response that you are getting with your code since I also had to deal with json_decode(str_replace(")]}'", "",$googleResponse));
Hey, sry for the delay.
the /entity request looks indeed significantly faster and the response is generally similar, thx for bringing it up. Using the example you posted above and only adapting the query q parameter i can't get location specific results.
Did you also adapt the pb string for each request, or what am i missing here?
Hey man, I am sorry for the delay. I was so busy working on different projects that I did not have the time to investigate that part, so I am not working on that now. I was trying to build a package for Laravel so the community could use it since it looks like we have nothing for php yet.
Sorry for bringing an old thread back to life, but any progress on this? I love the functionality of this library, but it's just too slow at times. Looking into using the /entity endpoint, with the pb that @1quintana used, seems to return a lot of information that can replace a lot of the helper functions.
Ex:
[6, [ [6, 0, "", "", "6 AM"], [7, 0, "", "", "7 AM"], [8, 0, "", "", "8 AM"], [9, 0, "", "", "9 AM"], [10, 0, "", "", "10 AM"], [11, 10, "Usually not busy", "", "11 AM"], [12, 14, "Usually not busy", "", "12 PM"], [13, 14, "Usually not busy", "", "1 PM"], [14, 14, "Usually not busy", "", "2 PM"], [15, 15, "Usually not busy", "", "3 PM"], [16, 21, "Usually not too busy", "", "4 PM"], [17, 34, "Usually not too busy", "", "5 PM"], [18, 62, "Usually a little busy", "", "6 PM"], [19, 95, "Usually as busy as it gets", "", "7 PM"], [20, 100, "Usually as busy as it gets", "", "8 PM"], [21, 68, "Usually a little busy", "", "9 PM"], [22, 29, "Usually not too busy", "", "10 PM"], [23, 0, "", "", "11 PM"] ], 0]
returns the exact popularity of each restaurant, and is specific for the location. It's perfect 😍
If someone much more skilled can chime in and take a stab at forking off of this and using the /entity endpoint, it would be much appreciated!
I'm going to take a look at parsing this in the meantime.
Thanks and great work!
Just did a bit more work on it and found that the pb parameter is essentially the same between requests:
Format is as follows:
The only part that varies is this: 1x405873813!2x3463614540 , which I assume to be the corners of the map that Google creates, but when I leave these the same and use an address in California (im in MI), the call still works.
@m-wrzr can you take a look into this again?
Thanks so much,
Eric
hey @zhongeric
i'll check for speedup possibilities next week, thx for the input! i recall testing the pb string some time ago and the results were inconclusive due to possible caching on the google side and not really working /entity strings.
here is my old testing code, maybe it's helpful to you: https://pastebin.com/VnLS4kzk (sry super messy and undocumented)
depending on your usecase you could also just skip the /details calls, most of the info is in /search but it would break google tos even more probably.