[HOLD for payment 2024-01-11] [$500] New Feature request: Add LocationBias to distance requests

[thienlnam]

Problem

Right now, when using distance split requests, if I input my starting location as "Portland Oregon", I would expect when I click into "finish" to put my destination address that anything I type in would zero me in closer to "Portland Oregon". Instead, I'm shown random a completely random address in KS. Why is that?

Why is this important?

When you've already put a starting point in, it's expected it'll show you destinations close to your starting location. This is expected behavior on all modern maps features and a great polish item. Without this, you'd basically have to type out the entire destination address and that's a PITA.

Solution

Add a locationbias to the search results which would help with this

Original conversation here

cc @joaniew

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~0159f03026153d7509
• Upwork Job ID: 1729223415881756672
• Last Price Increase: 2023-12-11
• Automatic offers:
• rojiphil | Contributor | 28061698

[melvin-bot]

Triggered auto assignment to @miljakljajic (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~0159f03026153d7509

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @parasharrajat (External)

[DylanDylann]

Proposal

Please re-state the problem that we are trying to solve in this issue.

• New Feature request: Add LocationBias to distance requests

What is the root cause of that problem?

• Currently, we does not sort the result by distance

What changes do you think we should make in order to solve the problem?

• We can use the rankby=distance parameter in the Autocomplete API request like below:

<GooglePlacesAutocomplete
        query={{
          location: `${startLocation.latitude},${startLocation.longitude}`
          rankby: 'distance', // Sort results by distance
        }}
      />

• startLocation is easy to get from the previous waypoint.

What alternative solutions did you explore? (Optional)

• NA

[allroundexperts]

Proposal

Please re-state the problem that we are trying to solve in this issue.

New feature to add location bias.

What is the root cause of that problem?

N/A

What changes do you think we should make in order to solve the problem?

Here, we should add the following and introduce a new locationBias prop:

 locationbias: props.locationBias

Once the above prop is added to the AddressSearch component, we'll then add the following changes to the WaypointEditor component here:

    const previousWaypoint = lodashGet(allWaypoints, `waypoint${waypointIndex - 1}`, {});

Next, here, we'll specify the locationbias as:

<AddressSearch
   {...waypointIndex > 0 && { locationBias: `circle:50@${previousWaypoint.lat},${previousWaypoint.lng}` }}

Note that, 50 is the radius I've chosen to search for. I think we can change this so that it gets picked up from a CONST file and can be decided in the PR.

There can also be multiple stops in a distance request and as such, I'm using the biasing based on the last selected waypoint. This can also be changed in the PR based on the requirements.

Lastly, I'm using circle as the biasing parameter. It can also be a rectangle but in order to do that, we need to specify at-least two points (which might not be always available).

What alternative solutions did you explore? (Optional)

None