Hmm... This is what I get for a model version of the example setup.

http://imageshack.com/a/img673/4074/5xVzlk.png
http://imageshack.com/a/img673/4074/5xVzlk.png

And the original setup:
https://wiki.waze.com/wiki/images/a/a2/ ... l_dest.png

And the livemap PL to my model setup:
https://www.waze.com/livemap?lon=-152.2 ... -152.29087
Note for when playing with the setup from livemap — as of the time of this posting, Places in the livemap seem to be asynchronized with Places in the app.

----
P.S. Re your DM from today, from my testing, TBTRs and TRs have the same penalty and behave the same (with the exception of being able to use TBTRs as a hack to break a specific case of BC, I believe). Ulgh, I really need to get all my results compiled and onto my wiki soon...

Perhaps we should put this revision on hold until the behavior of walking trails is more consistent? The Waze staff is looking into it right now and hopefully we will get word back soon.

To reiterate a conversation that occurred in a Google Hangout: Presently, Walking Trails appear to be partially routable... at least in Waze 4.0.x Public Release.

If you start on a Walking Trail, Waze can route within the Walking Trail segment, as well as out of it assuming the turns are allowed. However, you cannot route onto a Walking Trail regardless of allowed turns. This includes not being able to route from Walking Trail segment to another Walking Trail segment.

https://dl.dropboxusercontent.com/u/280 ... within.jpg
The screenshot above shows routing within a single Walking Trail segment.

---
Moreover, to confirm what has already been said about routing to a destination closest to a Walking Trail — Waze will try to route to the closest segment junctioned with the Walking Trail (regardless of any TRs). Unfortunately, it's not perfect; sometimes the route will stop before reaching the Walking Trail junction. The screenshot below shows expected behavior:

https://dl.dropboxusercontent.com/u/280 ... e2dest.png

---
Critically, unlike Pedestrian Boardwalk type, it appears that your current position can snap to a Walking Trail.

https://dl.dropboxusercontent.com/u/280 ... tnight.jpg

In the above screenshot, I've drawn a short Walking Trail segment in my backyard. My current GPS position is indicated by the yellow arrowhead and the snap position is indicated by the blue arrowhead. Since this Walking Trail is disconnected from the road system and Waze has snapped my current position to the disconnected Walking Trail segment, I am unable to find a route out.

---
The behaviors highlighted above is relevant because if Waze decides to make this permanent, we may want to advise editors to always connect a Walking Trail to drivable road, otherwise one may snap to a disconnected Walking Trail and would be unable to route off of it. Moreover, we may want to allow turns off a Walking Trail segment in certain situations. In contrast, when turns off a Walking Trail have been disallowed, Waze appears to start the route from the nearest drivable segment, which may be a desirable behavior in many other scenarios:

https://dl.dropboxusercontent.com/u/280 ... outTRs.png

--------------------------
Interestingly (and surprisingly), when I install and use a custom color scheme, Walking Trails appear to be as inert as Pedestrian Boardwalks. I can no longer route within a Walking Trail, nor does my current position snap to the Walking Trail segment:

https://dl.dropboxusercontent.com/u/280 ... utable.jpg

https://dl.dropboxusercontent.com/u/280 ... scheme.jpg

--------------------------
To summarize:
Using the default color scheme (night or day):

• Routing to a destination closest to a Walking Trail will attempt to stop at the nearest drivable segment junctioned to the trail.
• Walking Trails appear to be snap-able and this behavior has an effect on routing to a destination.
  • Waze will fail to find a route when snapped to a disconnected Walking Trail.
  • When starting on a Walking Trail, Waze can route within the Walking Trail segment.
  • When starting on a Walking Trail and turns are allowed, Waze can route off the Walking Trail segment.
  • When starting on a Walking Trail and turns off the segment have been restricted, Waze may move the start of the route to the closest drivable segment, which may or may not be accessible in real life.

Using a custom color scheme, Walking Trails appear to behave like Pedestrian Boardwalk. That is, there is no snapping, and when a destination is closest to a Walking Trail, Waze will route to the nearest drivable segment closest to the destination.

https://dl.dropboxusercontent.com/u/280 ... scheme.png

herrchin wrote:TheLastTaterTot, does LiveMap then have the "custom color scheme" behavior? Using DwarfLord's example again, here's the LiveMap using the nearest drivable segment closest to the destination, ignoring the presence of the WT completely.

Edit: The behavior of WTs appears on the LiveMap appears to be consistent with the expected behavior described by Waze. Sort of. It also does route within itself, but it does so oddly.

Try routing from a point on the Walking Trail to another point within the same segment. Pesach said he got routing over the Walking Trail using default and custom themes in Waze 3.9.x Android.

herrchin wrote:Does the custom color scheme have some impact on snapping local position only? (I can't imagine it has any impact on routing server decisions).

It may be conceivable that even though snapping occurs on the client-side, it can send the starting position information to the routing servers and thus affect routing in this way. If the starting position is on a disconnected segment, the routing server might not be able to find any alternative routes and fails. ...just guessing here. I have no idea how the color scheme can affect routing to destinations close to Walking Trails... but as shown in the screenshot, it happened.

herrchin wrote: The results of your screenshot on this are inconsistent with testing DwarfLord's railroad place. Can you repeat the test there please? What you described is the behavior DwarfLord originally intended, but doesn't seem to be working anymore in LiveMap or app for his example (but strangely does for your test setup).

It's not inconsistent. It's because the other end of the WT is not connected to any drivable roads. If you put the destination on the WT before the half way mark, it will route to the drivable segment attached to the closest junction, which is the PLR.

https://www.waze.com/livemap?lon=-122.0 ... -122.06268

I would be curious what would happen if you looped the WT around and attached the other end to the PLR (without cutting the WT into more than one segment)

It's specific to Walking Trails. Waze ignores the PB segment and only cares about the location of the destination relative to drivable segments.

Thanks for doing that test, DL!

It is expected behavior, but IMHO, not ideal behavior. Otto believes this happens because the end of a disconnected segment is still considered a junction, a terminal junction. I think that Pz mentioned in the Routing GHO that Waze is going to look into fixing this, but he might have been referring to something else. I'll ask him to confirm.

I think this behavior is very similar to restrictions on segments. I would not be surprised if they simply co-opted the current rules for routing to a restricted segment and associated them with Walking Trails as well. The idea of choosing the junction that is closest to the destination pin makes sense when you have a Walking Trail that is connected to drivable road on both ends. You could think of it as routing to the junction of the WT that would result in the least distance one would have to walk to the destination. Of course, this fails to work as intended when Waze considers the "terminal junction" as a valid junction to try to route to.