we can do it Double time faster.

[1quintana]

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.

[m-wrzr]

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.

[1quintana]

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.

[m-wrzr]

Can you send an example request with the full URL?

[1quintana]

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));

https://www.google.com/maps/preview/entity?authuser=0&hl=en&gl=us&pb=!1m19!1s0x88d901b7eb380cb1%3A0xc72cbc93549edbc5!3m12!1m3!1d81920.38965449497!2d-80.19856063874508!3d26.156989096290584!2m3!1f0!2f0!3f0!3m2!1i1680!2i549!4f13.1!4m2!3d26.137109!4d-80.12179499999999!5e0!9e0!12m3!2m2!1i392!2i106!13m57!2m2!1i203!2i100!3m2!2i4!5b1!6m6!1m2!1i86!2i86!1m2!1i408!2i200!7m42!1m3!1e1!2b0!3e3!1m3!1e2!2b1!3e2!1m3!1e2!2b0!3e3!1m3!1e3!2b0!3e3!1m3!1e8!2b0!3e3!1m3!1e3!2b1!3e2!1m3!1e9!2b1!3e2!1m3!1e10!2b0!3e3!1m3!1e10!2b1!3e2!1m3!1e10!2b0!3e4!2b1!4b1!9b0!14m5!1sKGvTW-KFMYGm_Qas5JbgCw!4m1!2i6986!7e81!12e3!15m18!2b1!5m4!2b1!3b1!5b1!6b1!10m1!8e3!14m1!3b1!17b1!24b1!25b1!26b1!30m1!2b1!36b1!52b1!21m28!1m6!1m2!1i0!2i0!2m2!1i458!2i549!1m6!1m2!1i1630!2i0!2m2!1i1680!2i549!1m6!1m2!1i0!2i0!2m2!1i1680!2i20!1m6!1m2!1i0!2i529!2m2!1i1680!2i549!22m1!1e81!29m0!30m1!3b1&q=Il%20Mulino%20Cucina%20Italiana%2C%20East%20Sunrise%20Boulevard%2C%20Fort%20Lauderdale%2C%20FL

[m-wrzr]

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?

[1quintana]

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.

[zhongeric]

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!

[zhongeric]

Just did a bit more work on it and found that the pb parameter is essentially the same between requests:

Format is as follows:

https://www.google.com/maps/preview/entity?authuser=0&hl=en&gl=us&pb=!1m8!4m7!2u17!5m2!1x405873813!2x3463614540!6m2!1x425928789!2x3463678484!2m1!1e0!2m33!1e2!2spsm!4m2!1sgid!2s29JJixkYzaFNu49JiIaMsQ!4m2!1ssp!2s1!8m24!13m13!2shh%2Chplexp%2Ca!18m7!5b0!6b0!8b0!9b1!10b0!11b0!12b1!22m3!6e2!7e3!8e2!19u6!19u7!19u11!19u12!19u14!19u29!19u50!19u37!19u53!19u30!3m1!5e1105!4e5!18m1!1b1&q= URLENCODEDFULLSTREETADDRESSHERE

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

[m-wrzr]

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.