US-1 to SR-29 connector classification

On Sunday, I did a route between Woodhaven Road in PA to Great Adventure and was pleasantly surprised to get a route near Trenton that worked really well – avoided tolls (that I didn’t have set to do so) and was faster.

https://www.waze.com/livemap?lon=-74.44181&lat=40.13908&zoom=17&from_lat=40.10276&from_lon=-74.99053&to_lat=40.13909&to_lon=-74.44181

(You may have to select Sunday at noon to see the route since at rush hours it probably sucks)

But during the actual drive I saw it go across a primary street which sort of surprised me. I looked at the classification maps and couldn’t tell really would it should be.

Regardless, my question is, should it be higher than a PS mainly because it’s basically a feeder between two freeways? (well, SR-29 is shortly a MH in that area)

These are the segments I am referring to (S Warren Street)

https://www.waze.com/editor/?env=usa&lon=-74.76466&lat=40.20862&zoom=6&segments=31688702,31679790,61834411

There’s a ramp from US-1 that dumps to a PS. It’s clearly not intended for local traffic only. Therefore to give Waze an easier time calculating a route that includes that – especially on longer drives – should its classification be upgraded?

Nice, how were the lines at Great Adventure?

Im actually fairly familiar with this ramp/route as I used to commute to PA.

I definitely see your point regarding continuity; we do not want this route to get pruned. At the same time we also dont want to make S Warren St more desirable for the local drivers in the area. It is tough to see but the FC map has this section as a local road- I blew it up to make it easier to identify:

S.Warren.jpg
So, 1- We already have it upgraded to PS from Street and 2- Waze seems not to have any problem finding this route; I tried it at almost every possible time and it always shows up either first or second in LM. The client listed the route second as well when I tested it at around 4:30 pm. See below. It appears that the upgrade to PS is sufficient for our purposes, giving longer drivers the route while not effecting local drivers. What do you think?

S.Warren.Rts.pngS.Warren.Map.png

TL;DR - Segments already upgraded to PS, additional upgrade to mh/MH unnecessary as routing works as expected.

Wow, thank you for the comprehensive explanation. I know you spent some time on it.

I ran several more scenarios thinking I could make it fail by making the route longer, but was unable to. I stretched the destination out to the shore and kept backing up the origin further west into PA until it really made no sense to go that way but more sense just to go down the PA Tpk.

ps, lines at Six Flags weren’t bad but Kingda Ka kept failing with technical difficulties whilst we were queued up for it (I have an English niece visiting for two weeks, so getting my Brit-speak on). We never did get to ride it. :frowning:

That doesnt make sense, Kobe. The longer the route, the more it prunes, not the other way around. If it isn’t pruned for long routes, then it won’t get pruned for short routes.

Heh?

The point is it doesn’t get pruned, even on the longer routes Poncewattle tested.

I’m not sure I understand your concern.

Did you try the route with much further end points? Road type continuity strongly suggests that connector road should be MH since its is not controlled-access and connects Fwy to MH/Fwy.

Have you guys read the entire thread?

Perhaps, I wasn’t clear. Yes, I tested longer end points; Poncewattle tested longer end and start points. Routing works perfectly for those using the highways. We acknowledged continuity in the first 2 posts and that was the basis for the question. Continuity is VERY important as it ensures correct routing. If routing is working however, continuity should not play a role as it will only effect the local drivers. If we upgrade it further it will directly effect the constant flow of local traffic in this area. So the question is has anyone tested longer routes that failed? If yes then absolutely we should upgrade it to MH. Otherwise, are there any other reasons to upgrade it that I overlooked?

If it ain’t broke , don’t fix it IMHO.

I think it might make a difference with a route long enough but the east end points are limited by the ocean and further west you go the Turnpike sweeps to the north and hence ends up being the smarter choice for routing regardless.

It’s an interesting technical exercise so was hoping honestly for a demonstrated failure as a learning exercise. But alas, didn’t find one.

I was asked for my 2 cents, i decided to give 3. Here goes, FWIW:

tl;dr: Even though it may “seem” to be working without any ill effects as-is, there may be special circumstances where it is having a negative effect on routing. Therefore it may still be advantageous to maintain continuity.

  1. The reason it comes up as the 2nd option is probably because it is no toll, and the first option is toll. When the first option is toll the second option will be no toll even if it’s much longer (if at all possible).

  2. There’s preference AND pruning, they are often confused but they are two different things. Preference always applies even on short routes, and may be having an effect here. Preference may be preventing this route from ever being the first suggestion, under normal circumstances.

  3. Pruning only applies on longer routes, and while on a normal day any longer route should use the turnpike regardless, making this route be not pruned is still adventageous. We still want the routing server to have alternate options if it wants to avoid heavy traffic, an accident, or a road closure. If this route is being pruned, and there’s severe traffic on the turnpike, it may still not detour around the traffic, if all the alternate routes are being pruned.

Sent using Tapatalk for Android 4.4.2

Thanks PZ for the detailed response. I’m on the road and will reread it again shortly I just wanted to understand this: 1 - What is considered a longer route? 2 - What do you mean by under normal circumstances? I just tested it again - from Woodhaven Rd in PA to Pine Park in Lakewood, NJ and the route in question showed up first.
Screenshot_2015-05-10-21-06-20.pngScreenshot_2015-05-10-21-06-09.png
It’s a 50 mile route offered first (tolls allowed).

My dilemma is do we really have to concern ourselves with the possibility that there may be a special scenario or corner case where the apparent correct routing my not work and assume that the reason it didn’t work is because of continuity? Is continuity a strong enough argument to effect local traffic patterns beyond reasonable doubt ?

Kobe,

It isn’t a concern. I just think you reversed the applicability of pruning to local versus long distance routes. Pruning occurs when Waze ignores lower-typed roads for the bulk of the route. For a medium distance trip, it may ignore street and primary street. For a long trip, it may start ignoring minor highways. You would not find pruning for very short “local” trips at all.

As to PZ’s discussion of preference, I’m not aware of road type playing a role preference, at least not directly. Waze will prefer two things:

  1. speed, based on various combinations of measurements
  2. special rules to eliminate unwanted behavior, including “smoothing”/detour prevention

There’s also some evidence that it gives preference to road segments you’ve traveled on previously. Indirectly, road type plays a role in preference, because when Waze is missing speed data for a segment, it will make some assumptions based on road type.

If there’s some aspect of “preference” that I’m missing, please elucidate.

Qwalatee,

A.

Where did you get that from? I simply consider this route to be long enough to be applicable. Plus we tested longer routes which absolutely* are applicable to PS pruning, yet waze chose it as the first option, multiple times. (*absolutely = AFAIK.)

B.

Are you answering this question?

C.
When it comes to routing, there are some things which we (read:I) will never understand or know completely. There are certain aspects of routing that we (I) think we (I) know and then I realize that in reality I literally know absolutely nothing about. The sort of information that would likely cost me about a smooth billion. But there is one thing I know forsure: Routing works here. Period. I know this because I tested it. On Livemap and on the client. I know this because others have tested it as well and returned the same results.
I also know that based on what we know this should not be the case. Based on all the knowledge cited in this thread, this route SHOULD NOT work. But it does. That is an indisputable fact that is well documented above.

D.
Based on the results displayed here, we can either conclude and say -

  1. …It works - perhaps waze is ignoring the 2-3 segments, perhaps this PS got preference from someone or something, perhaps {fill in the blank} - lets leave it as is.
  2. …The fact that it works is an anomaly/illusion/misunderstanding and we should follow what we know (blindly?).
  3. …Tests are wrong; we are right - it does not work. Here’s why… {prove it}.

E.
Correct me if im mistaken but I believe you are saying option 3 - your test results are wrong/inapplicable. However, I don’t hear any substantial proof or evidence of that being the case. I hear a lot of words such as “think”, “may”, “some evidence”, “indirectly”. But I have yet to hear an explanation which would deem the test results as false. PZ had a fantastic explanation regarding the second/toll-less option, but further testing showed that explanation stood on shaky ground.

F.
Im still just as confused from this post as I was from your last one. Are you explaining why the routing worked or why my solution to the OP was incorrect? Are you saying my reasoning doesnt make sense or that the route posted doesnt make sense?

G.
The most simple out, would be to prove that a 48 mile route is just not long enough for pruning of PS segments. But if that’s the case, if 50 miles is not a long enough commute for waze to use this magical system I will go back to never understanding “pruning”.

H.
FWIW, I am perfectly happy with the results here. A considerably short segment connecting a FWY->MH/FWY, typed PS and in the middle of a 50 mile route is entirely acceptable to me and I stand by my advice to leave it as is. Had the segment been in the beginning of my trip and was 5 mile long, then id be singing an entirely different tune. That said, instead of running around in circles, lets present this to Waze and see if they can help shed some light here - one way or the other.

Finally, please refrain from using names in the forums.

Do we know if the use of a relatively short PS connector between highways as part of a longer trip in which we would otherwise expect PS roads to be pruned is in spec for how navigation is supposed to work?
I mean it’s ultimately up to you guys here, but it’s also very possible that the PS segments working here is the result of a bug in the routing system - a bug which could be silently fixed at any time, thus breaking any configurations relying upon it. For that reason, I would strongly recommend not doing anything that would encourage similar treatments elsewhere by other editors, even if it means not documenting this in the wikis or even just plain not doing it here either.

We did discuss with a routing expert the effect of few PS segments in a long route. I’ll ask Otto to look here, otherwise if everything we know days it shouldn’t work, let’s ask Waze to verify if it is a bug.

Sent using Tapatalk for Android 4.4.2

Kobe, I’m not expressing anything about this specific instance. i’m addressing isolated comments within your explanation. We know based on previous communication from Waze and many past routing tests that short routes don’t use pruning, long routes do, and an isolated low-rank segment has been seen in at least some cases to apparently block a route from consideration due to pruning. Might that have changed? Might there be outlier cases where routes do not get pruned? Yes, possible… PZ seems to be addressing that.

HQ is investigating these segments to see why they are not being pruned, but it may be working as designed.

Sent using Tapatalk for Android 4.4.2

That’s great to hear, thank you. I say we hold off on making changes here until their work is complete. Once we hear back I’m all for upgrading them to MH so as not to deviate from our standards (as phantomsoul said) and because there should not be any effect on the locals (as I understand qwalatee & pz). Not for nothing, this was an interesting case study.

Was has analyzed this route and told us that this is working as designed, based on specific a proprietary algorithm that happens to be effecting this particular interchange. It is not guaranteed to continue to work or even be able to be replicated elsewhere. The specific details of why this happened were technical and obviously not shared.

Therefore it should not be used as an example. To ensure it continues to work it is recommended to be upgraded to MH for proper continuity.

Sent using Tapatalk for Android 4.4.2

Wow, did we just set a record for the quickest response time?!

While understandably not entirely complete, the reasoning is satisfactory to me and the segments have been upgraded to MH.

Based on what we saw here, I would conclude that we continue to follow our guidelines for continuity even in scenarios where routing appears to be working correctly.