Travel Mapping

User Discussions => Other Discussion => Topic started by: yakra on November 25, 2018, 02:57:10 am

Title: Routes concurrent with themselves
Post by: yakra on November 25, 2018, 02:57:10 am
Split from PA: US 19 Truck (Pittsburgh) (http://forum.travelmapping.net/index.php?topic=316)


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?
Title: Re: Routes concurrent with themselves
Post by: yakra on November 27, 2018, 02:27:40 pm
Some changes I'm proposing to the concurrency detection code (https://github.com/TravelMapping/DataProcessing/issues/137) 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:

ut.ut190:
Title: Re: Routes concurrent with themselves
Post by: the_spui_ninja on December 02, 2018, 05:04:36 pm
As I said in the Utah thread, I'm all for this.
Title: Re: Routes concurrent with themselves
Post by: 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..

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.
Title: Re: Routes concurrent with themselves
Post by: yakra 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.
Title: Re: Routes concurrent with themselves
Post by: michih on December 03, 2018, 04:09:58 am
Some changes I'm proposing to the concurrency detection code (https://github.com/TravelMapping/DataProcessing/issues/137) 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)
Title: Re: Routes concurrent with themselves
Post by: neroute2 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. (https://www.google.com/maps/@40.6090018,-111.5803267,3a,15y,237.23h,83.42t/data=!3m6!1e1!3m4!1sShr9VoqnqYus2RkDz0-1fQ!2e0!7i13312!8i6656)
Title: Re: Routes concurrent with themselves
Post by: michih on December 03, 2018, 04:02:34 pm
I see a gate on it. (https://www.google.com/maps/@40.6090018,-111.5803267,3a,15y,237.23h,83.42t/data=!3m6!1e1!3m4!1sShr9VoqnqYus2RkDz0-1fQ!2e0!7i13312!8i6656)

You can walk or take a bike.
Title: Re: Routes concurrent with themselves
Post by: Duke87 on December 03, 2018, 07:10:04 pm
I see a gate on it. (https://www.google.com/maps/@40.6090018,-111.5803267,3a,15y,237.23h,83.42t/data=!3m6!1e1!3m4!1sShr9VoqnqYus2RkDz0-1fQ!2e0!7i13312!8i6656)

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.
Title: Re: Routes concurrent with themselves
Post by: yakra 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) (http://forum.travelmapping.net/index.php?topic=316) 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 (https://github.com/TravelMapping/DataProcessing/issues/135) fix.
Concurrency detection was implemented back before (https://github.com/TravelMapping/DataProcessing/commit/9b1c6333a3497bfe948725d963dfb4eec312c741) PA US19TrkPit seems to have hit Jim's radar (http://forum.travelmapping.net/index.php?topic=316.msg1572#msg1572)... Maybe he had self-concurrent routes in mind when adding this line (https://github.com/TravelMapping/DataProcessing/blob/master/siteupdate/python-teresco/siteupdate.py#L2367) 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 (https://github.com/TravelMapping/DataProcessing/issues/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 (http://forum.travelmapping.net/index.php?topic=196.msg12335#msg12335) at MelPl or RodDr, we might need to have [MS TourRd UniAve_S ConAve_S] do the same.
Title: Re: Routes concurrent with themselves
Post by: neroute2 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.
Title: Re: Routes concurrent with themselves
Post by: si404 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.
Title: Re: Routes concurrent with themselves
Post by: neroute2 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.
Title: Re: Routes concurrent with themselves
Post by: yakra 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.
Title: Re: Routes concurrent with themselves
Post by: neroute2 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.
Title: Re: Routes concurrent with themselves
Post by: yakra on December 05, 2018, 04:04:24 pm
Quote
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.
Title: Re: Routes concurrent with themselves
Post by: michih on December 06, 2018, 03:10:58 pm
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 (http://travelmapping.net/hb/index.php?u=michih&r=mkd.a001) (exit 14-17) could once (as-is) or twice?
Title: Re: Routes concurrent with themselves
Post by: neroute2 on December 07, 2018, 06:27:14 am
A one-way route is a route that only exists in one direction. If you backtrack from end to start there are no signs.
Title: Re: Routes concurrent with themselves
Post by: yakra on December 07, 2018, 02:31:16 pm
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.

Quote
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 (http://forum.travelmapping.net/index.php?topic=196.90)).
UT190 is a bit murkier though IMO...
Title: Re: Routes concurrent with themselves
Post by: michih on December 07, 2018, 03:25:10 pm
Quote
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 (http://forum.travelmapping.net/index.php?topic=196.90)).
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.
Title: Re: Routes concurrent with themselves
Post by: the_spui_ninja on December 07, 2018, 09:50:16 pm
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.
Title: Re: Routes concurrent with themselves
Post by: US 89 on December 18, 2018, 07:18:26 pm
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.
Title: Re: Routes concurrent with themselves
Post by: yakra on July 15, 2021, 04:34:39 pm
Apologies in advance for dusting off this old topic.
A memory leak (https://github.com/TravelMapping/DataProcessing/issues/449) in the C++ siteupdate program (which I hope to eventually bring to production (https://github.com/TravelMapping/DataProcessing/issues/375)) 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 (https://github.com/TravelMapping/DataProcessing/issues/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.
Title: Re: Routes concurrent with themselves
Post by: michih on July 16, 2021, 01:39:39 pm
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  ;D

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 :D