mapview: rail & self-concurrencies

[yakra]

I've only started paying attention to rail, and admittedly have plenty of catching up to do.
If there are any links relevant to this, sock it to me!

https://tmrail.teresco.org/user/mapview.php?u=M3200&rg=SCT

Zoom in on the very top of the Scottish rail network.
Here, the Far North Line is concurrent with itself after making the Thurso stop and backtracking along the same rail line back to Georgemas junction.

Now switch to "Color by Concurrencies".
This portion is all blue. As in, "one segment here". --Or do I mean, "one route here?"

Was this intentional? By design, does a route concurrent with itself not count toward the total concurrency count in mapview?
If so, no problem, fine by me. I see the logic in it; it's just one route after all.
I just want to make sure what I'm looking at is mapview operating as intended, not  bug.

[mapcat]

Sounds like this is the same thing that happens with UT 190: https://travelmapping.net/user/mapview.php?units=miles&u=roadguy2&rg=ut (west of Park City). Same behavior with the self-concurrent segment north of the loop in Brighton.

[si404]

Looking at the user's travels on the route, they aren't given the bit from Thurso and Georgemas Junction towards Wick, despite having travelled that same track towards Inverness.

Is that a bug? I don't believe it would affect mileage (because the same granting of that mileage by concurrency would also take it away from totals). The numbers make no sense though - I'm getting a missing 3 miles taking the length of Georgemas Junction-Wick from the total length and looking at the travels, but Georgemas Junction to Thurso is over 6 miles.

I wouldn't see the mapview thing it as a bug, especially when concurrencies are high (which doesn't work well), eg into a busy terminus station where many services reverse in along their route (eg Zurich Bahnhof, though those services are not currently mapped, though the S-Bahn is more than enough concurrencies to be getting on with there!) and so reducing the number counted is a good thing.

And yes, this applies to every route concurrent with itself across modes. I noticed this behaviour on mapview (the travelers stats on the route page are new to me).

[yakra]

Looking at the user's travels on the route, they aren't given the bit from Thurso and Georgemas Junction towards Wick, despite having travelled that same track towards Inverness.

Is that a bug?

It's two bugs.

Bug #1, DataProcessing:
[SCT FarNorLn Thu +X841815_B] isn't flagged as concurrent with [SCT FarNorLn +X841815_A Thu].
I have a fix implemented locally, and am just going thru all the before-after diffs (logs, CSVs, graphs, SQL file) to make sure everything's as expected. Looks good so far, and I expect it to continue to do so, but I just wanna be sure.

Bug #2, Web:
ISTR a while back Jim implemented a means of detecting segments at the same location in mapview, to not have to draw as many polylines and yield faster performance.
I think what's happening is that mapview is choosing the 2nd segment here ([SCT FarNorLn Thu +X841815_B]), which is unclinched, and drawing it as such on the map.
Edit: This won't be as big a deal once bug #1 is fixed.
This raises another question -- Highway is one thing, but should users automatically get credited for concurrencies in rail? I can see arguments for & against. Maybe this discussion has already happened somewhere on the forum.

I don't believe it would affect mileage (because the same granting of that mileage by concurrency

This bit isn't straightforward, due to bug #1.
The last 2 segments, from the last shaping point up north to Thu, and back south again to the next shaping point (at the same coords), aren't flagged as concurrent, so no extra mileage is granted.

would also take it away from totals).

For the other segments that are "self-concurrent", they'd only count once toward the region, system & overall totals, and count twice for the route itself.

The numbers make no sense though - I'm getting a missing 3 miles taking the length of Georgemas Junction-Wick from the total length and looking at the travels, but Georgemas Junction to Thurso is over 6 miles.

Let's unpack this; I bet I can make sense of it.
Nota Bene: showroute lists FarNorLn's total mileage as 173.31, whereas wptedit shows 173.30. So let's allow for 0.01 mi of wiggle room in the figures.
M3200.rlist has SCT FarNorLn Inv Thu. Starting at the start of the route. Makes things nice n easy.
Wptedit puts the milepost for Thu at 152.54.
Then, due to bug #1, the user gets no mileage until +X841815_B, at mile 154.14.
From there, it's concurrent with stuff they've already traveled down to GeoJct_2, at mile 159.14.
5 mi even; add that to the previous total = 157.54.
Showroute shows M3200 Traveled 157.55 mi, and there's that 0.01 mi (Probably just cumulative rounding errors) again.

I wouldn't see the mapview thing it as a bug, especially when concurrencies are high (which doesn't work well), eg into a busy terminus station where many services reverse in along their route (eg Zurich Bahnhof, though those services are not currently mapped, though the S-Bahn is more than enough concurrencies to be getting on with there!) and so reducing the number counted is a good thing.

Exactly. I could see it being done intentionally for just these reasons.

And yes, this applies to every route concurrent with itself across modes. I noticed this behaviour on mapview (the travelers stats on the route page are new to me).

True. It's nor just rail.
I put "rail" in the topic because... *shrug* it's pretty common in the rail data. A route goes into a station, then back out along the same track.

[Duke87]

This raises another question -- Highway is one thing, but should users automatically get credited for concurrencies in rail? I can see arguments for & against. Maybe this discussion has already happened somewhere on the forum.

It definitely has. It's worth noting that among railfans generally the preference is towards tracking completion of riding down the tracks, not riding individual services over the tracks. And indeed, this is how other means of tracking rail "clinches" out there have generally been set to work.

It is admittedly awkward with TM's structure of classifying different rail operators as different "systems" though, because of how for example marking a clinch of Amtrak will through concurrency detection give you mileage on potentially multiple commuter rail systems you may never have actually ridden a train belonging to.
A Trainlog coverage map, on the other hand, will only show you a binary "has the user clinched this" for all clinchable lines in a given region. It will not distinguish between different systems in that region on the map, nor will it do so on stats pages either - indeed, the very concept of "systems" does not exist on the site. This avoids the "I got credit for clinching Metro-North mileage when I've never been on a Metro-North train" problem and tends to be more standard for how things work in the rail "clinching" world.

I don't really support flipping TMRail over to this model though because it ultimately represents removing functionality and granularity, and why do that?

[yakra]

This raises another question -- Highway is one thing, but should users automatically get credited for concurrencies in rail? I can see arguments for & against. Maybe this discussion has already happened somewhere on the forum.

After posting that, I realized that not augmenting concurrencies would complicate things for making traveled graphs of railways.
Not insurmountable, but not something I really wanna deal with either.
That enough to push me into "Stop thinking about it" territory, even if it means I've ridden the D train without riding the D train.

It definitely has. It's worth noting that among railfans generally the preference is towards tracking completion of riding down the tracks, not riding individual services over the tracks. And indeed, this is how other means of tracking rail "clinches" out there have generally been set to work.

It is admittedly awkward with TM's structure of classifying different rail operators as different "systems" though, because of how for example marking a clinch of Amtrak will through concurrency detection give you mileage on potentially multiple commuter rail systems you may never have actually ridden a train belonging to.
A Trainlog coverage map, on the other hand, will only show you a binary "has the user clinched this" for all clinchable lines in a given region. It will not distinguish between different systems in that region on the map, nor will it do so on stats pages either - indeed, the very concept of "systems" does not exist on the site. This avoids the "I got credit for clinching Metro-North mileage when I've never been on a Metro-North train" problem and tends to be more standard for how things work in the rail "clinching" world.

I don't really support flipping TMRail over to this model though because it ultimately represents removing functionality and granularity, and why do that?

This all works for me.
My takeaway from this post is that for mot railfans, "systems" aren't a concept, and thus concurrency augments aren't something that'd really matter to them, rather than a preference to use (or not use) concurrency augments.
So I can get on board with that.