canmbw: Winnipeg City Routes

[yakra]

Posted in another thread, but relevant here:

Perhaps a more relevant question might be: are the "Winnipeg City Routes" (Winnipeg, Manitoba, Canada) (canmbw) actually maintained by the province, or by the city? I don't know, but perhaps someone on the forum does, and the answer could be relevant here.

Maintained by the city I believe.
The Winnipeg Routes are a unique case, a one-off; they're the only such numbered/signed city system in Manitoba; it's highly unlikely that there will ever be another in the future. As such, there won't be any confusion with any other potential city systems, or a need to differentiate multiple such systems within Manitoba.
Some quotes from the canbmw thread:
Jim: "These seem to be an unusual case where they are well-signed and seem to take the place, within the Perimeter Highway, of what might normally be expected to be part of the provincial system."
mapcat: "I agree that they're a special case, and not analogous to USA county routes, or other smaller district systems we don't include."
I agree with this assessment. (Of course, having drafted the system. ) I'll note that not only are many of them extensions of canmb/canmbs routes from outside the Perimeter Highway, but many are themselves former Provincial highway alignments.
The canmbw thread blew up a bit too fast, and I've just left it alone for a while, but some day I'd like to revisit it, hash out a few of the topics therein as needed (maybe even with a topic split), and move canmbw toward activation again. But it's a low priority right now.

I still haven't gotten back around to that.
I have a good number of different sub-projects I'm working on, with the result that any given one (or all) of them will move along slowly.
My main priority right now is an ongoing Arkansas Cleanup. Once that's more out of the way (or I want to take a break from it) I'll put more attention on canmbw or usanyp, whichever I think would face a quicker path to activation.

[yakra]

I *could* go into the history of tiers, a precursor "layers" concept in CHM, and their development in TM. But I'm not always very good with the whole brevity thing.
There's been talk in this thread and others about how to define a given tier, what should/shouldn't be included, etc. IMO, this is overthinking it a bit; all a tier really does is determine in what order systems are rendered on the map views (mapview.php, region.php).
WRT what to include, where/why/how, one size does not fit all, and what works in one area may not work well in another. EG, North America vs. Europe, or even different regions within Europe.
For any system under consideration, we'd want it to pass the "actually makes sense" test. (A subjective judgment, yes.) I foresee more yellow / tier 5 in Canada, with Manitoba Provincial Roads (which @julmac mentioned upthread) and Alberta Provincial Highways 500-986 in the pipeline. (There's potential for yellow / tier 5 in SK too, but SK isn't my turf.) I see more limited use in the USA: Texas FM & RM roads are in my longer range plans; other than that, we only have the Montana Secondary State Highways now. (I can't really comment on potential systems in other states; my knowledge is limited.)

Does canmbw make sense?
I think so. For my rationale, see my previous post, the bits where I quoted myself.

I plan on moving canmbw back to preview status within the next several days.

[yakra]

canmbw has been moved back to preview status, and is ready for peer review.

Tricky routes include Rte37 & Rte57, as noted in the OP.

[michih]

canmbw has been moved back to preview status, and is ready for peer review.

Here it is

Concurrencies:    FINE
NMPs:             ALREADY FPs
Add cannf routes: NOPE
soures:           https://www.gov.mb.ca/mit/map/ + http://mli2.gov.mb.ca/roads_hwys/index.html
route list check: I've compared the April 2019 map to our graph on mapview and think that it's fine. The shp files are from 2017 but the system was already drafed in 2016 - @yakra: Maybe you can have look whether any route has been added or removed (compared to shp files or any other source?


Rte20:
EliRd should be located in the median or do you generally position it like this when there are only ramps for one carriageway?
MB100 -> MB59/100 ?
MB101 -> MB59/101 ?
The difference to Rte42 wp MB75/100 is that M59 is concurrent to Rte20 but it also extends and I usually indicate both in this case.


Rte30:
Add corresponding wp for EliRd @ Rt20
MB1 is off


Rte37:
WattSt_N -> ChaAve ? (just because it's shorter)
Please check whether shp files have been updated
We might add a branch for the southern route b/n Rt42 and Rt30?


Rte42:
Rte125 is off, move it to the overpass!
SutAve is off, move it to the underpass!
TalAve is off, move it to the underpass!
TalAve -> MidAve
MB101 -> MB101/204 like you've labeled MB75/100


Rte52:
MB1_E is off
MB100 -> MB100/200


Rte57:
Rte70 might be moved to http://www.openstreetmap.org/?lat=49.900885&lon=-97.158837 ?


Rte85:
StuRd is off
EmpSt is off, move it to the overpass!
ArlSt is a litte bit off
MB1_E is off


Rte90:
Add corresponding wp for OakPtHwy @ MB190 (or remove the MB190 wp)
Add corresponding wp for AcaRd_W @ Rt70


Rte95:
Add corresponding wp for Rt96/Rt105 junction


Rte105:
Add corresponding wp for CamSt @ Rt95
MB100 -> MB100/241


Rte115:
Add corresponding wp for TacAve @ Rt57


Rte145:
MB100 -> MB100/427


Rte150:
MB1/135 -> MB1_E


Review done except if you have comments to my suggestions.

[neroute2]

For the record, there are two Mexican cities - Mexico City and Monterrey - that have systems like this.

[yakra]

The shp files are from 2017 but the system was already drafed in 2016 - @yakra: Maybe you can have look whether any route has been added or removed (compared to shp files or any other source?

The LRS files are blank within the perimeter hwy other than a few stubs. The newest NRN files still date to 2016-06-06, so nothing new there.

Rte20:
EliRd recentered, also in MB59.
MB100 & MB101: I'm less of a fan of indicating a concurrent route in a case like this, where the route we're plotting is otherwise concurrent and then just ends. I consider the newly intersected route to be the more important piece of information. I don't have a problem with the way you do it though.

Rte30:
I only added EliRd to Rte20 as a shaping point.
MB1 recentered, also in MB1 & TCHMai.

Rte37:
WattSt_N -> ChaAve

We might add a branch for the southern route b/n Rt42 and Rt30?

That's not an alternate/branch/child route though, just half of an unusual couplet/split alignment. That's a can of worms I don't want to go near; don't wanna set that precedent.
OTOH, anyone wanna talk me into removing the Rte42_N, LevSt_W & (WattSt_N / ChaAve) points, and just cutting from one corner of the couplet to the other?

Rte42:
If I remove the above points from Rte37, then TalAve & Rte37_E may be better off as Rte37_E & JohAve respectively. Or even if I leave as-is? Discuss.
Rte125, I consider to be a "misbehaving parclo". It makes a nicer-looking graph view; I like it as is.
SutAve & TalAve: Misbehaving parclos again.
Talbot Ave is signed northbound. See above, though.
MB101: I went with just using the tier 4 routes in the labels in these cases.

TCH1 / Rte52 / Rte150 junction recentered.
Rte57: Maybe, but, eh... I kinda like the nice clean trace we get off to the west...

Rte85:
StuRd & MB1_E recentered, also in MB1 & TCHMai.
EmpSt is another misbehaving parclo.
ArlSt is a CHM-era TCH relic. I snipped out several other points along this stretch once upon a time, but left this one in. It eventually leads up to that long bridge over the wide spot in the rail yard, sure, but otherwise doesn't look like a very major street. Fairly close to MB1_E. Not in use. Just remove it?

Rte90:
MB190 is a controlled-access expressway, so it seemed more appropriate to include all its access points, since there are relatively few. Zoom in close enough and you'll see that Oak Point Hwy doesn't actually connect directly to Rte90.
AcaRd_E added.

Rte95:

Add corresponding wp for Rt96/Rt105 junction

Unsure what you mean here. 96 & 105 are concurrent on Grant Ave from William Clement Pkwy to Shaftesbury Blvd. 95 intersects 105 alone W of the overlap, and 96 alone N of it.

Rte105: CamSt was added to Rte95 for shaping/clarity, even though not strictly needed to keep within tolerance. On Rte105, the Rte80 point is close enough for this.
Rte115: Same deal with TacAve on Rte57. This would be awful close to MB1.

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

[michih]

Rte37:
OTOH, anyone wanna talk me into removing the Rte42_N, LevSt_W & (WattSt_N / ChaAve) points, and just cutting from one corner of the couplet to the other?

Rte42:
If I remove the above points from Rte37, then TalAve & Rte37_E may be better off as Rte37_E & JohAve respectively. Or even if I leave as-is? Discuss.

I tend to leaving Rte37 as-is but removing the wps might also be fine to me.....

ArlSt is a CHM-era TCH relic. I snipped out several other points along this stretch once upon a time, but left this one in. It eventually leads up to that long bridge over the wide spot in the rail yard, sure, but otherwise doesn't look like a very major street. Fairly close to MB1_E. Not in use. Just remove it?

yep.

Rte95:

Add corresponding wp for Rt96/Rt105 junction

Unsure what you mean here. 96 & 105 are concurrent on Grant Ave from William Clement Pkwy to Shaftesbury Blvd. 95 intersects 105 alone W of the overlap, and 96 alone N of it.

Add a wp @ http://www.openstreetmap.org/?lat=49.867109&lon=-97.229559


btw: Rte135 concurrency to TCHMai,MB1 is now broken. Sync Rte30 wp.

[yakra]

ArlSt removed from TCH/1/85.
ShaBlvd added to MB95.
Rte135@Rte30 resynced.
https://github.com/TravelMapping/HighwayData/pull/3137

Rte37:
OTOH, anyone wanna talk me into removing the Rte42_N, LevSt_W & (WattSt_N / ChaAve) points, and just cutting from one corner of the couplet to the other?

I tend to leaving Rte37 as-is but removing the wps might also be fine to me.....

Still toying with the idea; haven't made a decision yet.
If I add a shaping point hereish, I can fit both westbound & eastbound within the tolerance lines.
Though one could say that's less appropriate than just cutting straight across...

Rte42:
If I remove the above points from Rte37, then TalAve & Rte37_E may be better off as Rte37_E & JohAve respectively. Or even if I leave as-is? Discuss.

Or I could call them Rte37_A, Rte37_B, Rte37_C...
'C', Johnson Ave, won't be signed for Rte 37 *from* Rte42 though.
Opinions?

New business: I'm starting to reconsider my handling of Rte57 @ Rte52...
Link from the OP, and what was there at the time it was posted. That sign was gone by July 2017. So now we have a clearer case for WB 57 via Pioneer Ave. This agrees with the shapefiles, and is the assumption behind the current layout in the HB. This much is good at least.

Eastbound, if I go by the "follow the signage the thru traveler sees" rule of thumb (see Watertown NY), we'd go straight on Portage across Rte52 and then find  this. The left turn from Westbrook St to William Stephenson Way isn't signed, but I don't think this is a deal-breaker: Westbrook ends, and William Stephenson is one-way, so there's only one option here.

I could just cut the diagonal across the couplet as per SOP. Keep Rte52_N, renaming to Rte52, and remove Rte52_S.
It's a bit like VT30 and VT125: we have a triangle with one through route (VT30/Rte52) and another route on a couplet, where only one direction multiplexes (VT125/Rte57).
In that case, VT30 has AcaSt, not a label referencing VT125, because VT125 enters here on a one-way, and there's no signage for VT125 leaving the concurrency here. (More on this below...)
Conversely, Going by the signage along Rte52, Rte52 could keep its existing labels. There's Rte57 signage at both points.

Getting back to Rte42's labels...
Rte42 can be our VT30 thru route, and Rte37 can be our VT125 half-multiplex. ...Okay, double half multiplexes in this case.
Following the "go by what's signed leaving the multiplex from the thru route", that'd yield Rte37_E, Rte37_W, and JohAve for our point labels.

[michih]

Or I could call them Rte37_A, Rte37_B, Rte37_C...

I generally dislike _A, _B, _C

[yakra]

I generally dislike _A, _B, _C

I was editing my previous post while this was posted. My latest thinking is to avoid the _A, _B, _C in this case.

[michih]

@yakra, I feel a little bit bad while writing this, since you work so hard on backend stuff but....
Do you see any chance to solve the last remaining issues so that we can activate the system "soon"? I mean, if there is any question to me, the chance is getting more and more smaller that I can remember what I thought when peer-reviewing the system in September...

Similar situation for Manitoba Provincial Roads.

[yakra]

Naah, it's a fair cop. This system's been, save a few tweaks, essentially ready to go for months and I've just let it sit.
Pretty much just procrastinating on making a decision I'd already decided on (the Rte37 thing).

I mean, if there is any question to me, the chance is getting more and more smaller that I can remember what I thought when peer-reviewing the system in September...

No questions as I see it; you'd left off at

I tend to leaving Rte37 as-is but removing the wps might also be fine to me.....

(emphasizing the bit that agrees with my own opinion )
...so we were just waiting for me to make the last few tweaks.

In other news...

what was there at the time it was posted. That sign was gone by July 2017.

How did it not register with me that that's a sign for 85, not 57?

https://github.com/TravelMapping/HighwayData/pull/3437
Rte37:
Points removed. Cutting across the diagonal of the couplet.
Rte42_S -> Rte42

Rte42:
Rte37_E -> JohAve
TalAve -> Rte37_E

Rte57:
Rte52_S removed. Cutting across the diagonal of the couplet.
Rte52_N -> Rte52

This should make it ready to go active TMK.