Uber Drivers Forum banner
1 - 7 of 7 Posts

·
Registered
Joined
·
678 Posts
Discussion Starter · #1 ·
OK guys, I had that feature for a while, they took it away (it is not that much of app driven but server driven, who's account to turn on)
I did extensive tests few days that I had and I can say this (I covered this throughout on our whatsapp group)

It is called destinations mistakenly, it should be called Along-the-route (ATR)
The way it works is simple, at any point of your origin (where you are parked at the moment) to the destination you entered the system draws a suggested map (using google maps) and it sends you requests that go ATR.
What this means is practically it is not guaranteeing you will get closer to your destination, it won't even guarantee you will not go east when you entered west destination, it just guarantees your ride will be ATR (with a little detour to drop off passenger), the route of google maps.

To better understand the concept here is an example. Say you are around Yonge/Adeliaide and your destination is set to Bathurst/Major Mackenzie in Richmond Hill, technically from the point you are to the point you have destination is NORTH/WEST, a bit west and a lot north but still a bit WEST.
Now your most typical Google maps route will be take Yonge south, take Gardiner east, DVP north etc towards Richmond Hill.

Now you have the mode on and you get a request say from say Dundas/Yonge, you go pick up a person and it turns out pax is going Yonge and Front, yes it is ATR, since it is technically along the projected trajectory of your route from the moment of your request to your destination.

Understandingly most of you will be ultra-unhappy in such scenarios, so here is the trick for you how to utilize maximum of this feature.

1. Do not drive around after entering destination, every movement your GPS tracks, it will recalculate the above mentioned route to your destination and will try to search matches again. So after entering destination just park and wait.
2. Right after entering destination, go to google maps, enter the destination there too and see suggested route (it always chooses fastest over shortest for some reason). Project the trajectory in your mind and remember.
3. When getting a matched request try to analyze pickup location, if it's opposite way on ATR (revisit the scenario I described above) ignore it, because just like in the scenario above you will most likely waste time and gas to move someone a few meters ATR from your initial location.
4. If you get someone requesting you exactly from around ATR, say in the above mentioned scenario it was request not from Dundas/Yonge but say Wellington/Yonge, it is higher chance that the person will continue following the route.
5. Even if 4th happens it still not a guarantee you will get really close to your destination since your ride might just actually "exit" along the route very close by, but still at least you did not waste time and gas traveling and picking up someone from opposite direction.
6. And as people said it still keeps the mode on, so you might get another one, getting you a bit closer, but remember after completing trip, you need to park again and start from 1st step, since now your new google maps route towards your destination might have changed.

So it's a poor implementation. I red their blog on technology behind this, lot of math, probability theory behind it, standard dispersion etc, but poor implementation and not understanding what actually would made lot more sense for drivers.

This is one example that in technology choosing fancy over simple is not always a right choice.

What they should have done is very simple for even computer science co-op to implement.

|). Driver parked at point X enters destination D, they calculate shortest (not fastest) route X to D.
Let's call that R1 distance.
||). When requests comes from a point Y and say it is R2 distance from point of your parked origin X and say it is going to point Z which is R3 distance away from point of origin of request (point Y) and R4 distance away from the final destination of D.

Got it? Please read carefully above | and ||, virtually understand X Y Z, D points and R1, R2, R3, R4 distances

App should simply filter and send you requests where R2+R3+R4 < R1. Very simple to implement, does not matter your ATR, what does matter to get physically closer to your destination.

With current implementation drivers need to be smart follow my suggestions of 1 to 6 to chose what to accept and what not and still not guaranteed if they will get closer to their destination.

But again, I am not their developer ;)
 

·
Premium Member
Joined
·
8,989 Posts
At least if I'm downtown the system should not send me to Burlington when I want to go to North York. I do agree you could get stuck doing a ton of short hop rides downtown but in the end this is better than not having something. This should eliminate many of the people who want to go to Oakville and Burlington but get rides that take them to Ajax and Oshawa.

While not perfect I will take it.
 

·
Registered
Joined
·
169 Posts
Exactly, I live near dvp and York Mills. I often end up in Mississauga, anything east is perfered, I hate being taken to Burlington. This may not be perfect but I like it so far
 

·
Registered
Joined
·
582 Posts
OK guys, I had that feature for a while, they took it away (it is not that much of app driven but server driven, who's account to turn on)
I did extensive tests few days that I had and I can say this (I covered this throughout on our whatsapp group)

It is called destinations mistakenly, it should be called Along-the-route (ATR)
The way it works is simple, at any point of your origin (where you are parked at the moment) to the destination you entered the system draws a suggested map (using google maps) and it sends you requests that go ATR.
What this means is practically it is not guaranteeing you will get closer to your destination, it won't even guarantee you will not go east when you entered west destination, it just guarantees your ride will be ATR (with a little detour to drop off passenger), the route of google maps.

To better understand the concept here is an example. Say you are around Yonge/Adeliaide and your destination is set to Bathurst/Major Mackenzie in Richmond Hill, technically from the point you are to the point you have destination is NORTH/WEST, a bit west and a lot north but still a bit WEST.
Now your most typical Google maps route will be take Yonge south, take Gardiner east, DVP north etc towards Richmond Hill.

Now you have the mode on and you get a request say from say Dundas/Yonge, you go pick up a person and it turns out pax is going Yonge and Front, yes it is ATR, since it is technically along the projected trajectory of your route from the moment of your request to your destination.

Understandingly most of you will be ultra-unhappy in such scenarios, so here is the trick for you how to utilize maximum of this feature.

1. Do not drive around after entering destination, every movement your GPS tracks, it will recalculate the above mentioned route to your destination and will try to search matches again. So after entering destination just park and wait.
2. Right after entering destination, go to google maps, enter the destination there too and see suggested route (it always chooses fastest over shortest for some reason). Project the trajectory in your mind and remember.
3. When getting a matched request try to analyze pickup location, if it's opposite way on ATR (revisit the scenario I described above) ignore it, because just like in the scenario above you will most likely waste time and gas to move someone a few meters ATR from your initial location.
4. If you get someone requesting you exactly from around ATR, say in the above mentioned scenario it was request not from Dundas/Yonge but say Wellington/Yonge, it is higher chance that the person will continue following the route.
5. Even if 4th happens it still not a guarantee you will get really close to your destination since your ride might just actually "exit" along the route very close by, but still at least you did not waste time and gas traveling and picking up someone from opposite direction.
6. And as people said it still keeps the mode on, so you might get another one, getting you a bit closer, but remember after completing trip, you need to park again and start from 1st step, since now your new google maps route towards your destination might have changed.

So it's a poor implementation. I red their blog on technology behind this, lot of math, probability theory behind it, standard dispersion etc, but poor implementation and not understanding what actually would made lot more sense for drivers.

This is one example that in technology choosing fancy over simple is not always a right choice.

What they should have done is very simple for even computer science co-op to implement.

|). Driver parked at point X enters destination D, they calculate shortest (not fastest) route X to D.
Let's call that R1 distance.
||). When requests comes from a point Y and say it is R2 distance from point of your parked origin X and say it is going to point Z which is R3 distance away from point of origin of request (point Y) and R4 distance away from the final destination of D.

Got it? Please read carefully above | and ||, virtually understand X Y Z, D points and R1, R2, R3, R4 distances

App should simply filter and send you requests where R2+R3+R4 < R1. Very simple to implement, does not matter your ATR, what does matter to get physically closer to your destination.

With current implementation drivers need to be smart follow my suggestions of 1 to 6 to chose what to accept and what not and still not guaranteed if they will get closer to their destination.

But again, I am not their developer ;)
Great info.. Thank you so much for sharing this very valuable info with us..
 

·
Registered
Joined
·
2,544 Posts
OK guys, I had that feature for a while, they took it away (it is not that much of app driven but server driven, who's account to turn on)
I did extensive tests few days that I had and I can say this (I covered this throughout on our whatsapp group)

It is called destinations mistakenly, it should be called Along-the-route (ATR)
The way it works is simple, at any point of your origin (where you are parked at the moment) to the destination you entered the system draws a suggested map (using google maps) and it sends you requests that go ATR.
What this means is practically it is not guaranteeing you will get closer to your destination, it won't even guarantee you will not go east when you entered west destination, it just guarantees your ride will be ATR (with a little detour to drop off passenger), the route of google maps.

To better understand the concept here is an example. Say you are around Yonge/Adeliaide and your destination is set to Bathurst/Major Mackenzie in Richmond Hill, technically from the point you are to the point you have destination is NORTH/WEST, a bit west and a lot north but still a bit WEST.
Now your most typical Google maps route will be take Yonge south, take Gardiner east, DVP north etc towards Richmond Hill.

Now you have the mode on and you get a request say from say Dundas/Yonge, you go pick up a person and it turns out pax is going Yonge and Front, yes it is ATR, since it is technically along the projected trajectory of your route from the moment of your request to your destination.

Understandingly most of you will be ultra-unhappy in such scenarios, so here is the trick for you how to utilize maximum of this feature.

1. Do not drive around after entering destination, every movement your GPS tracks, it will recalculate the above mentioned route to your destination and will try to search matches again. So after entering destination just park and wait.
2. Right after entering destination, go to google maps, enter the destination there too and see suggested route (it always chooses fastest over shortest for some reason). Project the trajectory in your mind and remember.
3. When getting a matched request try to analyze pickup location, if it's opposite way on ATR (revisit the scenario I described above) ignore it, because just like in the scenario above you will most likely waste time and gas to move someone a few meters ATR from your initial location.
4. If you get someone requesting you exactly from around ATR, say in the above mentioned scenario it was request not from Dundas/Yonge but say Wellington/Yonge, it is higher chance that the person will continue following the route.
5. Even if 4th happens it still not a guarantee you will get really close to your destination since your ride might just actually "exit" along the route very close by, but still at least you did not waste time and gas traveling and picking up someone from opposite direction.
6. And as people said it still keeps the mode on, so you might get another one, getting you a bit closer, but remember after completing trip, you need to park again and start from 1st step, since now your new google maps route towards your destination might have changed.

So it's a poor implementation. I red their blog on technology behind this, lot of math, probability theory behind it, standard dispersion etc, but poor implementation and not understanding what actually would made lot more sense for drivers.

This is one example that in technology choosing fancy over simple is not always a right choice.

What they should have done is very simple for even computer science co-op to implement.

|). Driver parked at point X enters destination D, they calculate shortest (not fastest) route X to D.
Let's call that R1 distance.
||). When requests comes from a point Y and say it is R2 distance from point of your parked origin X and say it is going to point Z which is R3 distance away from point of origin of request (point Y) and R4 distance away from the final destination of D.

Got it? Please read carefully above | and ||, virtually understand X Y Z, D points and R1, R2, R3, R4 distances

App should simply filter and send you requests where R2+R3+R4 < R1. Very simple to implement, does not matter your ATR, what does matter to get physically closer to your destination.

With current implementation drivers need to be smart follow my suggestions of 1 to 6 to chose what to accept and what not and still not guaranteed if they will get closer to their destination.

But again, I am not their developer ;)
How many in your whatsapp group? How do I join?
 
1 - 7 of 7 Posts
Top