Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip calculating step distance when too far away from the step #75

Merged
merged 2 commits into from
Aug 19, 2023

Conversation

boldtrn
Copy link
Collaborator

@boldtrn boldtrn commented Jul 21, 2023

This PR improves progress updates if the user is too far from the route. If the user is further away then 1km from the route, we don't progress along the step anymore.

Before this was done, independent of how far the user is away from the route.

This change should only be relevant if you have a fixed route, if you reroute, once the user if offroute, this should not be a relevant change.

@wipfli
Copy link

wipfli commented Jul 31, 2023

@Fabi755 would you be interested in reviewing this pull request?

@Fabi755
Copy link
Collaborator

Fabi755 commented Jul 31, 2023

Yes, I will review this PR this week 👍

Feature feature = TurfMisc.nearestPointOnLine(locationToPoint, stepPoints, TurfConstants.UNIT_KILOMETERS);

// Check distance to route line, if it's too high, it makes no sense to snap and we assume the step distance is the whole distance of the step
Number distance = feature.getNumberProperty("dist");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels a little bit ugly that we read a property here.

On other code parts we use something like this:

double distance = TurfMeasurement.distance(locationToPoint, (Point) feature.geometry());

But your solution is calculate the distance only once, while my variant is calculate the distance twice.

I think you can keep this, but if we need this a second time, we should wrap up this in some util function.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I know that this is pretty weird, but this is how you are supposed to use Turf AFAIK. Turf.js uses the same approach.

@Fabi755
Copy link
Collaborator

Fabi755 commented Aug 2, 2023

The code looks good for me 👍

For my understanding only two questions:

  1. Without this changes, do we have some downsides? Or what is the reason for fixing this?
  2. I think the 1 km are a good value. How you select them? Can be use cases where we need a lower or higher value?

@boldtrn
Copy link
Collaborator Author

boldtrn commented Aug 3, 2023

Without this changes, do we have some downsides? Or what is the reason for fixing this?

Quick explainer: with snapping in this context I mean that your location will be used for internal calculations on the route, not the visual snapping.

Yes, this is only relevant when you disable the route recalculation, so it is probably not super relevant for most users of the SDK.

You can be 50km away from the route, the SDK always snaps you to the closes point of the route, which makes no sense, if you are very far away from the route. The route progress will be increased and you skip ahead to a future part of the route. If you want to go back on the route at your original location, it can happen that the SDK does not recognises you to be back on the route, as you have skipped ahead already. I hope this makes sense? If not, let me know, I think it can better explained with a drawing :).

I think the 1 km are a good value. How you select them? Can be use cases where we need a lower or higher value?

I wanted to pick a reasonable distance where it makes sense that we actually consider a route snap. Right now I don't think we will need any higher values, if anything, maybe even lower values. While you are driving towards the route line, you will come closer than 1km to the route, and you will be snapped before you are on the route.

@Fabi755
Copy link
Collaborator

Fabi755 commented Aug 3, 2023

Now I get this! Thanks for your explanation!

All things look good to me and we can merge this.

@boldtrn
Copy link
Collaborator Author

boldtrn commented Aug 3, 2023

All things look good to me and we can merge this.

Thanks, maybe you can approve the PR (using the review option on Github)?

@Fabi755
Copy link
Collaborator

Fabi755 commented Aug 3, 2023

Ahh interesting, I thought this is only possible as maintainer

@boldtrn boldtrn merged commit e26aa48 into maplibre:main Aug 19, 2023
@boldtrn boldtrn deleted the distance_limit_snapping branch August 19, 2023 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants