View Associated Routes

[rschen7754]

I respect your opinion but we already had a forum - on aaroads.com - and my experience is that some ideas of mine got lost. I think that's quite normal about "low priority" ideas.

Again, I like your proposal. What should I do now, rely on the developers that they will remember the proposal one day or should I submit an issue?

It is Github; you can always submit the code for your proposed change in a pull request, which may get it done sooner.

[Jim]

Low priority, but I'd like the routes that retain their numbers when crossing national boundaries (US/BC 97 et al) to be associated with each other. I'd even extend that to MSR routes (ID/MT/ND/MN 200).

I've thought the same thing, but the big complication here is that we'd be, for the first time, stitching together routes from different systems.  To put all of the I-90 chunks together was taken care of by the usai_con.csv file.  That was a natural extension and added in CHM.  The examples above are routes currently in different systems, so we'd have to introduce some new kind of "connectivity" files.

[michih]

I respect your opinion but we already had a forum - on aaroads.com - and my experience is that some ideas of mine got lost. I think that's quite normal about "low priority" ideas.

AARoads was never meant to be a permanent solution; it was only temporary till we got this forum up and running.

I just said that I (or we) already have some experience with discussing software development in a forum. Ideas are often born in threads with a different title, e.g. "Highway Data Discussion" or "Status of Travel Mapping". I think they easily got lost.

In my view, there are a lot of issues open on GitHub, and ideas are getting lost there already too; ones the devels may not be too keen on pursuing. It's that signal-to-noise ratio, again.

I think that's quite common in software development. There can be a huge requirement pool. Some will never be implemented but maybe one day a developer is looking through the open issues - detailed solution idea available, maybe link to forum discussion - and he will implement it.

I know, TM is just a not a commercial project. People work on it "just for fun". Maybe it's unfair to handle the project like it's done in commercial projects but... Sorry, I have some experience with software development in my job and we often complain about missing features, talk to developers about ideas, write email et cetera. When asking what happened to the idea, customer request it, my developers often say "sorry, I don't remember, it's not in an official feature list, let's discuss it again, write a requirement, describe what's needed, describe your solution idea in a document,..."

Keep in mind also that having a forum much like this one was the primary mode of communication and discussing the direction of the CHM project for MANY years, and worked very well IMO. This form of communication will be familiar and very natural to those veterans who've been around CHM/TM a long time. I can't speak for the others, but some may well prefer this form of communication and tracking of tasks. I know I for one do.

Sorry, I registered in 2014 but Tim didn't activate my account. Things have been changed, e.g. the new "preview systems" category. And I think there are more software developers involved now....

It is Github; you can always submit the code for your proposed change in a pull request, which may get it done sooner.

It's not about sooner or later. It's just about having all ideas - high and low priority - in a list which can be worked on if there time one day.

Sorry for OT. Again, maybe I'm wrong. Sorry!

[oscar]

Sorry if this has been raised elsewhere, but a different concept from "show associated routes" would be to include links for individual waypoints, to take you to other routes intersecting those waypoints. CHM has that feature, and I'm finding that hugely useful in my revamp of active California routes (Interstate and US). It also provides a user-friendly way to call up intersecting (not necessarily "associated") routes directly, without going back to an HB route list.

[yakra]

Sorry if this has been raised elsewhere, but a different concept from "show associated routes" would be to include links for individual waypoints, to take you to other routes intersecting those waypoints. CHM has that feature, and I'm finding that hugely useful in my revamp of active California routes (Interstate and US). It also provides a user-friendly way to call up intersecting (not necessarily "associated") routes directly, without going back to an HB route list.

Yes. I like this feature of CHM. The fact that the HB point list can link from, say, MT200 to ID200 demonstrates that this can in fact be done without any new kind of "connectivity" files. Maybe piggyback off the code that detects colocated points for concurrency purposes.

One thing that's been on my wish list since back in the CHM days is, in addition to the links in the waypoint list, to also have links from the InfoWindow you get when clicking on a waypoint. Maybe in a drop-down menu.

[oscar]

Sorry if this has been raised elsewhere, but a different concept from "show associated routes" would be to include links for individual waypoints, to take you to other routes intersecting those waypoints. CHM has that feature, and I'm finding that hugely useful in my revamp of active California routes (Interstate and US). It also provides a user-friendly way to call up intersecting (not necessarily "associated") routes directly, without going back to an HB route list.

Yes. I like this feature of CHM. The fact that the HB point list can link from, say, MT200 to ID200 demonstrates that this can in fact be done without any new kind of "connectivity" files. Maybe piggyback off the code that detects colocated points for concurrency purposes.

CHM used different code to detect intersecting/connecting routes, that includes "close calls" and does not require exact matches like concurrency detection does. A lot of intersections have inexact matches, but CHM picked them up anyway.

[mapcat]

CHM used different code to detect intersecting/connecting routes, that includes "close calls" and does not require exact matches like concurrency detection does. A lot of intersections have inexact matches, but CHM picked them up anyway.

Are you sure? I recall discovering a few cases where the detection didn't happen, and it turned out that the waypoints were off by .00001° or something.

[si404]

Are you sure? I recall discovering a few cases where the detection didn't happen, and it turned out that the waypoints were off by .00001° or something.

It's a reason why there was no insistence on NMP being an issue - it wasn't needed for this function. A missing one would probably be as the options are None-Some-More-Many, with no All option.


Intersecting routes must be one of the most important things not yet on TM.

[yakra]

D'oh! Oscar is right! I completely spaced on that distinction!
Well then -- maybe piggyback off the code that detects NMPs. Modified to also include exact matches. Although... that may have been an earlier script, in what -- Python? -- that's never made it into the PHP the site does things in now. So that may require a bit of rewriting. Ugh. Work...

I understand what's going on below, but I think the thread may be about to get confusing.

Are you sure? I recall discovering a few cases where the detection didn't happen, and it turned out that the waypoints were off by .00001° or something.

I think mapcat is referring to cases where multiplex detection didn't happen. Waypoints were off by .00001° on purpose to avoid false-positive multiplexes. (For example, TX US183 as the frontage roads of TX130.)

It's a reason why there was no insistence on NMP being an issue - it wasn't needed for this function. A missing one would probably be as the options are None-Some-More-Many, with no All option.

Oscar and Si are referring to CHM's Intersecting highways shown function.
"it wasn't needed for this function", I parse as "Exact coordinate matches were not needed for the 'Intersecting highways shown' function."
"A missing one would probably be as the options...", I parse as "A missing highway (from the 'Intersecting highways shown' list) would probably be an issue as the options..."

Getting off-topic here, I think including NMPs as a datacheck might be worth thinking about, if for no other reason than to nail down multiplexes.
I think one of the CHM veterans (forget who) may have even agreed with me on that, over on AARoads... ISTR the discussion just fizzled. Maybe because it's viewed as a low priority, maybe because it'd open up a huge Pandora's box of Possible Errors to look thru & deal with & check off as false positives. Something that even I, as someone suggesting it as "worth thinking about", don't want to have to deal with.

Intersecting routes must be one of the most important things not yet on TM.

disagree strongly
disagree somewhat
neither agree nor disagree
agree somewhat
agree strongly

[Thing342]

Check out:

http://tm.teresco.org/hbtest/mapview.php?u=terescoj&rte=I-90

for example.

Nice new feature from Thing 342.

That's pretty sweet.  However, it will need work with putting the segments in the correct order in the grid.
http://tm.teresco.org/hbtest/mapview.php?u=terescoj&rte=I-74

I-74 is in pretty bad shape as it's going in 'alphabetical' order.   Maybe we need to create special CSV files for that?

Not a lot we can do about this without getting more info into the SQL database. I would propose an integer pos field in connectedRouteRoots (possibly pulled from the connection files) that show the segment's position in the larger route.

Meh, I don't think everything needs a GitHub issue. I'd prefer to keep the signal-to-noise ratio over there more manageable; devels over there have lot to keep track of. My mentioning the topic here is nothing more than simple brainstorming, not even rising to the level of a request for a feature. If Thing342 or whoever else may be working on the website & mapview.php is actually seriously planning on implementing it, they're welcome to create an issue to track that themselves if they see fit.

The issue won't get lost. It's right here in the forum. That's what the forum is for. Some things deserve at least a little public discussion first before being immediatekly tracked onto the to-do list.

For looking at things to be done, I generally pull from the issue page on GitHub for things to tackle. Things mentioned on the forums do have a tendency to get lost in a list of my things to do, especially since school has caused me to put this project on the backburner and I don't have too much time to look at the forums. I'd also really appreciate it if those who post the issues would close them once they're fixed, because I can't.

[Jim]

I'd also really appreciate it if those who post the issues would close them once they're fixed, because I can't.

I think I just added permissions so you can now.  Give it a try when you have a chance.