Fuzzy behaviour

[krzysiek mbis]

Hi,
Let's consider below route:(Grossengotten -> Fuzzy via point near Berliner Ring -> Słupsk) (Fuzzy radius is 1000 m)

When Fuzzy via point is on the right side of highway ...

The route is as supposed to be:

But if user puts Fuzzy via point on the left side of highway...

The route is far from ok:

Even though It is near fuzzy point (less then 1000m), It turns back. Then It goes near the Fuzzy point, turns back again and goes to It's destination Point (Słupsk).
Our users complaint a lot on this. They would like from Fuzzy point and It's radius, to act as Fuzzy Point in a circle shape.
How can we do this ?
Is it even possible ?

Best Regards,
Kris.

[Bernd Welter]

Hi Kris,

imagine your waypoint desc list is A=>B(fuzzy 1000m)=>C

Fuzzyrouting - as far as I know - is based on the following strategy:

• Calculate a route (A => B)
• move backwards from B for the distance of the fuzzy radius. Let's label that so-determined point B* and a subroute (A => B*)
• create a second route (B* => C)
• concatenate (A => B*) + (B* => C) to the logical result

So if the via point's coordinate is located on the "left" side of the highway and the fuzzy distance is too short we have to calculate the malicious loop and the return path isn't long enough.

both routes have same fuzzy waypoint coordinates.
LEFT: radius = 100m
RIGHT: radius = 10'000m

I recommend to take into consideration that the fuzzy radius could be set to a larger value so the return distance is long enough to get rid of that effect.

By the way: this behaviour is not limited to "wrong side of the highway". It could also happen that the FUZZY coordinate B is located somewhere off the highway that the distance (highway => B) is greater equal the radius...

Best regards,
Bernd

[krzysiek mbis]

Hi,

I recommend to take into consideration that the fuzzy radius could be set to a larger value so the return distance is long enough to get rid of that effect.

Yea, but what radius is good generally ? In this situation It supposed to be 13 km. In other 4 km ets. So user complaints that he must guess and It takes time to get the job done.

So if the via point's coordinate is located on the "left" side of the highway and the fuzzy distance is too short we have to calculate the malicious loop and the return path isn't long enough.

Yeap, but in our situation user works in high alitude and he doesn't see that It is on the "left" side. One time It is on the "left" side one time on the "right" side. And "left" side "steals" kilometers. That is why He doesn't trust via points from high altitude and He must check the route in low altitude every time and when route is "bad" He must experiment with radius which is a waste of time.
He claims that all of his problems could be solved if Fuzzy via point with radius could work as circle area. If route is inside this circle it means that route is going through the Fuzzy via point. That is all He wants.
Can we somehow do it like that?

[Bernd Welter]

How about determining the radius based on the map interface's current scale?
If a user clicks on a 500km map he can't expect that the pixels are precise up to 7 digits behind the comma...

[krzysiek mbis]

Hi Bernd,
Yeah, It's tempting, but I'm afraid that It won't solve the problem. And It would create new ones (when Radius is too big then route could be different that we expect). Generally speaking of course.
Thanks a lot for your help.

Best Regards,
Kriss.

[Bernd Welter]

Let me know if you need more samples or info about the internal handling.

If a dispatcher creates a long distance tour on a wide scope the question is: what does he expect from a click.

[Bernd Welter]

well - let's change the perspective for a second:

How about offering "drag and drop" routing?
http://176.95.37.46/samplebrowser/#samp ... g-dnd/view

sounds like a valid offer for the users if they want to influence a route's overall direction

[krzysiek mbis]

Hi,
Actually, we are working on "drag and drop" routing.
And I also think that it might be a good alternative for users with "Fuzzy" problems.
Thanks for your help.

Best Regards,
Kriss.