Yes, correct routing happens for walking trails on the beta server, but only if they are connected through normal nodes. The new phantom nodes do not give the correct routing behavior from both sides. Ruben's release notes today mention that this feature is still in development, and routing doesn't quite work yet, so we are on the same page there.

We used to use WT for access paths that could be reached from either end; Waze at that time would route to whatever end of the WT would be the fastest to drive to (provided the TRs were done right). This was great for certain train stations, for example, where no drivable road crossed the tracks but a pedestrian bridge or tunnel did.

With the new behavior, we can't use WT for those kinds of situations any more. Waze will prioritize for the shortest walk (even if it's shorter by only 1 meter) no matter how much longer the drive might be. Unless of course the WT behavior has changed again...


Sent from my iPhone using Tapatalk

petervdveen wrote:

DwarfLord wrote:With the new behavior, we can't use WT for those kinds of situations any more. Waze will prioritize for the shortest walk (even if it's shorter by only 1 meter) no matter how much longer the drive might be. Unless of course the WT behavior has changed again...

No, you misunderstood.

For walking 5km/h is taken into consideration.
But Waze will always take the fastest route, not the shortest walk. So your destination can be different based on your starting position.

Thanks, that's good news.

In fact, I'll test immediately. I have a specific train station in mind. It has one entrance on the north side of the tracks and another on the south side, joined only by a pedestrian access path, not a drivable road. Drivers should be routed to whichever entrance is the shortest drive -- regardless of whether the Waze stop point has been placed slightly closer to one entrance or the other. We get complaints when this doesn't happen. I will be delighted if the WT functions as you described and will report back here.

petervdveen wrote: No, you misunderstood.

For walking 5km/h is taken into consideration.
But Waze will always take the fastest route, not the shortest walk. So your destination can be different based on your starting position.

The tiles finally rebuilt and I could test, but I'm afraid my results are negative. It would appear I did not misunderstand. I'm sorry about that, because I would far rather that Waze worked the way you describe!

Here is the test case. There are some issues with Google pins in this area, but this Live Map test route was generated with simple location clicks rather than depending on Place lookups.

When I run this test, Waze takes me on a 7-minute drive to get to the north side of the station, when I'm starting only a 30-second walk from the south side, despite the connection of the target WT to the south access road.

This is the same behavior I encountered when I tested after the massive WT changes took place, so I am not surprised, but I am disappointed nevertheless.

petervdveen wrote:The WT issues seems solved in beta.

Indeed! Production routing still fails (i.e. optimizes for shortest walk, not shortest drive) but this is certainly hopeful news!

DwarfLord wrote:I'll test immediately. I have a specific train station in mind. It has one entrance on the north side of the tracks and another on the south side, joined only by a pedestrian access path, not a drivable road. Drivers should be routed to whichever entrance is the shortest drive -- regardless of whether the Waze stop point has been placed slightly closer to one entrance or the other. We get complaints when this doesn't happen. I will be delighted if the WT functions as you described and will report back here.

If it works as hoped, it may also be a way to eliminate the hack at TheLastTaterTot's Providence, RI train station

DwarfLord wrote:With the new behavior, we can't use WT for those kinds of situations any more. Waze will prioritize for the shortest walk (even if it's shorter by only 1 meter) no matter how much longer the drive might be. Unless of course the WT behavior has changed again...

No, you misunderstood.

For walking 5km/h is taken into consideration.
But Waze will always take the fastest route, not the shortest walk. So your destination can be different based on your starting position.

DwarfLord wrote:This is the same behavior I encountered when I tested after the massive WT changes took place, so I am not surprised, but I am disappointed nevertheless.

You are right.
My own examples also stopped working..

I'll send an e-mail to Waze.

Hi!

I think I've got some good news:
The WT issues seems solved in beta.

From North:
https://www.waze.com/nl/livemap?rp_id=b ... t_text=Now

From South:
https://www.waze.com/nl/livemap?rp_id=b ... t_text=Now

USA:
https://www.waze.com/nl/livemap?rp_id=b ... t_text=Now

WazingArch wrote:

petervdveen wrote:Hi!

I think I've got some good news:
The WT issues seems solved in beta.

I cannot confirm this because I see places located above underpasses or tunnels and Waze still routes to the underground road and not to the relevant walking trail near the place.

You can take a look at the following example - try to route to this post office located above a underpass.

Because it's closer:

https://www.waze.com/bg/livemap?lon=24. ... t_text=Now