ShowConc / List of Concurrent Highways

[yakra]

Does TM have an equivalent of CHM's showconc.php?
http://cmap.m-plex.com/stat/showconc.php
Nothing yet, right?
A big item on my wish list.

[oscar]

TM has a concurrencies log, http://tm.teresco.org/logs/concurrencies.log

I used it to confirm that my California Interstates/US routes cleanup preserved the concurrences that were supposed to be there, and didn't introduce false concurrencies.

[yakra]

Very nice, thank you.

What I really like, compared to the old page on CHM, is having more than two routes listed on a single line.

Extended concurrency [ME135_N to ME135_S via me.us202][ME135_N to ME135_S via me.me011][ME135_N to ME135_S via me.me100][US202_E to US202_W via me.me135] (4)

Very nice!

Wish list item:
Concatenating adjacent segments, as done on CHM.
So instead of 45 lines of

New concurrency [ME111 to SacoRd via me.us202][US202_W to SacoRd via me.me004] (2)
New concurrency [SacoRd to WestRd via me.us202][SacoRd to WestRd via me.me004] (2)
...
New concurrency [ElmSt to ME4_N via me.us202][ElmSt to US202_E via me.me004] (2)

we could have one clean and simple

New concurrency [ME111 to ME4_N via me.us202][US202_W to US202_E via me.me004] (2)

At first I wasn't quite sure how adaptable concatenating & listing the full length of a concurrency would be to listing an n-route concurrency on a single line -- what to do when 2 or more routes are already concurrent, and another one joins in the fun?
But look at this:

Extended concurrency [ME135_N to ME135_S via me.us202][ME135_N to ME135_S via me.me011][ME135_N to ME135_S via me.me100] (3)
Extended concurrency [ME135_N to ME135_S via me.us202][ME135_N to ME135_S via me.me011][ME135_N to ME135_S via me.me100][US202_E to US202_W via me.me135] (4)

I suppose the code is already, in a way, adapting itself to this, by listing the triplex separately from the quadruplex.

We could have one line for each n-plex involved, something like

[ME121 to US201_S via me.us202][US202_Aub to US201/202 via me.me011] (2)
[ME26_S to US201_N via me.us202][US202_W to US202_E via me.me100] (2)
[US202_Aub to US201/202 via me.me011][ME121 to US201_S via me.me100] (2)
[ME121 to US201_S via me.us202][US202_Aub to US201/202 via me.me011][ME121 to US201_S via me.me100] (3)
[ME135_N to ME135_S via me.us202][ME135_N to ME135_S via me.me011][ME135_N to ME135_S via me.me100][US202_E to US202_W via me.me135] (4)

Note that here, the 202/11 & 11/100 duplex each have endpoints exactly the same as the 202/11/100 triplex. Their lines could even be eliminated, leaving us with

[ME26_S to US201_N via me.us202][US202_W to US202_E via me.me100] (2)
[ME121 to US201_S via me.us202][US202_Aub to US201/202 via me.me011][ME121 to US201_S via me.me100] (3)
[ME135_N to ME135_S via me.us202][ME135_N to ME135_S via me.me011][ME135_N to ME135_S via me.me100][US202_E to US202_W via me.me135] (4)

New vs. Extended concurrency:
It took me a little bit, but I see that "Extended concurrency" is used when an additional route is added onto a segment already flagged as a concurrency, e.g. 202/11/100 "extended" to 202/11/100/135.
If concatenating adjacent segments as I've outlined above is eventually implemented, there would be far fewer "New concurrency" items to list, and the importance of distinguishing them (New/Extended) would be diminished IMO.
If omitting listings of, for example, 2-route concurrencies when part of 3-route concurrencies (the 202/11 & 11/100 example above) would save us some more new & extended listings, and blur the New/Extended distinction as we have it now: an "extended" type concurrency, with no corresponding "new" listing...
Thus, if implementing these changes, I'd suggest leaving out the "New concurrency" / "Extended concurrency" text. Having each listing itself left-justified would make the file neater and easier to read IMO.
On that note, one space between each bracketed listing could also help readability. Worth the small delta in file size inflation , and a drop in the bucket compared to what could be cut out as described above.

Further trimming the fat:
At 43.6 MB, this is a huge file. It takes a lot of CPU juice just loading it into my browser. Triple-clicking to highlight a single line of text, and copying it to the clipboard, will both redline one of my CPU cores for several seconds.
Most of the space of the file is taken up by the Concurrency augments for individual travelers. These probably aren't all that useful for the average developer who wants to look up a few routes and do some debugging; I don't think this file is the best place for them. While I'd prefer to use the HB to look at how concurrency augments affect my list/maps/stats, I'll concede that this info might be useful. Instead, how about keeping it in traveler .log files?

Tangentially related:
I miss the cleanliness of the CHM-style logs, listing errors & that's it. The traveler stats are less needed now that we have Thing342's userpages, region.php & system.php. Though some of the stats might differ or what have you (I haven't scrutinized the stats that closely)... I can see an argument for keeping them in. What do you think of the idea of splitting up traveler logs into multiple files?
• yakra.error.log
• yakra.stats.log
• yakra.concurrencies.log

Consider this post as just a brainstorming session, and not a concrete request for anything. Despite my having said "Wish list item" above.

[yakra]

Meant to add at the tail end of the previous post, that the concurrency-listing routines are probably pretty uncomplicated now. Encounter a multiplexed segment, log it, be done with it; not much to think about. Surely all that stuff I mentioned above would take up more CPU cycles, a much larger memory footprint, and more program complexity. (But it'd be worth it. )

But anyway. I found some more redundancy in concurrencies.log, in cases of multiplexes of 3 or more routes. Check this out:

New concurrency [9 to 10 via ns.ns101][NS101(9) to NS101(10) via ns.ns001] (2)
Extended concurrency [9 to 10 via ns.ns101][NS101(9) to NS101(10) via ns.ns001][NS101(9) to NS101(10) via ns.evatrl] (3)
...
New concurrency [NS101(9) to NS101(10) via ns.evatrl][9 to 10 via ns.ns101] (2)
Extended concurrency [NS101(9) to NS101(10) via ns.evatrl][9 to 10 via ns.ns101][NS101(9) to NS101(10) via ns.ns001] (3)

[yakra]

Had an idea while working out the Oklahoma concurrencies...
Visual multiplex inspection. It can streamline the process of checking out concurrencies, as sifting thru concurrencies.log can be a bit unwieldy.

I'm envisioning a modification of the HB to plot two (only 2, no more; keep it simple) routes: hb.php?r=ok.i040&r2=ok.us062, or somesuch.
Route segments unique to one route would be plotted in gray, and segments shared by both routes would be shown in red.

Whaddaya think? Anyone willing to tackle this? If it came to pass I know I for one would find it hella useful, and be very grateful.

[si404]

I'd quite like a 'user' that has clinched all the concurrent sections and nothing else. Similar graphical display to what yakra proposes is thus possible, and one can check over a whole region in one go.

[yakra]

I'd quite like a 'user' that has clinched all the concurrent sections and nothing else. Similar graphical display to what yakra proposes is thus possible, and one can check over a whole region in one go.

One thing that can gum up the works: triplexes. Take for example in Tulsa, where US64 & US75 are multiplexed over I-444. Right now, the US64/75 concurrency is okay, but their respective concurrencies with I-444 are broken. Looking at the map you described, I could miss out on this info.
Not shouting down your idea by any means though. It's still useful; this is just something to be mindful of.

[Jim]

Here's a thought on this, but I haven't decided how hard it would be to do.  I'd like to have a map view that shows all concurrencies in some color, and near-concurrencies (potential concurrencies, though in many cases intentionally not) in another color.  Segments carrying a single route would be left out entirely.

I think this fits in with the graph view of the data that I use for my academic projects.  I have lots of plans for that work this summer, so this kind of view might be part of my upcoming enhancements.

Something I could probably whip up quickly is a view of the data in graph form, with connections color-coded by the number of concurrent routes they carry.  The sticking point there is that the graph data is all from old CHM data files, but one of my priorities early this summer is to write new code that generates graph data from our current wpt and csv files.  Ideally, it would be done as part of site updates.