PA: US 19 Truck (Pittsburgh)

[Jim]

OK, why this route is plotted like this:

http://tm.teresco.org/hb/index.php?r=pa.us019trkpit

If that little leg needs to be part of this route, I think it needs a separate wpt file.  As it stands, you get credit for the little leg if you  pass it by on the way.  And it triggers an error in some code I'm writing that I just spent hours tracking down...  Turns out my code was making what I thought was a reasonable assumption that situations like this aren't allowed.

[rickmastfan67]

Because the route loops around on itself?  It's been this way since the beginning.

This picture shows what happens:
https://en.wikipedia.org/wiki/U.S._Route_19_Truck_(Pittsburgh)#/media/File:U.S._Route_19_Truck_concurrency_map.svg

It's one of the rare places where both directions of a route share the same carriageway.

Anyway you look at it, if you attempt to eliminate that 'backtrack', you're loosing a decent amount of mileage.

[si404]

It's literally impossible to turn directly at the northern junction with US19/I-376, so you have travel to the next junction and do a u-turn on the u-turn ramp there to follow the route. It's even signed. If you 'pass it by on the way' you deserve the credit as you genuinely have clinched part of the mainline.

Truck North 19 signed on the ramp at the northern junction that turns onto South US19.

[Jim]

Wow, thanks.  Of the 373,952 highway segments in our data, this is the only one that caused the particular problem.  I wonder where else in the system there are assumptions that this can't be.  I will find a workaround for my current problem that arises from this, but I know I never considered this, for example, when computing mileage for concurrencies and crediting users for them.  I'll see if I can figure it out, but what would be the correct, expected behavior?  Suppose someone drives I-376 from 67 to 69C.  They should get credit for US19TrkPit, but should they get double credit, since they've traveled it "both ways"?

[michih]

I wonder where else in the system there are assumptions that this can't be.

A little bit different but waypoint 109 and 113 are the same because you can exit A485 northwards: http://tm.teresco.org/hb/index.php?r=deu.b049.

[Jim]

FYI, here's how an I-376 traveler gets credit:

http://tm.teresco.org/user/?u=i376

[mapmikey]

Wow, thanks.  Of the 373,952 highway segments in our data, this is the only one that caused the particular problem.  I wonder where else in the system there are assumptions that this can't be.  I will find a workaround for my current problem that arises from this, but I know I never considered this, for example, when computing mileage for concurrencies and crediting users for them.  I'll see if I can figure it out, but what would be the correct, expected behavior?  Suppose someone drives I-376 from 67 to 69C.  They should get credit for US19TrkPit, but should they get double credit, since they've traveled it "both ways"?

Could this be solved by taking the I-376(69B)_S and moving it northwest to the nearby partial interchange with US 19?  Then 19Trk would get the mileage right for the loop portion and the I-376 concurrency would only come up once?

[Jim]

I'd rather not adjust the highway data, which I believe is plotted in a reasonable way.  I might need to make changes in some of the concurrency detection code and web front end.

[yakra]

This case is not handled deterministically by concurrency detection:

I noticed that concurrencies.log isn't always the same number of lines between successive runs of siteupdate.py. Which struck me as odd, as the same number of concurrencies should always be detected, in whatever order they're detected in, and travelers should be augmented for the same concurrencies, in whatever order, on whatever basis.

Using...
HighwayData: fa43011
DataProcessing: 8d1c457
UserData: 9ab420d
http://yakra.teresco.org/tests/concurrencies/y20181119/m/concurrencies-3.log multi-threaded, attempt #3 (717659 lines)
http://yakra.teresco.org/tests/concurrencies/y20181119/m/concurrencies-4.log multi-threaded, attempt #4 (717658 lines)
http://yakra.teresco.org/tests/concurrencies/y20181119/s/concurrencies-9.log single-threaded, attempt #9 (717640 lines)
Multi-threaded logs were always 717658 or 717659 lines; single-threaded logs were always 717640 lines.

The problem with trying to find one extra line out of 717659 is that the concurrencies & segments therein aren't found & listed in a deterministic order. A regular DIFF between files will be useless. A real needle in a haystack.
To help with this, I wrote a (painfully slow) program to massage the log files, listing only full concurrencies, sorted, with their segments sorted.
http://yakra.teresco.org/tests/concurrencies/y20181119/m/concurrencies-3_frobbed.log
http://yakra.teresco.org/tests/concurrencies/y20181119/m/concurrencies-4_frobbed.log
http://yakra.teresco.org/tests/concurrencies/y20181119/s/concurrencies-9_frobbed.log

Comparing the two multi-threaded logs:

Code: [Select]

1c1
< Log file created at: 2018-11-20 00:40:05.101466
---
> Log file created at: 2018-11-20 00:47:04.461352
73299a73300
> Full concurrency [69A to 69B via pa.i376][I-376(69A) to I-376(69B) via pa.us019][I-376(69B)_S to I-376(69A) via pa.us019trkpit][I-376(69A) to I-376(69B) via pa.us022][I-376(69A) to I-376(69B) via pa.us030] (5)Even with my limited understanding of the concurrency detection routine, it makes sense that this is sometimes detected and sometimes not.
We can get into more detail on this later on.

Here's where things really start to get strange:
The number of detected concurrencies is always the same (give or take one pa.us019trkpit entry).
The 18-line difference between single & multi-threaded runs of siteupdate occurs in the augments for travelers.
http://yakra.teresco.org/tests/concurrencies/y20181119/m4-s9.diff
...And it's always the same 18 travelers.
What do these 18 all have in common? These travelers, and no others, all have PA I-376, and only PA I-376, listed along this segment.

I'll have to do some more digging to find out why this is behaving this way.

[yakra]

https://github.com/TravelMapping/DataProcessing/issues/135 because GitHub Flavored Markdown.

[yakra]

Wow, thanks.  Of the 373,952 highway segments in our data, this is the only one that caused the particular problem.  I wonder where else in the system there are assumptions that this can't be.  I will find a workaround for my current problem that arises from this, but I know I never considered this, for example, when computing mileage for concurrencies and crediting users for them.  I'll see if I can figure it out, but what would be the correct, expected behavior?  Suppose someone drives I-376 from 67 to 69C.  They should get credit for US19TrkPit, but should they get double credit, since they've traveled it "both ways"?

IMO yes, they should get double credit as long as the segments are concurrent.
• Driving EB, PA I-376 69A 69B, I'm driving the 2nd half of the loop, PA US19TrkPit I-376(69A) I-376(69B)_N. And doing the 1st half "backwards".
• Driving WB, PA I-376 69B 69A, I'm driving the 1st half of the loop, PA US19TrkPit I-376(69B)_S I-376(69A). And doing the 2nd half "backwards".

With most concurrencies, I'm given credit for the overlapping route regardless of direction traveled. If I clinch ME15, I'm credited for a bit of I-95. Just plain I-95, regardless of which way I traveled it.
I see no reason this special case should be any different.

(If we do decide to separate out this self-concurrency, and separate out I-376 (and/or US19), we may be better off doing this in the highway data, with some minimum offset shaping points.)

I'd rather not adjust the highway data, which I believe is plotted in a reasonable way.

That said though, I pretty much agree with this.

I might need to make changes in some of the concurrency detection code and web front end.

No changes to web front end needed. Currently testing out a change to the concurrency detection code that will consistently double-count this segment & augment travelers accordingly.

[Wadsteckel]

IMHO, since I-376/Truck US19 North goes through the Fort Pitt Tunnel, if I was PennDOT I would re-route Truck 19 over the West End Bridge to PA 65 and over to I-279.  The West End Bridge is kind of narrow, but flammables (gas/fuel hauling trucks) would technically be allowed to stay on Truck US19 instead of diverting off of it.

Of course, PennDOT has also demoted US19 on a couple signs in the area between the Liberty Tunnels and Fort Pitt Tunnels, so there's that, too (signs show PA19 instead of US19).

-Ed S

[yakra]

To try to better articulate why I believe travelers should be double-credited:

Going EB on I-376, you're traveling:
• The more northerly segment of NB US19Trk's "backtrack", IE, the one farther from the south end of the route.
• The more southerly segment of SB US19Trk's "backtrack", IE, the one closer to the south end of the route.
Both segments are being traveled. At once.

[Wadsteckel]

IMHO, since I-376/Truck US19 North goes through the Fort Pitt Tunnel, if I was PennDOT I would re-route Truck 19 over the West End Bridge to PA 65 and over to I-279.

I remembered this morning that US19 crosses the West End Bridge.  So, the re-routing would only extend from the north end of the bridge over to I-279 where it currently resides.  😕

-Ed S