A route follows a one-way pair, each half of which also has its own number

[neroute2]

http://travelmapping.net/hb/?r=mexnl.mex040
Zoom into Monterrey and note the long section with no points. Here 40 eastbound follows the south side of the river and 40 westbound follows the north side. Usually I'd just put a point in the middle of the river for each junction. The problem is that Monterrey has its own system of numbered routes, which I've drafted (but not yet pushed to devel status yet). Eastbound Federal 40 is also Monterrey 20, and westbound Federal 40 is also Monterrey 22. There's no way to have one line for Federal 40 and separate lines for Monterrey 20 and 22 while making them overlap.

Are there any existing cases that are anything like this?

[michih]

I've not checked our rules on that but I'd draft MEX40 concurrent to M20 eastbound (because that's the waypoint order of MEX40) and draft a MEX40 (Monterrey) route concurrent to M22 westbound.

[Jim]

Forgetting for the moment the restrictions of our current TM implementation related to concurrency detection...

- A traveler who lists 20 should also get credit through concurrency detection for overlapping 40.
- A traveler who lists 22 should also get credit through concurrency detection for overlapping 40.
- A traveler who lists 40 should not get credit through concurrency detection for 20 or 22, since we can't know which one they meant.

[yakra]

- A traveler who lists 40 should not get credit through concurrency detection for 20 or 22, since we can't know which one they meant.

This traveler will at least still have the option of adding 20 or 22 manually.
I'm not gonna look at this too closely; I just woke up & kinda can't parse it. I don't envy neroute2

Not sure if either of these would help, how related they really are, but:
http://travelmapping.net/hb/?r=tx.us087&lat=35.210809&lon=-101.832147&zoom=14
http://travelmapping.net/hb/?r=ma.us006&lat=41.722339&lon=-71.152568&zoom=15

[Jim]

I'm thinking a wrinkle here from the data processing and stats points of view are that a traveler who lists either 20 or 22 should get credit for that segment of 40, but if they list both, should only get credit for 40 once, not twice.

There's probably not a good solution without changes to the data processing/stats/maps infrastructure.

[Bickendan]

I'd recommend Michih's solution as probably the simplest.

[bhemphill]

That's kind of similar to Amarillo, Texas where US60, US87, and US287.  US60 uses a one-way pair with US287 northbound vs US87 southbound through that stretch of town.

[yakra]

That's kind of similar to Amarillo, Texas where US60, US87, and US287.  US60 uses a one-way pair with US287 northbound vs US87 southbound through that stretch of town.

I'm thinking a wrinkle here from the data processing and stats points of view are that a traveler who lists either 20 or 22 should get credit for that segment of 40, but if they list both, should only get credit for 40 once, not twice.

There's probably not a good solution without changes to the data processing/stats/maps infrastructure.

Someone who's driven US60 in Amarillo has also driven... something else, but we don't know what.
Eastbound on Buchanan, it's US287 north.
Westbound on Pierce, it's US87 south.
Here, there's no multiplex to be detected, as 87 & 287's traces fall between their respective couplets a block west. Users will need to also .list their section of US87 or US287 as appropriate.
Travelers on US87 or US287 may not have also traveled US60: US87 NB on Fillmore & US287 SB on Taylor.

- A traveler who lists 40 should not get credit through concurrency detection for 20 or 22, since we can't know which one they meant.

Amarillo & Fall River are like the OP in this regard...
- A traveler who lists US60 should not get credit through concurrency detection for US87 or US287, since we can't know which one they meant.
- A traveler who lists MA138 should not get credit through concurrency detection for US6 or MA79, since we can't know which one they meant.

- A traveler who lists 20 should also get credit through concurrency detection for overlapping 40.
- A traveler who lists 22 should also get credit through concurrency detection for overlapping 40.

Amarillo & Fall River are un like the OP in this regard:
- A traveler who lists TX US87 should not get credit through concurrency detection for overlapping US60, because it may have been NB on Fillmore.
- A traveler who lists TX US287 should not get credit through concurrency detection for overlapping US60, because it may have been SB on Taylor.
- A traveler who lists MA US6 should not get credit through concurrency detection for overlapping MA138, because it may have been SB on the western frontage road.
- A traveler who lists MA79 should not get credit through concurrency detection for overlapping MA138, because it may have been NB on the inner roadway.

This makes the OP really unique. I'm not aware of anything else quite like it.


Don't think I'm on board with michih's solution.
IMO, the greater good is to keep routes' traces & points close to the centerline where practicable; to plot routes faithfully, and this outweighs the desire to get multiplexes nailed down in more places. I say give users the option.
Thus so far I'm leaning to more of an Amarillo-style solution, where each route has a trace along its own center.
While each route would still have its own correct mileage, the downside is that the system & region would have slightly inflated mileage, as we see in Amarillo & Fall River. (But hey, that'll happen sometimes.)
Michih's solution wouldn't add more mileage to the system & region, but in a way, it does to a route. Or group of routes if you will; MEX40 + another MEX40 (even if it's something we can't filter for on the maps & stat pages.)

But most importantly,

if they list both, should only get credit for 40 once, not twice.

In my view, that's what would in effect be happening.

This would create an extra fake MEX40 route that's already part of MEX40 proper, really.
There's no ME5 (Saco) to overlap I-195 & US1.
I left out NH4 Trk (Dover), because it overlaps what's already half of NH4 proper.
There's of course nothing in Amarillo for an alternate direction of 60, 87 or 287.
Nothing in Watertown NY. Or Holyoke MA for US202.
This idea of creating an alternate route file for just an alternate direction of a single route is a slippery slopy, one hell of a Pandora's Box to open.


Looking at the situation in Monterrey some more, ugh, what a mess. It may or may not help me to have a clearer understanding of what 20 & 22 do here. Are these one-way routes? Is something else going on? I may check out neroute2's drafts of these and see what I can see. Not right this moment though.

[neroute2]

I've put the Monterrey routes in preview, so you can see what's going on in https://travelmapping.net/user/mapview.php?rg=MEX-NL . I'm leaning towards putting MEX40 down the middle of the river; the only issue is that it won't have graph connections with intersecting routes.

There's also a similar issue with 85, where northbound is signed using 22 west-15 north-17 north while southbound appears to use 210 east-25 south. In this case, signs are missing on 210, so it might make sense to use the northbound route, but the southbound route is signed on 25.

[michih]

I've not checked our rules on that but I'd draft MEX40 concurrent to M20 eastbound (because that's the waypoint order of MEX40) and draft a MEX40 (Monterrey) route concurrent to M22 westbound.

This.

[Duke87]

My interpretation of the situation is that 20 and 22 are not distinct routes, they are in effect opposite directions of the same route. So, handle it like any other one way pair: run 40 down the middle, and have 20/22 (as one single route in the HB) concurrent with it.

Admittedly, this takes a reality on the ground which simply does not fit our existing framework and bludgeons it into said framework, but what else can we really do here?

[neroute2]

My interpretation of the situation is that 20 and 22 are not distinct routes, they are in effect opposite directions of the same route. So, handle it like any other one way pair: run 40 down the middle, and have 20/22 (as one single route in the HB) concurrent with it.

20 and 22 are two-way west of 9 (where 40 crosses to use only 22). 22 also becomes two-way east of 31 (with 20 still existing to the south).

Maybe have one line mapped along the river between 9 and 31, with 20 and 22 overlapping there? But clinching 20 shouldn't clinch any of 22. And this doesn't work for 85, since (among other issues) large parts of 15 and 25 are two-way.

[Duke87]

Maybe have one line mapped along the river between 9 and 31, with 20 and 22 overlapping there? But clinching 20 shouldn't clinch any of 22.

This... is probably the least bad solution.

And actually, this resembles a common issue in Costa Rica that often part of a route follows a one way street and anyone heading the other direction either has to find their way around or ignore a do not enter sign (the latter is apparently quite common practice for people on mopeds and motorcycles). I pretty quickly decided "there are no one-way routes", and in all such situations identified the most logical thru route for traffic in the opposite direction and mapped it as an implied one way pair.

Now, usually said most logical thru route has no route number or only has in inventory number, but there are cases where opposite halves of a one-way pair officially have different route numbers. In these situations, following the same principle as above, I've run the two concurrent down the middle (see for example RS100 and RS109).