Routes concurrent with themselves

[yakra]

both directions do not use the same side of the road

I've thought about that as well. It'd be possible to pull the coordinates of the points at each the south end of the overlap apart slightly, indicating a different highway segment for each direction of travel, and thus eliminating the self-overlap.

My current thinking:
I tried to think of cases where a user's traveled only one direction, and not the other, and would thus have reason to just want to claim one "direction".
They'd have to leave the "loop" of these routes, and return to the outside world.
UT190: not too easy.
On TourRd, I first saw MelPl and RodDr and thought this was possible.
OTOH, Checking aerial imagery and GMSV, there are actually no connections.
OT3H, sometimes it's wise to anticipate the unanticipated. New roads could be built here, connecting to the outside world. Or a new route could be added to the database in the future, with such a setup.

It may be best to skip my proposed changes to the code (even if it seems better from a programming standpoint), leaving travelers the option of .listing one or both segments.

[michih]

This is how things are handled now, if we ignore for a moment the possibility of a self-concurrent route.

If so, everything's fine to me

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.

Sure. For that reason, we have the possiblity to break the concurrency by moving one point 0.000001mi off. I think this should be done here too!

OTOH, I wrote in the past that I'd like to have a better way anywhere done the road so that the "Intersecting/Concurrent Routes" links in the HB still work. But this might also be done in the HB or anywhere else.

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.

What's the exact definition of a one-way route? Is even a dual-carriageway a one-way route? I there any minimum "median" width? Should mkd.a001 (exit 14-17) could once (as-is) or twice?

[neroute2]

A one-way route is a route that only exists in one direction. If you backtrack from end to start there are no signs.

[yakra]

Or a route (completely or partially) on one-way roads, allowing travel in only one direction, with no complementary alignment in the other direction.
tm.teresco.org/hb/index.php?r=me.me011bmil
I'd still count mkd.a001 as a two-way route.

Sure. For that reason, we have the possiblity to break the concurrency by moving one point 0.000001mi off. I think this should be done here too!

I think this is an appropriate solution for MS TourRd (Which may be a moot point soon, as there's been talk of scrapping that route).
UT190 is a bit murkier though IMO...

[michih]

Sure. For that reason, we have the possiblity to break the concurrency by moving one point 0.000001mi off. I think this should be done here too!

I think this is an appropriate solution for MS TourRd (Which may be a moot point soon, as there's been talk of scrapping that route).
UT190 is a bit murkier though IMO...

I think UT190 is similar. UT190_C should just be moved off by 0.000001mi from UT190_B.

[the_spui_ninja]

They'd have to leave the "loop" of these routes, and return to the outside world.
UT190: not too easy.

As of right now, the only way to leave the UT 190 loop is what appears to be a narrow private drive that has street signs using Comic Sans. The odds that people would use that to leave Brighton are very slim.

[US 89]

For what it’s worth, it is possible to hike outside the UT 190 loop and not return to Brighton. To give one example: there’s a fairly well used trail that leaves from the loop, passes a few mountain lakes, crosses Catherine Pass and winds up at Alta.

What that means is that there’s a real way to stop partway down the loop and never leave. While that probably is irrelevant for most TM mappers here, it is possible.

[yakra]

Apologies in advance for dusting off this old topic.
A memory leak in the C++ siteupdate program (which I hope to eventually bring to production) begs for changes to the concurrency detection routine. As a consequence, a self-concurrent route will always be counted as concurrent, whether or not another route is in the mix. As it should be, IMO.

Right now:
[UT UT190 UT190_A UT190_B] is not marked as concurent with [UT UT190 UT190_C UT190_D]. I'm coming to regard this as more of a bug than a feature.
OTOH, [PA I-376 68A 69B] (and US19/22/30) is concurrent with both [PA US19TrkPit I-376(69B)_S I-376(69A)] and [PA US19TrkPit I-376(69A) I-376(69B)_N].
Therefore, [PA US19TrkPit I-376(69B)_S I-376(69A)] and [PA US19TrkPit I-376(69A) I-376(69B)_N] must necessarily be concurrent with one another.

The fact that whether a self-concurrency is flagged depends on whether another route is also concurrent is an inconsistency that makes no sense. Arbitrary. Counterintuitive.

To revisit the topic of how a self-concurrency affects overall stats & user stats...

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...

I've since gotten that deep into the code. Here's how a self-concurrent route works out. (For simplicity, defining a self-concurrent route here as a case where the self-concurrency actually gets flagged. Ignoring UT190 for the time being.)
• Route: 4 miles counted toward the self-concurrent route(s) itself/themselves, 2 miles for the others.
• System: All systems get 2 miles.
• Region: Gets 2 miles.

This is how things are handled now, if we ignore for a moment the possibility of a self-concurrent route.

If so, everything's fine to me

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.

Sure. For that reason, we have the possiblity to break the concurrency by moving one point 0.000001mi off. I think this should be done here too!

UT190_C should just be moved off by 0.000001mi from UT190_B.

Yes, that could be done, to allow travelers to independently claim one or both segments as they wish.
(I'd also favor giving the unsigned segment to Guardsman Pass the axe, but that's another discussion...)

To clarify, I do not think this should be done for PA US19TrkPit though...
• It would break not only the concurrency with itself, but also the concurrency between one of its segments & all the other concurrent routes. Undesirable.
• We truly do have a self-concurrency here:
  Driving the south half of the NB loop (the 1st segment) is the same as driving the south half of the SB loop (the 2nd segment).
  Driving the north half of the NB loop (the 2nd segment) is the same as driving the north half of the SB loop (the 1st segment).
  Same side of the road & everything.

Back to this bit...

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.

Sure.

I'm uncertain whether "Sure" means michih agrees with all the quoted text including the non-bold bits, or is just accepting my premise for the sake of argument & moving on.

Whether or not UT190 has a point moved & its concurrency intentionally broken, it should be pretty easy to count the full "4" miles for cases like US19TrkPit where the routes must be flagged as concurrent, if that's what there's consensus to do.
This would be independent of the fix I have in mind for DataProcessing#449 (which would be "no-build" WRT stats other than counting UT190 specifically as concurrent, and thus reducing mileage on that route/system/region by 0.33 mi), handled separately from concurrency detection, in the "computing stats" part of siteupdate. I can leave that idea out for now & allow time for discussion.

[michih]

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.

Sure.

I'm uncertain whether "Sure" means michih agrees with all the quoted text including the non-bold bits, or is just accepting my premise for the sake of argument & moving on.

I wrote that almost three years ago... I returned from Southern France a day before I wrote it. That means, I drunk a lot of red wine the days before but I was not drunk when I wrote it 

I think* that I agreed (and still agree) with everything I've quoted

*Need to double-check tomorrow because I recently had a glass of red wine