The Wazeo is passive on the right time to make changes to old intersection styling such as micro-doglegs and virtual stub segments. I recommend we update the Turn instruction override page to be more direct.
We have recently removed much of the mention of old styling from the Wazeo. The only place I could find where some direction on updating old intersection styling is on the TIO page linked above. If there are other places that should have this directive, please add it to the discussion. The language in the “important” box should be changed as follows:
What is the sense of urgency to mandate that the old design “must” be removed?
Some of the old configurations are complex, have been in place successfully for years, and would not be trivial to port over to newer techniques and/or the newer techniques introduce new tradeoffs of their own. Especially when the needed edit to the junction is minor, it seems heavy-handed to say the new edit cannot be made without undertaking a simultaneous modernization of the entire junction.
Example: if making a change along a stretch of road (e.g., alt-city addition), would the editor be required to revamp every junction touched along the way?
There is no need for extremism on either side here. These things should be fixed as we come across them. They do not need to be made a priority. You don’t have to replace mDL with TIO just because you happen to be there working on road names, but if you’re in the area you might as well.
And if you’re working geometry anyway then you’d darn well better, as common sense would dictate. Just use your head. The guidance should reflect this.
The current language is indeed too weak and noncommittal, but the proposal is too demanding. It does make sense to do it when you’re in the area, but no one should be faulted for not doing so.
As I remember, after granting us TIOs, there was a meetup where staff told us to ‘clean up your [poop]’, referring to the hacks such as mDL, stubs, or other mechanisms we had been using. Therefore, I support the idea of cleaning up these kinds of items as they are encountered. I also agree that there is no need to search these kinds of configurations out, as long as they are still functioning as intended.
We could probably create similar language for the bow-tie and other hacky interchanges used p/t the Junction Box controls, but that’s for another thread.
I like Sketch’s proposal. It says the job must be done, but it doesn’t say every brand-new editor who is just fixing up a misspelled name needs to undertake reworking a complicated intersection.
Taken out of context, that quote from staff sounds rude. Before we had TIO, these hacks were required to make the map work for us.
Legacy workarounds that still work fine and do no harm are not poop and were never poop. Whatever handsomely-paid employee used this kind of language in front of a room full of volunteers is out to lunch.
I completely agree that if a legacy construction is under the knife for other reasons, by all means editors should be encouraged to bring it up to current standards! And I support any guidance that says so.
But a mandatory requirement that editors spend their time seeking out, busting open, and redoing legacy constructions that are working just fine – don’t we have better things to do? Is that really what we volunteer our time for? Does any of us wake up in the morning saying “OH yeah, I’m gonna fix a pile of things that ain’t broke today! And if I’m lucky and do everything right, it will have no effect on the driver experience whatsoever!”
(EDIT: I recognize the OP proposed mandatory replacement of legacy constructions only when editing them for other reasons. I still disagree that guidance should demand mandatory replacement if an existing construction works fine. But to clarify, my strong tone above resulted more from the report of Waze staff “telling us off” about our “poop” – “poop” they left us no choice but to use to work around their oversights and bugs. :evil:)
I think this wording is perfectly acceptable. In the SER if we are working the area especially the specific segments that contain the mDl, our guidance has been update to a TIO. There is no seek and destroy mission however at our meetup 2 years ago it was specifically stated by waze staff (Chen) that they did not like the mDl hacks (in fact IIRC at the NA meetup she stated it makes her cry) and the TIO was developed for us and should be utilized instead.
:roll: :roll: :roll: Before you get your britches in a bunch, the context of the quote was that, in recognition of the fact that we have had to resort to map hacks to make the app work properly, the WME dev team intended to implement features (such as TIO) that would make such hacks obsolete.
In other words, recognition that they had failed us in this regard, and were doing something to make it better.
I get it. As voludu2 said, it doesn’t sound great out of context. That’s why context matters. It is possible to acknowledge that without pretending you know everything and imparting ill will on the part of people who have none.
Did Staff give a reason for phasing out mDL’s and the like? Is it for display reasons? Is it to help simplify the map? Knowing why it’s important would give the page update more validity beyond “because we told you to do it.”
Because they created the TIO (that we asked for) that gives more control than MDLs. No need to cause the car on the app map to do a sudden jerk to the right and then straighten out.
I did some testing recently and found that the way the app looks and the way the car icon acts matches any TIO on the junction.
If the junction has a mDL and the TIO is “keep”, the junction appears as a smooth curve on the app map and turn instructions do the same thing. And the car icon follows that smooth line.
Admittedly, mDL were smoothed by the app display and never appeared anyway so it may have nothing to do with the TIO.
No one on staff “told us to do” anything. mDLs were never anything more than a hack we created because we don’t have TIO. Now that we have TIO, we don’t need the hack. The community is saying this. I am saying this.
Native solutions are always better than hacks (as long as you can achieve the same result) because they usually don’t come with the same unintended consequences. mDL are really, really, really easy to unwittingly mess up when adjusting geometry on connecting roads. TIO are not.
How mDLs do or don’t work in practice is frankly irrelevant because it is a deprecated solution. There is simply no reason whatsoever not to replace those we come across when we come across them (per the proposal we had all come to pretty much agree on in this thread just a few posts ago).
I think that goes against the general trend of this thread:
That message tells editors to be unnecessarily conservative when editing intersections that use old hacks and generally muddies the page’s guidance. Not to add yet another proposal, but would it be too extreme to just remove the whole mbox since there’s no strong message that we need to convey (always/never/check with leadership)?
I’m hoping to provide guidance on how we want editors to edit so they don’t need to check in with leadership. It also provides black and white rules for editing style that we can use when we are reviewing editors for advancement.
How does that tell editors to be unnecessarily conservative when editing intersections that use old hacks? It matches the proposed wording, stating that there is no reason to replace them unless you are already editing the intersection that uses the old hack.
Personally, I don’t see a need to add the “so the intersection is immune to changes in segment geometry in the future” part. That is only a part of the explanation behind why TIOs exists.
Ultimately they were created to replace micro-doglegs and should be used instead of them, that is what they are for. One should never create a new micro-dogleg, so why leave old ones.
The only thing the guidance is trying to ensure is that no one starts a seek-and-destroy mission or mapraid type deal to get rid of them all. They will get fixed over time.
Sorry for the ambiguity. That comment was in reference to XKSpeed’s proposed change. I should’ve directly quoted sketch’s proposal to show the contrast so I’ll do so now.
To me this says that it’s not a priority but it might be a good idea to update to TIO if you see the opportunity. I’m not as concerned as some that editors may go on an mDL replacing spree if we don’t tell them not to, but I’m fine with this language.
I don’t like that this explicitly tells editors to NOT replace mDLs as a primary-cause edit. This is the type of guidance I would give a new editor about something like adjusting slightly misaligned segments and other edits that don’t really improve the map. Removing an mDL, on the other hand, means that the next editor can’t accidentally break it so why not do it when you find one?