IssueTracker

Thanks for your suggestion! We are currently evaluating this request, but do not have any plans to implement it at the moment. Please star to add your vote and receive further updates, and feel free to add any comments to discuss your use case.

I've transitioned from this team. Thanks!

Have you executed the reproduction steps I described above?

Is there any progress in the reproduction and the resolution of this issue?

Can you please provide an example of the query that will demonstrate your issue (http://sscce.org/) ?

Would you mind also explaining how do you calculate a distance, as far as I know distance is not included in the response JSON.

Look, I've described what query demonstrates my issue. If you don't know how to construct Nearby Search queries and thus have no idea how to use the info I've already provided, it's not my problem. Familiarize yourself with the Places API docs (https://developers.google.com/places/web-service/search#PlaceSearchRequests) or delegate this issue to those who are competent enough. Or do you think I'm supposed to deliver lectures here?

Concerning how exactly I calculate the distance, I use the Location.distanceBetween method on Android (https://bit.ly/2rHHxzq). However, it doesn't matter how I do it, you could do it using a different valid method and still see the same result.

All in all, I don't understand why I'm wasting my time explaining all this to you. Why are you keeping asking me silly questions instead of doing your job? Why haven't you even tried to reproduce the issue using the reproduction steps I described above (which do contain all the required info)?! Or if you're not competent enough, why haven't you delegated this issue to those who are?!

You are supposed to provide a valid sample at least.

I need following parameters to reproduce the issue: location, keyword, name, type

Can you please provide these values? And be sure that I know documentation very well. :) I would suggest maintain a professional tone in the conversation.

I repeat it again: I've provided all the required info.

1) I wrote that it should be a search of restaurants, which implies that the type is equal to "restaurant".

2) I wrote that it should be a search by some keyword, which obviously implies that it doesn't matter what keyword exactly you specify (as long as this keyword produces results consisting of multiple pages, of course).

3) I didn't write anything about the location, which obviously implies that it doesn't matter what location exactly you specify (as long as this location produces results consisting of multiple pages, of course).

4) I didn't write anything about the name, which obviously implies that it shouldn't be specified at all since this parameter isn't required and since this parameter duplicates the keyword parameter and since it's recommended not to use this parameter, as per the docs.  

Is all that a rocket science to you? As I said, instead of doing your job and really processing the issue, you just keep producing more and more posts in this thread. Of course, it's easier to write meaningless posts than to work. And no, I won't be polite and smiling when I'm faced with such blatant unprofessionalism.

1) And despite the fact that I reproduced this issue for the type being equal to “restaurant”, it is reproducible for different types as well. So it doesn't matter what type exactly you specify either (as long as this type produces results consisting of multiple pages, of course).

---

All the above-mentioned things prove how global and independent of particular parameters this issue is: IT LOOKS LIKE IT OCCURS WHENEVER YOU PERFORM A NEARBY SEARCH BY KEYWORD THAT PRODUCES RESULTS CONSISTING OF MULTIPLE PAGES IF THOSE RESULTS ARE RANKED BY DISTANCE. Thus it’s obvious how sufficient the reproduction steps I described initially are and how easy it is to reproduce the issue based on them.

Is there any progress in the reproduction and the resolution of this issue?

Thank you for the details provided so far.

Unfortunately, there has been no progress on the reproduction of this issue just yet. This is because additional information is required to confirm the issue, on top of the Nearby Search requests: which results in the 2nd page are closer than which results in the 1st page.

This involves extracting about 40 lat,lng coordinates from 2 API responses, calculating the distance from them to the lat,lng in the location parameter and comparing these distances before and after sorting. While not a complex operation to perform, it is one that is seldom necessary and therefore tools to facilitate/accelerate the task are not readily available on our side at the moment, which means it will take time.

We would be grateful if you have that information readily available.

I don't think any further information from me would somehow help you. As the information already provided is sufficient for you to be able to run all the requests and obtain all the results, and it’s important that you’ve performed all that yourself so that you can then attest the issue really exists.

Concerning the fact that you may need some tools to automate the reproduction of this issue, if you don’t have them you should do everything manually. Especially taking into account the fact that the issue is a prominent one and it’s relatively easy to reproduce it manually (actually you’d have already done that if you hadn’t spent time on meaningless communication in this thread).

All in all, a lot of time has passed since I reported this issue. And I (and other users of the Places API) would like to see some considerable progress on its resolution. What can you say in this respect?

Are there any updates?

If there’s no progress, I’ll have to use different channels of communication to complain about the fact that nothing gets done.

An update to the description of the issue: a few first results on the next page are less distant than the last result on the previous page, while they should have been equally or more distant (such a deviation is especially noticeable when you compare the third and second pages of the results).

I’m uploading two screenshots to illustrate the issue a bit. These screenshots are from an Android app that displays multiple-page results of ranking by distance.

On the first screenshot, you can see a few last items from the first page of the results followed by a few first items from the second page of the results: that is, a transition from the first page to the second page. The second screenshot is similar: it demonstrates a transition from the second page to the third page. On each of the screenshots, the last item from the previous page is circled with green, and the first item from the next page is circled with red, so it’s easy to see where exactly the transition occurs.

Now, as you can see on the screenshots, the first item (and several following ones) from the next page is less distant (what’s more, significantly) than the last item from the first page, while it should’ve been equally or more distant.

Thanks for reporting this issue. We have verified and logged it internally.  Please note that we cannot give you any timelines, but you can star the issue to get notifications.

In my last paragraph above, I should have written: "than the last item from the PREVIOUS page", not "than the last item from the FIRST page".

I'm shocked to see it's been over a year without this being resolved!  

How can the API not be considered fundamentally broken if the contract is that it should return results sorted by distance but it only does so within the first 20 results of a possible 60?  If there are matching results on pages 2 & 3 that are closer than the results on page one things aren't really sorted by distance!