Web Design Discussion > General Web Design Discussion

mapview: rail & self-concurrencies

(1/2) > >>

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:

--- Quote from: si404 on October 02, 2024, 06:23:15 pm ---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?

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


--- Quote from: si404 on October 02, 2024, 06:23:15 pm ---I don't believe it would affect mileage (because the same granting of that mileage by concurrency

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


--- Quote from: si404 on October 02, 2024, 06:23:15 pm ---would also take it away from totals).

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


--- Quote from: si404 on October 02, 2024, 06:23:15 pm ---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.

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


--- Quote from: si404 on October 02, 2024, 06:23:15 pm ---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.

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


--- Quote from: si404 on October 02, 2024, 06:23:15 pm ---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).

--- End quote ---
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:

--- Quote from: yakra on October 02, 2024, 08:22:47 pm ---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.

--- End quote ---

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?

Navigation

[0] Message Index

[#] Next page