Author Topic: Routes concurrent with themselves  (Read 887 times)

0 Members and 1 Guest are viewing this topic.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1973
  • Last Login:Today at 01:52:20 am
Routes concurrent with themselves
« on: November 25, 2018, 02:57:10 am »
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?
« Last Edit: November 27, 2018, 02:58:54 pm by yakra »

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1973
  • Last Login:Today at 01:52:20 am
Re: Routes concurrent with themselves
« Reply #1 on: November 27, 2018, 02:27:40 pm »
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.
« Last Edit: November 27, 2018, 03:09:15 pm by yakra »

Offline the_spui_ninja

  • TM Collaborator
  • Sr. Member
  • *****
  • Posts: 295
  • Last Login:June 12, 2019, 12:38:03 am
  • THE Western SD Highway Nut
Re: Routes concurrent with themselves
« Reply #2 on: December 02, 2018, 05:04:36 pm »
As I said in the Utah thread, I'm all for this.
An adventure is only an inconvenience rightly considered. An inconvenience is only an adventure wrongly considered. - G.K. Chesterton

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1446
  • Last Login:Yesterday at 10:55:54 pm
Re: Routes concurrent with themselves
« Reply #3 on: December 02, 2018, 05:28:20 pm »
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.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1973
  • Last Login:Today at 01:52:20 am
Re: Routes concurrent with themselves
« Reply #4 on: December 03, 2018, 12:44:47 am »
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.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1556
  • Gender: Male
  • Last Login:Yesterday at 12:49:19 pm
Re: Routes concurrent with themselves
« Reply #5 on: December 03, 2018, 04:09:58 am »
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)

Offline neroute2

  • Full Member
  • ***
  • Posts: 110
  • Last Login:Yesterday at 10:29:16 pm
Re: Routes concurrent with themselves
« Reply #6 on: December 03, 2018, 07:05:52 am »
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.

Offline michih

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1556
  • Gender: Male
  • Last Login:Yesterday at 12:49:19 pm
Re: Routes concurrent with themselves
« Reply #7 on: December 03, 2018, 04:02:34 pm »

Offline Duke87

  • TM Collaborator
  • Full Member
  • *****
  • Posts: 232
  • Last Login:Yesterday at 12:51:20 am
Re: Routes concurrent with themselves
« Reply #8 on: December 03, 2018, 07:10:04 pm »
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.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1973
  • Last Login:Today at 01:52:20 am
Re: Routes concurrent with themselves
« Reply #9 on: December 03, 2018, 11:46:09 pm »
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:
Quote
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.

Offline neroute2

  • Full Member
  • ***
  • Posts: 110
  • Last Login:Yesterday at 10:29:16 pm
Re: Routes concurrent with themselves
« Reply #10 on: December 04, 2018, 07:10:50 am »
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.

Offline si404

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 909
  • Last Login:Yesterday at 06:11:18 pm
Re: Routes concurrent with themselves
« Reply #11 on: December 04, 2018, 12:28:37 pm »
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.

Offline neroute2

  • Full Member
  • ***
  • Posts: 110
  • Last Login:Yesterday at 10:29:16 pm
Re: Routes concurrent with themselves
« Reply #12 on: December 04, 2018, 01:50:16 pm »
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.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 1973
  • Last Login:Today at 01:52:20 am
Re: Routes concurrent with themselves
« Reply #13 on: December 04, 2018, 05:46:21 pm »
If I were mapping this for TM, I would leave off the backtrack segment, because the opposing right turn can still be made.

Offline neroute2

  • Full Member
  • ***
  • Posts: 110
  • Last Login:Yesterday at 10:29:16 pm
Re: Routes concurrent with themselves
« Reply #14 on: December 05, 2018, 07:03:03 am »
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.