Hello,
may I ask you is there any difference between Walking Trail and Pedestrian Boardwalk? There’s been a speculation that there will be some difference in how they route traffic. One will be used for routing and estimating ETA and the other won’t. Which one?
PB are ignored for routing, the navigation will guide the Wazer to the nearest drivable segment regardless of any PB which may be mapped closer to the destination.
WT, if connected to a drivable road AND being the closest segment to a destination, Waze navigation guides the Wazer to the closest node where the WT is connected to a drivable segment, where the Wazer should basically park and continue on foot.
Ok, thanks a lot, but this seems to me like a serious change in mapping habits.
I’ve always thought that WT is a path in a park or a very narrow passage accessible only by foot, while PB is a pedestrian/walking road/avenue in a city, like the ones across city squares.
If Pedestrian Boardwalk means alley along a body of water, I am afraid I won’t be using this road much.
That’s why some communities renamed the types from WT to “Pedestrian (routable)” and from PB to “Pedestrian (non-routable)”
You should focus more on their effect for routing and less on the way they are called in WME.
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
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.
If it works as hoped, it may also be a way to eliminate the hack at TheLastTaterTot’s Providence, RI train station
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.
You are right.
My own examples also stopped working… 
I’ll send an e-mail to Waze.
The pedestrian routing feature should still be considered under development, as I understand it (however, I’m not privy to GC conversation). Eventually, the intended function is to produce the fastest route, combining driving time and a fixed/per-unit-length walking time.
Hi!
I think I’ve got some good news:
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!
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:
Hmm, ok, perhaps I’ts my mistake because I expected the stop point of Waze Place, that is closer to the walking trail, to override the stop points of linked Google Places that are closer to other roads. This doesn’t seem to happen on Live Map when the search result is linked Google Place.
I also wanted to point out the importance of this feature for proper routing.
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.
@Kartografer, the routing uses walking trails on production server too but you need to test the routes in the app, not on Live Map. Also, I noticed that routing server cannot determine precisely the location of Place if it is slightly closer to one segment than to another. This sometimes causes problems with the correct mapping of the Place.