Routes concurrent with themselves

[yakra]

Split from PA: US 19 Truck (Pittsburgh)

While testing some changes to the concurrency detection code, I came across:
http://travelmapping.net/hb/index.php?r=ut.ut190
http://travelmapping.net/hb/index.php?r=ms.tourrd
Like PA US19TrkPit, these routes are concurrent with themselves.
Unlike PA US19TrkPit, these routes are not concurrent with any other routes.

I have no big objections to the way these are plotted, but...
Comments? Thoughts?

[yakra]

Some changes I'm proposing to the concurrency detection code would change how these routes' self-concurrent segments are counted toward user stats.
Right now, a traveler must manually .list both segments to get credit for both.
Under my proposal, if a traveler claims only one, they'll receive credit for the other.

FWIW:

ms.tourrd:

• Of 7 travelers on MS TourRd, 6 have travelled the self-concurrent bit. All 6 .list files have a line that explicitly contains both concurrent segments.

ut.ut190:

• 4 travelers have UT UT190 I-215 BriRes in their .lists, BriRes being the old label for UT190_C:
      bobcobb, crosboro7, osu97gp, the_spui_ninja
      As things are now, these four travelers have the concurrent segment counted toward their mileage only once.
• 2 travelers have clinched UT UT190: Based8 & roadguy2.
• norheim hasn't travelled the extension to Guardsman Pass, but has UT UT190 I-215 UT190_D .listed, and thus has the concurrent segment counted twice for mileage.

[the_spui_ninja]

As I said in the Utah thread, I'm all for this.

[Jim]

Looking a bit at the UT 190 situation, I don't see how it makes sense to credit people twice for taking the same road both directions here.  But maybe I'm not understanding something, not having looked into it nearly as closely as those who have been discussing this.  Here are my thoughts, apologies if I missed something in this or another thread..

1) Is it possible to travel up to Guardsman Pass without dipping down to Brighton and taking that loop?
2) If any traveler gets to UT190_B and continues on at all, they have no choice but to continue all the way around the loop, and unless they are staying at Brighton permanently, eventually will get back out to UT190_D.  Doesn't this make NorTraLn pointless?'

I feel like it makes the most sense to have the main line dip down to Brighton ending at UT190_C.  Then a separate file for the part that continues up into the pass.

[yakra]

1) Is it possible to travel up to Guardsman Pass without dipping down to Brighton and taking that loop?

Yes.

2) If any traveler gets to UT190_B and continues on at all, they have no choice but to continue all the way around the loop, and unless they are staying at Brighton permanently, eventually will get back out to UT190_D.  Doesn't this make NorTraLn pointless?'

Looks like there's a connection via Nordic Trail Lane, Brighton Lake Lane, and Silver Aspen Lane back to north to UT190 north of the loop (however "Hi-Standard" or "Top Ho and Spiffing" this connection may or may not be). ESRI WorldImagery looks newer than MapBox, and agrees with Google and Bing. It looks possible to clinch UT UT190 UT190_B NorTraLn and not UT UT190 NorTraLn UT190_C, or vice versa.

[michih]

Some changes I'm proposing to the concurrency detection code would change how these routes' self-concurrent segments are counted toward user stats.
Right now, a traveler must manually .list both segments to get credit for both.
Under my proposal, if a traveler claims only one, they'll receive credit for the other.

I think if one has just one list file entry and the route contains a segment which is concurrent to - let's say - 5 different routes, all routes should be marked traveled (I think it's the actual situation). If the route is concurrent with itself, the segment should only count ONCE!

I'm not sure how concurrent routes are really handled today. My thoughts:

Let's assume that the 6 routes are in 3 systems. Route A1, A2, B1, B2, C1 and C2.
In user system stats, the segment should be count once for system A, once for system B and once for system C.
In user region stats, the segment should be count once. Total mileage is (or should be) the sum of all regions, not systems.

Let's say, the segment is 2mi, it would be as follows:
A1: 2mi traveled (plus the rest which is indicated in the list file entry)
A2: 2mi traveled
B1: 2mi traveled
B2: 2mi traveled
C1: 2mi traveled
C2: 2mi traveled

System A: 2mi traveled (plus the rest which is indicated in the list file entry)
System B: 2mi traveled
System C: 2mi traveled

Region: 2mi traveled (plus the rest which is indicated in the list file entry)

[neroute2]

Looks like there's a connection via Nordic Trail Lane, Brighton Lake Lane, and Silver Aspen Lane back to north to UT190 north of the loop (however "Hi-Standard" or "Top Ho and Spiffing" this connection may or may not be).

I see a gate on it.

[michih]

I see a gate on it.

You can walk or take a bike.

[Duke87]

I see a gate on it.

You can walk or take a bike.

Or pull out of NorTraLn into the parking lot across the street, go through it to the far end, and then make a not legal but not insanely stupid maneuver going straight back out rather than around the loop.

Regardless, it didn't seem right for UT190_B and UT190_C to be consecutive visible points.

[yakra]

As I said in the Utah thread, I'm all for this.

We have one Aye...

I think if one has just one list file entry and the route contains a segment which is concurrent to - let's say - 5 different routes, all routes should be marked traveled (I think it's the actual situation).

If I understand your post correctly, this is the current actual situation, yes.

If the route is concurrent with itself, the segment should only count ONCE!

I'll take that as a Nay, though I'm not sure I fully understand your post. More below...
Which is not a problem. I can just not implement the changes, and users can have the option of whether to manually specify the segment in their .lists.
(It's not like concurrency detection takes a huge amount of time either.)

I'm not sure how concurrent routes are really handled today. My thoughts:

Let's assume that the 6 routes are in 3 systems. Route A1, A2, B1, B2, C1 and C2.
In user system stats, the segment should be count once for system A, once for system B and once for system C.
In user region stats, the segment should be count once. Total mileage is (or should be) the sum of all regions, not systems.

Let's say, the segment is 2mi, it would be as follows:
A1: 2mi traveled (plus the rest which is indicated in the list file entry)
A2: 2mi traveled
B1: 2mi traveled
B2: 2mi traveled
C1: 2mi traveled
C2: 2mi traveled

System A: 2mi traveled (plus the rest which is indicated in the list file entry)
System B: 2mi traveled
System C: 2mi traveled

Region: 2mi traveled (plus the rest which is indicated in the list file entry)

This is how things are handled now, if we ignore for a moment the possibility of a self-concurrent route.
(How a self-concurrent route is handled for stats overall or in a region, I'm unsure of. Haven't gotten that deep into the code yet.)
Whether a self-concurrent segment could/should/would count for 2 miles or 4 miles, I guess I can leave that aside for now, assuming a traveler has the option of .listing 1 or both...

The trouble with this scenario is that there are multiple routes concurrent on a given segment. This is a bit different from the MS TourRd and UT UT190 examples above, where those routes are concurrent with themselves only.
Going back to the PA: US 19 Truck (Pittsburgh) example...
Here we have 5 routes, containing 6 segments, in 3 systems:

PA I-376 69A 69B
PA US19 I-376(69A) I-376(69B)
PA US22 I-376(69A) I-376(69B)
PA US30 I-376(69A) I-376(69B)
PA US19TrkPit I-376(69B)_S I-376(69A)
PA US19TrkPit I-376(69A) I-376(69B)_N

[PA US19TrkPit I-376(69B)_S I-376(69A)] is concurrent with [PA US19 I-376(69A) I-376(69B)], which is concurrent with [PA US19TrkPit I-376(69A) I-376(69B)_N], so therefore [PA US19TrkPit I-376(69B)_S I-376(69A)] is concurrent with [PA US19TrkPit I-376(69A) I-376(69B)_N].
Again, this is how things are implemented now, and were imperfectly/inconsistently implemented before the Insidious Bug fix.
Concurrency detection was implemented back before PA US19TrkPit seems to have hit Jim's radar... Maybe he had self-concurrent routes in mind when adding this line of code, or OTOH, maybe not -- that could have just been put in to avoid wasting CPU time searching for HighwaySegment s when s is already known...

Doing things another way could get pretty complicated pretty fast, and I'm not sure if it's the Right Thing...

This case, I think is appropriate due to the unique layout of the route...

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.

Thankfully, this is, and probably will remain, the only such unique case in the project.

I guess my thinking is, if a 2mi segment is contained twice in a route, and it must be traveled twice to clinch the route, then it should count for 4mi toward the route's overall mileage. And thus, 4mi toward mileage in that region & system.

So, that's my opinion on overall mileage of a route...
To augment or not to augment, then...

On PA U19TrkPit, one must drive south from 69B to 69A and then back north again, due to interchange layout, missing ramps at the I-376/PA51 interchange.
On UT190 and TourRd, one must backtrack in order to continue on and finish clinching the route. Just kinda a consequence of geometry.
In the former case, even to not clinch the route, but just return back to UT210, I-215, etc.

Looking a bit at the UT 190 situation, I don't see how it makes sense to credit people twice for taking the same road both directions here.  But maybe I'm not understanding something, not having looked into it nearly as closely as those who have been discussing this.  Here are my thoughts, apologies if I missed something in this or another thread..

Guess I should ask for clarification here too. Jim, I interpreted your post as just questioning the way UT190 is entered in the HB. Leaving aside the question of whether or not to split UT190 into two routes, what are your thoughts on #137?

Regardless, it didn't seem right for UT190_B and UT190_C to be consecutive visible points.

I hear ya there. It has been done though; see [MS TourRd CaiMus_A CaiMus_B]. With no actual access at MelPl or RodDr, we might need to have [MS TourRd UniAve_S ConAve_S] do the same.

[neroute2]

For TM purposes, would something like http://maps.google.com/maps?saddr=2507%20Palmer%20Ave&daddr=100%20Commerce%20Cir&geocode=FYHXYwId0W2J-w%3D%3D%3BFYvfYwIdyoKJ-w%3D%3D&dirflg=d be a self overlap? This is how one of the BicyclePA routes goes and it's plausible some car routes do something equivalent.

[si404]

For TM purposes, would something like http://maps.google.com/maps?saddr=2507%20Palmer%20Ave&daddr=100%20Commerce%20Cir&geocode=FYHXYwId0W2J-w%3D%3D%3BFYvfYwIdyoKJ-w%3D%3D&dirflg=d be a self overlap? This is how one of the BicyclePA routes goes and it's plausible some car routes do something equivalent.

that's what US19 Truck in Pittsburgh, that started this thread, does.

[neroute2]

For TM purposes, would something like http://maps.google.com/maps?saddr=2507%20Palmer%20Ave&daddr=100%20Commerce%20Cir&geocode=FYHXYwId0W2J-w%3D%3D%3BFYvfYwIdyoKJ-w%3D%3D&dirflg=d be a self overlap? This is how one of the BicyclePA routes goes and it's plausible some car routes do something equivalent.

that's what US19 Truck in Pittsburgh, that started this thread, does.

No...US 19 Truck does it in both directions. The opposing right turn in my example is simple.

[yakra]

If I were mapping this for TM, I would leave off the backtrack segment, because the opposing right turn can still be made.

[neroute2]

As would I. Final question: what if it's a one-way route, like the battlefield tour route? In non-TM parlance this isn't a self-overlap; both directions do not use the same side of the road (since there is only one direction). But I guess in TM there's no distinction between one- and two-way routes, so this would be a self-overlap.