NJ: US 40 Minor Point Errors

[Markkos1992]

1.   I think that NJ140_W should just be NJ140.
2.   PorRd should be ForkBriRd (Fork Bridge Rd).
3.   The shaping point between NJ47_N and CR555 could be replaced with visible points at Morris Ave (MorAve) and Grubb Rd (GruRd).
4.   It looks like CR557_W should be moved to the Tuckahoe Rd intersection and be changed to CR557_N.  The existing CR557_W point should be changed to Brewster Rd (BreRd).
5.   WeyRd should be WeyMalRd (Weymouth-Malaga Rd).
6.   CR557_E should be CR557_S.
7.   Should OldHarHwy be moved slightly to the east?
8.   I think that NJ50/559 should just be NJ50_N.
9.   CR559_E should be CR559_S.
10.   I am unsure what DorAve should be. (also affects US 322)

[Markkos1992]

10.   I am unsure what DorAve should be. (also affects US 322)

I was thinking if AtlCityHS would be viable for Atlantic City High School, but I cannot think of any situation of an interchange just for a school.  I cannot think of any university certainly that this would apply to, and most intersections for public schools would either already have another street name associated with it or would not need a point in the first place.

[yakra]

2. Done.
3. Replaced with GruRd only.
4-7. Done.
8. Normally, I'd not include a CR in a slashed designation, but I think NJ's 500-series have a bit of a different flavor to them. With the other 559 point right next door... eh. Chose no-build.
9. Done.
10. New_Jersey_Road_Centerlines shapefiles have Dorset Ave. Keeping as-is.
https://github.com/TravelMapping/HighwayData/pull/4441

Saving the screwiest 1 for last. Nothing committed here yet.
Just plain NJ140 won't work, because there is a multiplex.
Re-checking the manual, I think it's unspecific enough, and the situation unspecific enough, to allow what I usually do in similar cases...
When one route just ends while a concurrent one keeps on going, I interpret the concurrency as having only one "multiplex split" to get a _Suffix. Everything from there to the end, I treat as "intermediate points". Here's the canonical example from my backyard -- MainSt is what ME9 actually intersects here. And MainSt is what ME111 intersects while it's concurrent with ME9. (Although. An argument could be made that while ME111 doesn't leave a concurrency here, ME9 does. Such an argument could be used to justify a ME9_E label on ME111...)

Following this recipe, CR540 would be the label on US40.
And on NJ140? To keep following the Maine example, CR540 would get chosen again.

But why do I feel a little more OK about potentially including US40 in the label? Moreso than ME9_E on ME111? I think the physical layout of the T junction may be swaying me here. What road ends, what road continues... Hm.

But wait, there's more!
With the geometry of this junction, the way the ramps are laid out & the way the US40 thru movements are made, it's possible I could even be talked into going 1PPI here, and collapsing the point at CR540 into the point at NJTpk. Thoughts?

[Markkos1992]

The NJ 140 situation now reminds me of when I tried to get a graph connection with US 119, PA 43, and the north end of PA 857.  The main differences are that both directions of US 40 intersect CR 540 here while only US 119 NB intersects PA 857 and there is not any sort of concurrency there either.

I think that keeping the points as-is may be the best solution here based on what we have done in similar situations before. (see PA 42 at I-80 and PA 44)  I would prefer CR540 instead of US40/540 since we are still within the interchange here.

[yakra]

The NJ 140 situation now reminds me of when I tried to get a graph connection with US 119, PA 43, and the north end of PA 857.  The main differences are that both directions of US 40 intersect CR 540 here while only US 119 NB intersects PA 857 and there is not any sort of concurrency there either.

My take is a bit different -- that case, the main issue was that there was no graph connection at PA857's end. Here in NJ, we have a graph connection and will keep it, no question, easy.

I think that keeping the points as-is may be the best solution here based on what we have done in similar situations before. (see PA 42 at I-80 and PA 44)

A very straightforward example of this type of thing.
The canonical example in my mind is I-93 / US3 / NH11/132/142. ME143 has one too.

I would prefer CR540 instead of US40/540 since we are still within the interchange here.

If it's still within the interchange, wouldn't that suggest keeping it a single point?
HA! I kid! But only somewhat -- Can I describe what sort of sets this case apart for me? Part of it's the multiplex. Eastbound US40 doesn't actually follow the NJTpk_N NJ140_W segment; it just exits the NJTP and grabs Wiley Rd straight off the ramp. The EB onramp, while functionally just the unfolded parclo ramp from the PA/NH/ME examples, nonetheless visually adds to the sense of it all being within the same footprint. And then we have WB 40 neatly curving right into the center point of the NJTP interchange and grabbing the onramp.
Geometrically/visually (and with the concurrency thrown in), the closest comparison I can think of is where US6 leaves I-195.

Despite all my arguing just now, I'm not super married to the 1PPI idea here. I'd probably only do it if there were enough voices saying Yeah Do It! There have got to be similar cases (of a not-quite-true 1-way multiplex) throughout the data, including in my own states. I'm leaning a wee bit more toward keeping as-is, what with showing a more precise endpoint for NJ140 and keeping a CR540 point (I wanna say Jason included all CT5xx waypoints when drafting usanj) in the mix.
I also prefer CR540 over US40/540; it's the most consistent with what I do in most (counterexample: AB500-something ending on a useless multiplex with AB 800-something) similar cases.

[yakra]

https://github.com/TravelMapping/HighwayData/pull/5046

[Markkos1992]

I just saw that the US 40 change created a duplicate label error.  Thankfully, you may be able to go CR540_W and CR540_E.

[yakra]

Fixed. I check datacheck errors pretty regularly, so no pressing need to post about them.
While I do have a LACKS_GENERIC FP that's been sitting for a bit, and a couple new LABEL_SELFREFs, I plan to address these by changing the datacheck routines to flag fewer FPs.