Made Split to Nearby Query into a fast query for coordinates + a details query for each pin

[kanahia1]

Description (required)

Fixes #4560

What changes did you make and why?

• Splitted to the query into two queries
• Improved the pop up for the marker which will probably fix Nearby: Pins overlapping place name  #5692

Tests performed (required)

Tested prodDebug on Samsung S21 FE with API level 33.

Screenshots (for UI changes only)

WhatsApp.Video.2024-05-14.at.20.36.17_5a90b1f7.mp4

[nicolas-raoul]

Testing now.

Just wondering: Is there a specific reason why your branch is called kanahia1-main?
It is usually good to have a branch name that reflects the issue ID and an extremely short summary of the issue.
It makes it easier to work on different things in parallel. :-)

[kanahia1]

There's no specific reason for it 😄 From next time I will try to follow proper naming.

[nicolas-raoul]

Would you mind implementing a loop that asynchrously loads each item's details, for all shown points? Depending on the user's settings it will make many points disappear, which is not ideal user experience but it is the best we can do while having fast nearby maps in areas with many items.

Thanks! 🙂

[kanahia1]

Sure, I will do asynchronous loop to load pin's details

[kanahia1]

Hey @nicolas-raoul, I'm bit confused here.

Should the queries look like given below?

1. Run query for loading only pins (coordinates)
2. Run query to load all the data about all the pins async, which may also remove the pins from screen (This query will be similar to what we have already)
3. In case, user clicked over the pin and data has not been loaded (from 2.) then run query to load data for that particular pin as it is much faster.

[nicolas-raoul]

Sounds good! :-)

For the second query, you can specify the QIDs of the pins, that will make the query much faster.
Here is a example of how to specify QIDs: https://www.wikidata.org/wiki/User:Vojt%C4%9Bch_Dost%C3%A1l/app-Czech_uploads
I believe this is the relevant documentation: https://www.w3.org/TR/sparql11-query/#inline-data
Obviously, the second query does not need to care about coordinates.
Let me know if anything is unclear. :-)

[nicolas-raoul]

By the way, I believe it would be user-friendly to first show pins in grey color to mean "unfiltered". Then upon receiving the result from the second request, hide the pins that do not match the filter, and set the normal color to the pins that match the filter. What do you think? 🙂

[kanahia1]

Yeah, That would be great!

[kanahia1]

Hello @nicolas-raoul, I have improvised query as per suggestions by you and it's working fine for the smaller regions

WhatsApp.Video.2024-05-16.at.15.15.29_37c183a9.mp4

But I have faced an issue because we are using List of QID (which becomes really large for city like capital of India) the server returns error 414 which is because our url length exceeds a limit (which is because of the large query)

WhatsApp.Video.2024-05-16.at.15.16.45_392342b7.mp4

How about replacing the List of QID with similar method we had earlier?

[nicolas-raoul]

Would you mind splitting the second query into several queries of 50 QIDs max, and using the results as they come? Ideally sort them by their distance to the center of the search rectangle, then run the queries starting from the nearest 50 QIDs.

Sorry to add something again, but when a not-yet-loaded QID is tapped by the user, it would be great to run the second query for that point, in parallel with the above, it will probably return the result fast and the user will see the label/class/filter status/etc without having to wait for all points to load.

[kanahia1]

Thank you for suggestion and I feel it will make queries even better.

And I have added that when pins are not loaded still the user can get the details for a pin.

Screen_Recording_20240516_164159_Commons.mp4

[kanahia1]

Hello Nicolas, I have divided the second query into batches fixing the issue we were facing due to large size of second query. Now the first query has became more effective.

VID-20240517-WA0007.mp4

[nicolas-raoul]

It is getting better and better, keep up the great work :-)
Brilliant work on the SPARQL query especially!

[kanahia1]

Hello Nicolas, Thanks for the suggestions and now loading of pins has became even more efficient.

WhatsApp.Video.2024-05-18.at.11.13.21_560bd12d.mp4

[nicolas-raoul]

Looks fantastic! I will try it as soon as I get home. 🙂

[kanahia1]

Hi @nicolas-raoul, on digging I am able to find that issue was caused by ongoing network call which was not stopped on starting new call. Now I have updated the code, I hope it should fix up the issue.

WhatsApp.Video.2024-05-19.at.10.03.18_d70e1a6f.mp4

[nicolas-raoul]

I am experiencing several unexpected things, especially when swgitching to other apps or when the screen goes black:

screen-20240519-213301.mp4

Also, maybe modifying the default zoom level would be good (zoomed more, mening it loads less items by default).

[kanahia1]

Sure, I will update the zoom level ;-)

I tried switching apps. It moves the map to the default location

VID-20240519-WA0003.mp4

Actually It wasn't clear from the video provided. On switching apps the map return to the my location (in my case)