Web Design Discussion > General Web Design Discussion

ShowConc / List of Concurrent Highways

(1/2) > >>

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.

--- Quote ---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)
--- End quote ---
Very nice!

Wish list item:
Concatenating adjacent segments, as done on CHM.
So instead of 45 lines of
--- Quote ---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)
--- End quote ---
we could have one clean and simple
--- Quote ---New concurrency [ME111 to ME4_N via me.us202][US202_W to US202_E via me.me004] (2)
--- End quote ---

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:
--- Quote ---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)
--- End quote ---
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
--- Quote ---[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)
--- End quote ---
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
--- Quote ---[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)
--- End quote ---

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

But anyway. I found some more redundancy in concurrencies.log, in cases of multiplexes of 3 or more routes. Check this out:
--- Quote ---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)
--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page