BC: NMPs

[Jim]

Looks like a few FPs and a fairly small number of points that need aligning, which I plan to do in the next few days.  There's one "looks intentional" pair that I'd like to hear from whoever plotted those before changing or marking FP.

[oscar]

Here's the NMP log entries for the "looks intentional" pairs:

bc.bc001@44A 49.228668 -122.829123 LI
bc.bc007b@BC7_W 49.228668 -122.829124 LI
bc.bc007b@BC7_W 49.228668 -122.829124 LI
bc.tchmai@44A 49.228668 -122.829123 LI

I might've had something with that, while I was maintaining in BC only cantch, and Si was managing canbc until it got activated (now it's dropped in my lap). But I don't recall any reason to leave those files slightly out of synch, and I see no reason not to fix the NMPs.

[si404]

BC7B and BC1/TCH are on different parallel carriageways through the complex interchange, and the intentional NMP was created to break the concurrency. Up to you if you want to merge it.

[michih]

BC7B and BC1/TCH are on different parallel carriageways through the complex interchange, and the intentional NMP was created to break the concurrency. Up to you if you want to merge it.

yep, should must stay as-is!

[oscar]

BC7B and BC1/TCH are on different parallel carriageways through the complex interchange, and the intentional NMP was created to break the concurrency. Up to you if you want to merge it.

yep, should must stay as-is!

Sure, let's keep it. Mark as FP.

[yakra]

should must

Another option is to leave the graph connection (and thus the Intersecting/Concurrent Routes feature) in place, and break the concurrency with a hidden point.

[michih]

Agree!

[Jim]

I haven't done anything with the BC7B and BC1/TCH which is sounds like can/should be handled a bit differently.  Everything else should be cleared up or marked FPs on tomorrow's site update.  Changes in this commit:

https://github.com/TravelMapping/HighwayData/commit/68ed13cfde9b41dd4a7e18166c6a76836b1877ee

[michih]

So, either copy these lines

Code: [Select]

bc.bc001 44A (49.228668,-122.829123) NMP bc.bc007b BC7_W (49.228668,-122.829124)
bc.bc007b BC7_W (49.228668,-122.829124) NMP bc.bc001 44A (49.228668,-122.829123) bc.tchmai 44A (49.228668,-122.829123)
bc.tchmai 44A (49.228668,-122.829123) NMP bc.bc007b BC7_W (49.228668,-122.829124)
to https://github.com/TravelMapping/HighwayData/blob/master/nmpfps.log or break the concurrency with a hidden point as suggested by @yakra, and we can close the issue.

[Jim]

I would prefer the solution that adds the point to maintain graph connections.  Oscar, would you like to add it or would you like me to do so?

[oscar]

I would prefer the solution that adds the point to maintain graph connections.  Oscar, would you like to add it or would you like me to do so?

I'll handle it, once I recover from a road trip I completed earlier today (trip report to follow).

[Jim]

Thanks, definitely not urgent.

[oscar]

Not completely understanding what's going on, but here's my proposed change to BC7B, with the +X223637 breaking any false concurrency between BC7B and TCH1/BC1/BC7, while preserving the graph connection at the BC1/7 point. There isn't one at BC7_W, nor should there be since there is no connection there between BC 7B and BC 7 (and that point is slightly out of synch with TCH/BC1's exit 44A point, so there seems to be no concurrency involving BC 7B anyway).

BC1/7 http://www.openstreetmap.org/?lat=49.230280&lon=-122.841740
+X223637 http://www.openstreetmap.org/?lat=49.229567&lon=-122.836383
BC7_W http://www.openstreetmap.org/?lat=49.228668&lon=-122.829124

** one of the coordinates in the last line are .000001 off the corresponding 44A points in TCH1/BC1 **

On second thought, is the intention to synch up BC7B's BC7_W point, and TCH/BC1's 44A point, to create a graph connection there, but which would create a false concurrency between the routes? Maybe that graph connection is unneeded (we have one at BC1/7 anyway), in which case the status quo is fine. Or am I missing something?

Please let me know, then I'll make a pull request for the revised BC 7B if needed.

Sorry for the delay or any confusion, but the return home from my latest road trip Saturday 10/14 has been rather messy. Not only deer damage to my road trip car (mentioned in "Other Discussion"), but I found the catalytic converter had been stolen from the car I use for local, which is elderly and most likely worth less than the cost of replacing the converter. On top of that. my PC is on the verge of turning into a brick before I'm ready to switch to its replacement, though I can keep it going for at least a few more days.

[oscar]

Looks like BC7B's actual west end is not within the TCH1/BC1/BC7 interchange, but rather is at the intersection of United Blvd. and Mariner Way, just north of BC 7. This eliminates the NMPs associated with TCH1/BC1 exit 44A, and creates a new graph connection between BC 7  and BC 7B at BC 7's United Blvd. interchange.

[michih]

The intention was to change BC7B as you proposed but also syncing the BC7_W so that it's no longer off by 0.000001:

BC1/7 http://www.openstreetmap.org/?lat=49.230280&lon=-122.841740
+X223637 http://www.openstreetmap.org/?lat=49.229567&lon=-122.836383
BC7_W http://www.openstreetmap.org/?lat=49.228668&lon=-122.829123

Since BC7B's west end is wrong, the point can be synched but needs to be renamed, and the other wp simply needs to be moved and renamed:

BC7 http://www.openstreetmap.org/?lat=49.232451&lon=-122.829853
BC1 http://www.openstreetmap.org/?lat=49.228668&lon=-122.829123

Labels in use are "BC1/7 BC7_E KINAVE". Since "BC1/7" is not existing anymore, we don't need any alt label except you go si404's way (I don't like) and you move it to wp "BC1":

BC7 http://www.openstreetmap.org/?lat=49.232451&lon=-122.829853
BC1 +BC1/7 http://www.openstreetmap.org/?lat=49.228668&lon=-122.829123

An update entry is necessary for BC7B anyway.

BC7's "ToBC1" needs to be renamed to "BC7B", and "BC1/7B" to "BC1" with alt label "BC1/7B".
BC1 and TCH don't need to be touched.

Edit: Sorry, BC7B does not reach BC1 at all but leaves the freeway at UniBlvd heading north. That's even simpler. Straightforward.