Author Topic: Joining multi-state state routes  (Read 10217 times)

0 Members and 1 Guest are viewing this topic.

Offline Highway63

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 538
  • Gender: Female
  • Last Login:July 03, 2024, 01:59:15 am
Joining multi-state state routes
« on: July 28, 2018, 03:03:45 pm »
State highways keep the "View Associated Routes" option though they typically don't have any. But where a highway keeps the same number across state lines, could they have their own page, or is that too difficult since multiple states would have that number?

For example, IA-MO-AR 5, IL-IA-NE-WY 92, or ID-MT-ND-MN 200.

Places where the route is a continuation but doesn't keep the number (e.g. IA 175-NE 91) would be a different case.

Offline sipes23

  • Newbie
  • *
  • Posts: 29
  • Last Login:August 19, 2019, 12:44:31 am
Re: Joining multi-state state routes
« Reply #1 on: July 30, 2018, 04:28:19 pm »
There are more than a couple of these lurking in New England as well. I'm pretty sure Maine and New Hampshire (and maybe Vermont) have a highway 9 that links. There are probably others.

Offline rickmastfan67

  • TM Collaborator (A)
  • Hero Member
  • *****
  • Posts: 2050
  • Gender: Male
  • Last Login:Today at 01:05:43 am
Re: Joining multi-state state routes
« Reply #2 on: July 31, 2018, 01:11:22 am »
We also have SC/GA/FL 121.

Offline Jim

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 2854
  • Last Login:Today at 01:15:11 pm
Re: Joining multi-state state routes
« Reply #3 on: July 31, 2018, 07:40:41 am »
The complication here is that to date, all "connected routes" are part of a single system, like usai, usaus, or eure.  There is currently no good mechanism within the system to specify that a road in usany is connected to one in usama, for example, because no _con.csv file spans those two systems.  I'm thinking that to do so without code and DB changes would require a new system (usamsr?) which has copies of all the pieces of multi-state routes.  I'm sure there are better solutions, though, that do have code/DB changes, but that would support this in a cleaner way.  If this is generally seen as a useful enhancement, a discussion here of how it might work and a GitHub issue in the DataProcessing repository to make sure it stays on the radar would be good.

Offline bejacob

  • Full Member
  • ***
  • Posts: 230
  • Last Login:November 08, 2024, 03:03:32 pm
Re: Joining multi-state state routes
« Reply #4 on: July 31, 2018, 08:02:54 pm »
The complication here is that to date, all "connected routes" are part of a single system, like usai, usaus, or eure.  There is currently no good mechanism within the system to specify that a road in usany is connected to one in usama, for example, because no _con.csv file spans those two systems.  I'm thinking that to do so without code and DB changes would require a new system (usamsr?) which has copies of all the pieces of multi-state routes. 

These are not really multi-state routes. The fact the the route has the same number on each side of the state line is convenient, but the reality is that once you cross the state line, you're on a new route. I've been on numerous roads that continue across a state line where the numbers change. I don't see these as any different as routes with the number stays the same on either side of the border.

Not sure everyone will agree, but I don't see any need to change the way TM treats these routes.

Offline yakra

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 4422
  • Last Login:November 08, 2024, 04:00:10 pm
  • I like C++
Re: Joining multi-state state routes
« Reply #5 on: August 01, 2018, 11:48:33 pm »
These are not really multi-state routes. The fact the the route has the same number on each side of the state line is convenient, but the reality is that once you cross the state line, you're on a new route. I've been on numerous roads that continue across a state line where the numbers change. I don't see these as any different as routes with the number stays the same on either side of the border.

Not sure everyone will agree, but I don't see any need to change the way TM treats these routes.
IAWTP.

And as for my roadgeekly personal particular peculiarities...
IMAO, New England Interstate 9 ends in Wells, and New England Interstate 11 ends in Biddeford! ;)
Sri Syadasti Syadavaktavya Syadasti Syannasti Syadasti Cavaktavyasca Syadasti Syannasti Syadavatavyasca Syadasti Syannasti Syadavaktavyasca

Offline bejacob

  • Full Member
  • ***
  • Posts: 230
  • Last Login:November 08, 2024, 03:03:32 pm
Re: Joining multi-state state routes
« Reply #6 on: August 02, 2018, 07:20:12 am »
These are not really multi-state routes. The fact the the route has the same number on each side of the state line is convenient, but the reality is that once you cross the state line, you're on a new route. I've been on numerous roads that continue across a state line where the numbers change. I don't see these as any different as routes with the number stays the same on either side of the border.

Not sure everyone will agree, but I don't see any need to change the way TM treats these routes.
IAWTP.

And as for my roadgeekly personal particular peculiarities...
IMAO, New England Interstate 9 ends in Wells, and New England Interstate 11 ends in Biddeford! ;)

Fair enough. When they get signed that way, I might change my mind.  :D

Offline Bickendan

  • TM Collaborator
  • Hero Member
  • *****
  • Posts: 553
  • Last Login:November 07, 2024, 12:50:15 am
Re: Joining multi-state state routes
« Reply #7 on: August 03, 2018, 01:49:58 am »
The complication here is that to date, all "connected routes" are part of a single system, like usai, usaus, or eure.  There is currently no good mechanism within the system to specify that a road in usany is connected to one in usama, for example, because no _con.csv file spans those two systems.  I'm thinking that to do so without code and DB changes would require a new system (usamsr?) which has copies of all the pieces of multi-state routes.  I'm sure there are better solutions, though, that do have code/DB changes, but that would support this in a cleaner way.  If this is generally seen as a useful enhancement, a discussion here of how it might work and a GitHub issue in the DataProcessing repository to make sure it stays on the radar would be good.
Also: BC/YT 37, BC/AB 49, BC/AB 3, AB/SK 55, SK/AB 17, SK/MB 57, SK/MB 49, BC/AB/SK/MB 16, BC/AB/SK/MB 1, and YT 1, 2, 3 (for their BC portions), and NWT 5 (for its border hops with AB).
Then there's also the complication of the international varieties -- US/BC 101 (discontinuous), CA/OR/WA/BC 99 (all discontinuous), US/BC 97 (and its Yukon border hopping), US/BC 395, US/BC 95 (AZ 95 also says hi), US/BC/AB 93, US/MB 83, ND/MB 32, 75 (discontinuous), 59, MN/ON 11 (discontinuous and more likely a coincidence), US/ON 71, US/MN/ON 61 (US and MN discontinuous), VT/QC 139, 243, 147, QC/VT 141, VT/QC 253, ME/NB 161 (connected by ME 161S), I/NB 95, and MEX/US 57. Of these, 101, 99, 75, 11, and 161 can be ruled out. (Someone should get MNDOT and NDDOT to reroute the northern fringe of US 75 over to I-29 now that MB 75 replaced MB 29). AZ 95, though an 'extension' of US 95, is really a spur, and is discontinuous to itself, despite rumours of unsigned routing along I-40 into California to Needles.
MEX 57 is likely discontinuous from itself, because of MEX 15D (which is certainly discontinuous from itself).

The overall point is whether or not the respective DOTs/MOTs consider these to be singular corridors with numbers assigned as such (ID/MT/ND/MN 200 for example) versus routes that happen to continue a designation (MN/ON 11 and ME/NB 161?).

But, speaking briefly of discontinuities -- what of the US routes we currently have up in Yellowstone? Once the National Park set goes up, US 20, 89, 191, and 287 will need to be addressed -- and that will break their continuity.