User Discussions > Other Discussion
Routes concurrent with themselves
michih:
--- Quote from: yakra 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.
--- End quote ---
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:
--- Quote from: yakra on December 03, 2018, 12:44:47 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).
--- End quote ---
I see a gate on it.
michih:
--- Quote from: neroute2 on December 03, 2018, 07:05:52 am ---I see a gate on it.
--- End quote ---
You can walk or take a bike.
Duke87:
--- Quote from: michih on December 03, 2018, 04:02:34 pm ---
--- Quote from: neroute2 on December 03, 2018, 07:05:52 am ---I see a gate on it.
--- End quote ---
You can walk or take a bike.
--- End quote ---
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:
--- Quote from: the_spui_ninja on December 02, 2018, 05:04:36 pm ---As I said in the Utah thread, I'm all for this.
--- End quote ---
We have one Aye...
--- Quote from: michih on December 03, 2018, 04:09:58 am ---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).
--- End quote ---
If I understand your post correctly, this is the current actual situation, yes.
--- Quote from: michih on December 03, 2018, 04:09:58 am ---If the route is concurrent with itself, the segment should only count ONCE!
--- End quote ---
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.)
--- Quote from: michih on December 03, 2018, 04:09:58 am ---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)
--- End quote ---
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
--- End quote ---
[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...
--- Quote from: yakra on November 24, 2018, 01:29:00 pm ---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.
--- End quote ---
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.
--- Quote from: Jim 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..
--- End quote ---
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?
--- Quote from: Duke87 on December 03, 2018, 07:10:04 pm ---Regardless, it didn't seem right for UT190_B and UT190_C to be consecutive visible points.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version