https://www.waze.com/wiki/USA/api.php?action=feedcontributions&user=Bill473&feedformat=atomWazeopedia - User contributions [en]2024-03-28T22:54:14ZUser contributionsMediaWiki 1.40.2https://www.waze.com/wiki/USA/index.php?title=Indiana/AM/Editor/Area2&diff=160497Indiana/AM/Editor/Area22017-09-18T12:14:45Z<p>Bill473: */Other Area editor table update*/</p>
<hr />
<div><!---------------------- DO NOT MODIFY THIS TOP CODE ------------------------------<br />
------------------------ SCROLL DOWN FOR INSTRUCTIONS -----------------------------><noinclude><!--Keep hard coded due to unique page address--><div class="center"><span class="noprint plainlinks purgelink" style="{{Road/style}}background-color:#93c4d3">[{{FULLURL:{{#titleparts:{{PAGENAME}}|-3}}|action=purge}}#Other_Area_Editors <span title="Return to the Other Area Editor table">&nbsp;Press here to return to the Other Area Editors table to see your changes&nbsp;</span>]</span></div></noinclude><includeonly><!--<br />
-------------------------------------------------------------------------------------<br />
-- Editors: To add yourself to this Other Editor Area table, copy and paste the<br />
-- following template into the space below with the other {{AM/Editor|...}}<br />
-- templates. Add yourself into rank order (higher at top)then alphabetical order<br />
-- by user name (A-Z)<br />
-------------------------------------------------------------------------------------<br />
{{AM/Editor|YOUR_USER_NAME|YOUR_RANK#|YOUR_AREA|ANY_COMMENT}}<br />
-------------------------------------------------------------------------------------<br />
-- then in the Summary field enter "Added YOUR_USER_NAME" and press "Save page"<br />
-------------------------------------------------------------------------------------<br />
---------------------- DO NOT MODIFY CONTENT ABOVE THE LINE -------------------------<br />
--------------------------------------------------------------------------------->|-<br />
{{AM/Editor|RonRover|5|SE Indiana|LAM SW Ohio}}<br />
{{AM/Editor|Bill473|5|East Central Indiana/West Central Ohio|LAM NW Ohio}}<br />
{{AM/Editor|Aqualung812|3|Columbus, Indiana|}}<br />
{{AM/Editor|MrVanMeter|2|Kokomo, Indiana, Howard County|}}<br />
{{AM/Editor|ScottG76|2|Indianapolis, Indiana|}}<br />
{{AM/Editor|NoWareMan9|1|NE Indiana, Fort Wayne, Allen County|}}<br />
<!-----------------------------------------------------------------------------------<br />
---------------------- DO NOT MODIFY CONTENT BELOW THE LINE -------------------------<br />
-------------------------------------------------------------------------------------<br />
-------------------------------------------------------------------------------------<br />
--></includeonly></div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=159158User:Bill4732017-07-16T13:37:43Z<p>Bill473: </p>
<hr />
<div>Bill473 is an editor living in Richmond, Indiana. He mainly drives in east central Indiana and west central Ohio but does make several long-distance drives every year.<br />
<br />
He was appointed co-Large Area Manager for SW Ohio in January 2016. In October 2016, he agreed to transfer to NW Ohio LAM.<br />
<br />
'''Notes:'''<br />
(What follows are notes on methods and guidance that isn't part of the official Wiki, but I thought this would be a convenient place to record things I might forget.)<br />
<br />
'''How to fix routing issues:'''<br />
<br />
Type 1 problem - Location of address in the app search is not correct.<br />
1. Check this address in Google Maps. If it is wrong there, that is most likely the reason for Waze to have the wrong location. I think fixing it in GM is best since it helps both GM and Waze users.<br />
<br />
Waze made a change for routing to RPPs that would go to the nearest matching street name, not the nearest segment. This "broke" a number of fixes using RPPs (and I don't see any reason for them to have done it.) They reverted for PLRs first. Finally, April 2017: <br />
<br />
<span dir="ltr">'''Residential Place Point Navigation Update''' - The "match street name" issue was just reverted in NA, should be live now.</span><br />
<br />
<span dir="ltr">i.e. - original RPP routing should be restored</span><br />
<br />
<br />
'''Policy question''': If the 3 BGS leading to an exit have two control cities and the first 2 signs have them in one order and the final sign has them reversed, how should the exit be labeled? <br />
What ever the final sign does<br />
TTS is to match final sign<br />
<br />
(Answer from Travis - OhioStMusicMan 11/28/16)<br />
<br />
'''Wazers Near You'''<br />
From TerryPurdue, 1/2017:<br />
He has no Near You Now (NYN) polygon where he starts his drive. NYNs are only drawn around certain areas across the globe. Many areas are covered but not all.<br />
<br />
Staff says: Unfortunately we can't change the shape of the NYN polygons, the reason is that these metro polygons are used for all kinds of advertising, statistics, and data collection.<br />
<br />
The NYN feature is just tagging along, the polygons were never meant for it.<br />
<br />
And Terry checked:<br />
Can confirm there is a NYN polygon in Ohio due east of Richmond that ends hard at the IN/OH border.<br />
You'll see the feature work in both Greenfield and New Castle, but not on the stretch of I-70 between them.<br />
<br />
And Terry also added: Talking with other Champs, we were thinking it'd be good if you're outside the polygon if the app would fall back to a "radius sweep" of N km so you didn't feel so alone.<br />
<br />
[https://waze.uservoice.com/forums/59223-waze-suggestion-box/suggestions/17753275-make-wazers-near-you-work-everywhere I created a suggestion]<br />
<br />
I need to transition all this to Wazeopedia, but my link takes me here so I'll do that some other day.<br />
<br />
Cases where BDP seems to be working incorrectly:<br />
<br />
<br />
https://www.waze.com/livemap?lon=-84.0685&lat=40.7724&zoom=15&from_lat=40.80436&from_lon=-84.02009&to_lat=40.7724&to_lon=-84.0685&at_req=0&at_text=Now<br />
<br />
<br />
UR says they were directed off the Bluelick Rd exit and back on. Nothing on the map to explain this. December 17, 2016 11:23 Nothing in the UR to support or contradict that assertion. No traffic issues at the time. User reports 75 mph driving here.<br />
<br />
Waze3rdParty" gas stations popping up in places that clearly aren't gas stations.<br />
JustinS83 says (1/9/17) "send them to SMs".<br />
<br />
'''What you can tell from the search results in the app'''<br />
Put Waze in debug mode and it should fill in the bubbles with a dark blue for Waze results.<br />
search code 2##2 (xanderb 1/10/17)<br />
<br />
'''Toolbox Notes''' I noticed today (1/12/17) that there were "Select Segments" (Green) and "Select Places" (purple) options between "Keyboard Shortcuts Editor" and "Measurement Tool". Didn't see "Places" CHrome. Saw both in FF. (Toolbox update?)<br />
This gives a grid with information about segments or places. Can't copy it (at least I don't know how) but can sort columns. One use is sort on state and use it to fill in missing ones.<br />
<br />
'''Bad Ad Pin Correction'''<br />
(This may primarily be useful for incorrect locations.)<br />
From RoadTechie:<br />
Normally when we see a bad ad pin we can edit the point place within WME and staff will fix it in a few days. Please continue to do so whenever you see a bad ad-locked point place within WME. Here as of late there have also been reports of bad ad pins visable from the client but there is not an ad-locked point place within WME. If you run across one of these please send an email to one of the SMs with the following information. Email is preferred because a screenshot is required.<br />
<br />
[https://www.waze.com/forum/viewtopic.php?f=631&t=212731 Bad Ad Pin Corrections]<br />
<br />
When I sent my first one in, Todd replied:<br />
btw, I adjusted the final destination before I sent it to Terry with a zoom 10 centered on the point place.<br />
the lat lon of that pl determines exactly where the new ad pin will go [and not the location of the point place.]<br />
<br />
TerryPurdue is an OH state manager: TerryPurdue.Waze@gmail.com<br />
Todd-roadtechie is an IN state manager: roadtechie79@gmail.com<br />
<br />
<br />
'''Ignore Traffic selection on Road Closures'''<br />
(Need to clean this up. Raw comments in GHO from TerryPurdue, 1/2017)<br />
Can we tell if that happens? (I'm just curious how things work. If cleared by traffic, does the closure still show in WME and LiveMap? Should be gone in the app, right?)<br />
The closure will be in place, but it will retest traffic every 15 minutes<br />
If it sees sufficient traffic compared to "normal" it will roll back<br />
It will disappear from livemap and app during that 15 minute window, until next traffic test<br />
That is the clearest explanation anyone has ever been able to give on the "ignore traffic" check box. Thanks<br />
Thats more then I knew about it<br />
So a closure would be re-enabled in the app if not sufficient traffic during a 15 minute interval? (And, agree, best information I've heard on how this works.)<br />
Correct. There's a brand-new test every 15 minutes (until closure hits its expire time).<br />
<br />
That 15 minute test has no visibility to historical tests. IT does a snapshot test in time and makes a call on "closure on" or "closure rolled back" for the subsequent 15 minutes<br />
Which is why we try to remove closures when we know traffic is flowing freely.<br />
<br />
If we don't, due to traffic test, the closure can warp in and warp out unpredictably until the closure expire time.<br />
<br />
Causes URs that are impossible to reproduce and infuriates drivers.<br />
The natural assumption is that on the first traffic test where sufficient traffic is seen, the closure deletes itself.<br />
<br />
Absolutely untrue.<br />
<br />
'''In defense of SLURs'''<br />
When speed limits became visible in the app, there was also an ability to report errors in those limits. The volume of these Speed Limit URs created a lot of unhappiness in the editor community. On Sept 11 2016 the display of these SLURs was removed from WME. App users can still report and have no idea why their reports are not being acted upon. This situation seems horrible. There has been a suggestion that these URs might be made visible in a separate layer, as URs and MPs are now. But the possible time for this to be done is not soon.<br />
<br />
On 2/9/17, MapSir announced in the forum that all SLURs over 2 weeks old had been discarded and they were working on way of presenting the new SLURs. 2/12/17 MapSir said "support for changing/temporary speed limits is planned for the not so near future."<br />
<br />
2/19/17 MapSir said "We're almost ready to launch the new SLUR's.". (These are aggregates of reports on segments. Others call these super-SLURs.) There was a request the new SLURs show in beta first, but that might not be possible because URs go directly to production.<br />
<br />
'''Difficult turns'''<br />
Navigation option in app for "Reduce difficult intersections" in v4.18.0.1 (Jan 2017). The word is that the penalty is currently 7 minutes.<br />
<br />
'''Personal clean-up projects'''<br />
Since we are all volunteers, we get to work on items that interest us. Here are a list of "pet peeve" projects I'm working on. The list is mainly to remind me.<br />
<br />
* Make sure private residences are listed like that.<br />
If you search in the app, you won't get residences properly classified. Here are some search terms that will turn up incorrectly listed residences. House, home, residence, other, Mom, Dad, Aunt, Uncle, job. Need to make sure for "relations" that they aren't really businesses. Select the option menu, "report a problem" and then "residential place". This puts a flag on the place pretty quickly. You get a message in the app when an editor deals with it. I haven't tested what happens if you do this multiple times. I'm a little worried this can be perceived as spamming.<br />
<br />
* Have at least "state" on all places.<br />
It seems the basemap impor of places don't (always?) have state. The easiest way to find these (since Wide Area Lens won't find these yet) is to use the Toolbox "Select Places" option and sort on state. You will get some even at zoom=0 so it when I'm editing in an area, I should just take a quick look to see if there are addresses I can at least have state on. An Indiana SM(?) is also working on this.<br />
<br />
* Get I-80 turnpike in NE Indiana correctly listed as "not toll"<br />
Toll road attribute should only be when there is a collection point on the segment. Much of I-80 is incorrectly listed. Here's a link to one place. (This won't be a continuing issue. If no Indiana editor addresses this, I should chip away at it with GHO requests for change. All of it is OOA.<br />
[https://www.waze.com/editor/?env=usa&lon=-86.48300&lat=41.74433&zoom=2&mode=0 Turn on Highlight:Toll Road to see misclassified]<br />
Sample posting: <br />
<br />
R5+ - Please remove Toll Road attribute. There are no toll collection points on these segments. (I-80 in NE Indiana. OOA for me) xxx<br />
<br />
Group by direction (since if names don't match, can't change attribute.) Work east to west from Ohio state line.<br />
<br />
Note: I-44 in Oklahoma is also handled incorrectly (I think) in places.<br />
<br />
* Add parking lots<br />
When Waze started showing parking lots in the app, they wanted all parking lots to be mapped. When I'm editing, if I see an unmapped parking lot, I'll normally add it. If there are a lot of missing lots, I won't necessarily try to get them all. That wasn't why I was in the area. Also, any time I drive somewhere and the nearest parking lot shown to the destination is not really the nearest, I'll add at least the nearest.<br />
<br />
'''Where to find who the state managers are'''<br />
You can go to the Wiki for the state and find them, but TerryPurdue says this will always be current<br />
[https://wiki.waze.com/wiki/State_Manager/USA#State_Manager_list State Managers]<br />
<br />
'''Searching network'''<br />
<br />
I have been told that the server disconnects the client session after 10 minutes of no communication. However, the client (app) continues to try to connect with the old session number, which is why after a long period of no cellphone coverage, the app will never reconnect even though stopping and starting the app will connect immediately.<br />
<br />
'''Source for "everything" in a certain category'''<br />
<br />
(KY uses this to do projects to update "everything" of certain categories)<br />
This site gives us a way to build those lists for schools (among other things), without having to dig through school/district/county websites.<br />
It's actually kind of interesting all the stuff they've mapped (in a map-nerd kind of way, of course). If you're interested:<br />
https://hifld-dhs-gii.opendata.arcgis.com/<br />
<br />
'''Indiana County Road naming'''<br />
From Enfcer74-Barry (4/2017)<br />
The most recent Discussion with the other SM;s is, For this:<br />
{N/S/E/W} Co Rd xxxx {N/S/E/W}<br />
<br />
Primary - when general county-wide lgs omits leading cardinal):<br />
CR-xxxx {N/S/E/W} (trailing cardinal required if present)<br />
<br />
Alt - if current name or county-GIS reference contains leading cardinal:<br />
{N/S/E/W} CR-xxxx {N/S/E/W}<br />
<br />
And I confirmed:<br />
So just to be sure..."E Co Rd 350 N" currently on the map with a lgs of "350 N" should be primary "CR-350 N" with an alternate of "E CR-350 N"?<br />
<br />
Currently in Waze as "W 1000 S" with alts of " W Co Rd 1000 N" and " W Co Rd 1000 S" with lgs of "1000 N" (It's on the county line)...<br />
CR-1000 N for primary, W CR-1000 N and W CR-1000 S as alts? (Barry agreed)<br />
<br />
Overlocks<br />
<br />
This is the argument I made in the Ohio GHO, 7/16/17. "Unfortunately", the issue was decided to be a previous Freeway corrected to a MH but L5 not changed. So the underlying issue wasn't addressed. Saving it here for the next time, since I know there are some segments in NW Ohio that were overlocked for the reason I state below.<br />
<br />
<span dir="ltr">There<br />
<nowiki> </nowiki>is a 15 mile stretch of SR-15, a MH, near Findlay OH overlocked at L5. <br />
<nowiki> </nowiki>In the past I have been told some of these examples were because an R3 <br />
made erroneous updates to MHs. I'd like to suggest a few things: (1) <br />
That such overlocks have map comments at the begin and end of the <br />
overlock so we know it was an intentional decision. (2) That such <br />
overlocks be temporary. Once the R3 is properly educated, do we need to<br />
<nowiki> </nowiki>continue the overlock? (3) That such overlocks be +1 instead of L5. <br />
If an R3 makes a mistake, does that mean R4s shouldn't be allowed to <br />
edit? Here's the area in question, but this applies to any overlock in <br />
Ohio. <nowiki>https://www.waze.com/editor/?env=usa&lon=-83.61329&lat=40.97897&zoom=2</nowiki></span></div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=153061User:Bill4732017-04-03T16:29:48Z<p>Bill473: Update for Waze routing handling of RPPs</p>
<hr />
<div>Bill473 is an editor living in Richmond, Indiana. He mainly drives in east central Indiana and west central Ohio but does make several long-distance drives every year.<br />
<br />
He was appointed co-Large Area Manager for SW Ohio in January 2016. In October 2016, he agreed to transfer to NW Ohio LAM.<br />
<br />
'''Notes:'''<br />
(What follows are notes on methods and guidance that isn't part of the official Wiki, but I thought this would be a convenient place to record things I might forget.)<br />
<br />
'''How to fix routing issues:'''<br />
<br />
Type 1 problem - Location of address in the app search is not correct.<br />
1. Check this address in Google Maps. If it is wrong there, that is most likely the reason for Waze to have the wrong location. I think fixing it in GM is best since it helps both GM and Waze users.<br />
<br />
Waze made a change for routing to RPPs that would go to the nearest matching street name, not the nearest segment. This "broke" a number of fixes using RPPs (and I don't see any reason for them to have done it.) They reverted for PLRs first. Finally, April 2017: <br />
<br />
<span dir="ltr">'''Residential Place Point Navigation Update''' - The "match street name" issue was just reverted in NA, should be live now.</span><br />
<br />
<span dir="ltr">i.e. - original RPP routing should be restored</span><br />
<br />
<br />
'''Policy question''': If the 3 BGS leading to an exit have two control cities and the first 2 signs have them in one order and the final sign has them reversed, how should the exit be labeled? <br />
What ever the final sign does<br />
TTS is to match final sign<br />
<br />
(Answer from Travis - OhioStMusicMan 11/28/16)<br />
<br />
'''Wazers Near You'''<br />
From TerryPurdue, 1/2017:<br />
He has no Near You Now (NYN) polygon where he starts his drive. NYNs are only drawn around certain areas across the globe. Many areas are covered but not all.<br />
<br />
Staff says: Unfortunately we can't change the shape of the NYN polygons, the reason is that these metro polygons are used for all kinds of advertising, statistics, and data collection.<br />
<br />
The NYN feature is just tagging along, the polygons were never meant for it.<br />
<br />
And Terry checked:<br />
Can confirm there is a NYN polygon in Ohio due east of Richmond that ends hard at the IN/OH border.<br />
You'll see the feature work in both Greenfield and New Castle, but not on the stretch of I-70 between them.<br />
<br />
And Terry also added: Talking with other Champs, we were thinking it'd be good if you're outside the polygon if the app would fall back to a "radius sweep" of N km so you didn't feel so alone.<br />
<br />
[https://waze.uservoice.com/forums/59223-waze-suggestion-box/suggestions/17753275-make-wazers-near-you-work-everywhere I created a suggestion]<br />
<br />
I need to transition all this to Wazeopedia, but my link takes me here so I'll do that some other day.<br />
<br />
Cases where BDP seems to be working incorrectly:<br />
<br />
<br />
https://www.waze.com/livemap?lon=-84.0685&lat=40.7724&zoom=15&from_lat=40.80436&from_lon=-84.02009&to_lat=40.7724&to_lon=-84.0685&at_req=0&at_text=Now<br />
<br />
<br />
UR says they were directed off the Bluelick Rd exit and back on. Nothing on the map to explain this. December 17, 2016 11:23 Nothing in the UR to support or contradict that assertion. No traffic issues at the time. User reports 75 mph driving here.<br />
<br />
Waze3rdParty" gas stations popping up in places that clearly aren't gas stations.<br />
JustinS83 says (1/9/17) "send them to SMs".<br />
<br />
'''What you can tell from the search results in the app'''<br />
Put Waze in debug mode and it should fill in the bubbles with a dark blue for Waze results.<br />
search code 2##2 (xanderb 1/10/17)<br />
<br />
'''Toolbox Notes''' I noticed today (1/12/17) that there were "Select Segments" (Green) and "Select Places" (purple) options between "Keyboard Shortcuts Editor" and "Measurement Tool". Didn't see "Places" CHrome. Saw both in FF. (Toolbox update?)<br />
This gives a grid with information about segments or places. Can't copy it (at least I don't know how) but can sort columns. One use is sort on state and use it to fill in missing ones.<br />
<br />
'''Bad Ad Pin Correction'''<br />
(This may primarily be useful for incorrect locations.)<br />
From RoadTechie:<br />
Normally when we see a bad ad pin we can edit the point place within WME and staff will fix it in a few days. Please continue to do so whenever you see a bad ad-locked point place within WME. Here as of late there have also been reports of bad ad pins visable from the client but there is not an ad-locked point place within WME. If you run across one of these please send an email to one of the SMs with the following information. Email is preferred because a screenshot is required.<br />
<br />
[https://www.waze.com/forum/viewtopic.php?f=631&t=212731 Bad Ad Pin Corrections]<br />
<br />
When I sent my first one in, Todd replied:<br />
btw, I adjusted the final destination before I sent it to Terry with a zoom 10 centered on the point place.<br />
the lat lon of that pl determines exactly where the new ad pin will go [and not the location of the point place.]<br />
<br />
TerryPurdue is an OH state manager: TerryPurdue.Waze@gmail.com<br />
Todd-roadtechie is an IN state manager: roadtechie79@gmail.com<br />
<br />
<br />
'''Ignore Traffic selection on Road Closures'''<br />
(Need to clean this up. Raw comments in GHO from TerryPurdue, 1/2017)<br />
Can we tell if that happens? (I'm just curious how things work. If cleared by traffic, does the closure still show in WME and LiveMap? Should be gone in the app, right?)<br />
The closure will be in place, but it will retest traffic every 15 minutes<br />
If it sees sufficient traffic compared to "normal" it will roll back<br />
It will disappear from livemap and app during that 15 minute window, until next traffic test<br />
That is the clearest explanation anyone has ever been able to give on the "ignore traffic" check box. Thanks<br />
Thats more then I knew about it<br />
So a closure would be re-enabled in the app if not sufficient traffic during a 15 minute interval? (And, agree, best information I've heard on how this works.)<br />
Correct. There's a brand-new test every 15 minutes (until closure hits its expire time).<br />
<br />
That 15 minute test has no visibility to historical tests. IT does a snapshot test in time and makes a call on "closure on" or "closure rolled back" for the subsequent 15 minutes<br />
Which is why we try to remove closures when we know traffic is flowing freely.<br />
<br />
If we don't, due to traffic test, the closure can warp in and warp out unpredictably until the closure expire time.<br />
<br />
Causes URs that are impossible to reproduce and infuriates drivers.<br />
The natural assumption is that on the first traffic test where sufficient traffic is seen, the closure deletes itself.<br />
<br />
Absolutely untrue.<br />
<br />
'''In defense of SLURs'''<br />
When speed limits became visible in the app, there was also an ability to report errors in those limits. The volume of these Speed Limit URs created a lot of unhappiness in the editor community. On Sept 11 2016 the display of these SLURs was removed from WME. App users can still report and have no idea why their reports are not being acted upon. This situation seems horrible. There has been a suggestion that these URs might be made visible in a separate layer, as URs and MPs are now. But the possible time for this to be done is not soon.<br />
<br />
On 2/9/17, MapSir announced in the forum that all SLURs over 2 weeks old had been discarded and they were working on way of presenting the new SLURs. 2/12/17 MapSir said "support for changing/temporary speed limits is planned for the not so near future."<br />
<br />
2/19/17 MapSir said "We're almost ready to launch the new SLUR's.". (These are aggregates of reports on segments. Others call these super-SLURs.) There was a request the new SLURs show in beta first, but that might not be possible because URs go directly to production.<br />
<br />
'''Difficult turns'''<br />
Navigation option in app for "Reduce difficult intersections" in v4.18.0.1 (Jan 2017). The word is that the penalty is currently 7 minutes.<br />
<br />
'''Personal clean-up projects'''<br />
Since we are all volunteers, we get to work on items that interest us. Here are a list of "pet peeve" projects I'm working on. The list is mainly to remind me.<br />
<br />
* Make sure private residences are listed like that.<br />
If you search in the app, you won't get residences properly classified. Here are some search terms that will turn up incorrectly listed residences. House, home, residence, other, Mom, Dad, Aunt, Uncle, job. Need to make sure for "relations" that they aren't really businesses. Select the option menu, "report a problem" and then "residential place". This puts a flag on the place pretty quickly. You get a message in the app when an editor deals with it. I haven't tested what happens if you do this multiple times. I'm a little worried this can be perceived as spamming.<br />
<br />
* Have at least "state" on all places.<br />
It seems the basemap impor of places don't (always?) have state. The easiest way to find these (since Wide Area Lens won't find these yet) is to use the Toolbox "Select Places" option and sort on state. You will get some even at zoom=0 so it when I'm editing in an area, I should just take a quick look to see if there are addresses I can at least have state on. An Indiana SM(?) is also working on this.<br />
<br />
* Get I-80 turnpike in NE Indiana correctly listed as "not toll"<br />
Toll road attribute should only be when there is a collection point on the segment. Much of I-80 is incorrectly listed. Here's a link to one place. (This won't be a continuing issue. If no Indiana editor addresses this, I should chip away at it with GHO requests for change. All of it is OOA.<br />
[https://www.waze.com/editor/?env=usa&lon=-86.48300&lat=41.74433&zoom=2&mode=0 Turn on Highlight:Toll Road to see misclassified]<br />
Sample posting: <br />
<br />
R5+ - Please remove Toll Road attribute. There are no toll collection points on these segments. (I-80 in NE Indiana. OOA for me) xxx<br />
<br />
Group by direction (since if names don't match, can't change attribute.) Work east to west from Ohio state line.<br />
<br />
Note: I-44 in Oklahoma is also handled incorrectly (I think) in places.<br />
<br />
* Add parking lots<br />
When Waze started showing parking lots in the app, they wanted all parking lots to be mapped. When I'm editing, if I see an unmapped parking lot, I'll normally add it. If there are a lot of missing lots, I won't necessarily try to get them all. That wasn't why I was in the area. Also, any time I drive somewhere and the nearest parking lot shown to the destination is not really the nearest, I'll add at least the nearest.<br />
<br />
'''Where to find who the state managers are'''<br />
You can go to the Wiki for the state and find them, but TerryPurdue says this will always be current<br />
[https://wiki.waze.com/wiki/State_Manager/USA#State_Manager_list State Managers]<br />
<br />
'''Searching network'''<br />
<br />
I have been told that the server disconnects the client session after 10 minutes of no communication. However, the client (app) continues to try to connect with the old session number, which is why after a long period of no cellphone coverage, the app will never reconnect even though stopping and starting the app will connect immediately.<br />
<br />
'''Source for "everything" in a certain category'''<br />
<br />
(KY uses this to do projects to update "everything" of certain categories)<br />
This site gives us a way to build those lists for schools (among other things), without having to dig through school/district/county websites.<br />
It's actually kind of interesting all the stuff they've mapped (in a map-nerd kind of way, of course). If you're interested:<br />
https://hifld-dhs-gii.opendata.arcgis.com/<br />
<br />
'''Indiana County Road naming'''<br />
From Enfcer74-Barry (4/2017)<br />
The most recent Discussion with the other SM;s is, For this:<br />
{N/S/E/W} Co Rd xxxx {N/S/E/W}<br />
<br />
Primary - when general county-wide lgs omits leading cardinal):<br />
CR-xxxx {N/S/E/W} (trailing cardinal required if present)<br />
<br />
Alt - if current name or county-GIS reference contains leading cardinal:<br />
{N/S/E/W} CR-xxxx {N/S/E/W}<br />
<br />
And I confirmed:<br />
So just to be sure..."E Co Rd 350 N" currently on the map with a lgs of "350 N" should be primary "CR-350 N" with an alternate of "E CR-350 N"?<br />
<br />
Currently in Waze as "W 1000 S" with alts of " W Co Rd 1000 N" and " W Co Rd 1000 S" with lgs of "1000 N" (It's on the county line)...<br />
CR-1000 N for primary, W CR-1000 N and W CR-1000 S as alts? (Barry agreed)</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=153041User:Bill4732017-04-02T05:34:12Z<p>Bill473: </p>
<hr />
<div>Bill473 is an editor living in Richmond, Indiana. He mainly drives in east central Indiana and west central Ohio but does make several long-distance drives every year.<br />
<br />
He was appointed co-Large Area Manager for SW Ohio in January 2016. In October 2016, he agreed to transfer to NW Ohio LAM.<br />
<br />
'''Notes:'''<br />
(What follows are notes on methods and guidance that isn't part of the official Wiki, but I thought this would be a convenient place to record things I might forget.)<br />
<br />
'''How to fix routing issues:'''<br />
<br />
Type 1 problem - Location of address in the app search is not correct.<br />
1. Check this address in Google Maps. If it is wrong there, that is most likely the reason for Waze to have the wrong location. I think fixing it in GM is best since it helps both GM and Waze users.<br />
<br />
<br />
'''Policy question''': If the 3 BGS leading to an exit have two control cities and the first 2 signs have them in one order and the final sign has them reversed, how should the exit be labeled? <br />
What ever the final sign does<br />
TTS is to match final sign<br />
<br />
(Answer from Travis - OhioStMusicMan 11/28/16)<br />
<br />
'''Wazers Near You'''<br />
From TerryPurdue, 1/2017:<br />
He has no Near You Now (NYN) polygon where he starts his drive. NYNs are only drawn around certain areas across the globe. Many areas are covered but not all.<br />
<br />
Staff says: Unfortunately we can't change the shape of the NYN polygons, the reason is that these metro polygons are used for all kinds of advertising, statistics, and data collection.<br />
<br />
The NYN feature is just tagging along, the polygons were never meant for it.<br />
<br />
And Terry checked:<br />
Can confirm there is a NYN polygon in Ohio due east of Richmond that ends hard at the IN/OH border.<br />
You'll see the feature work in both Greenfield and New Castle, but not on the stretch of I-70 between them.<br />
<br />
And Terry also added: Talking with other Champs, we were thinking it'd be good if you're outside the polygon if the app would fall back to a "radius sweep" of N km so you didn't feel so alone.<br />
<br />
[https://waze.uservoice.com/forums/59223-waze-suggestion-box/suggestions/17753275-make-wazers-near-you-work-everywhere I created a suggestion]<br />
<br />
I need to transition all this to Wazeopedia, but my link takes me here so I'll do that some other day.<br />
<br />
Cases where BDP seems to be working incorrectly:<br />
<br />
<br />
https://www.waze.com/livemap?lon=-84.0685&lat=40.7724&zoom=15&from_lat=40.80436&from_lon=-84.02009&to_lat=40.7724&to_lon=-84.0685&at_req=0&at_text=Now<br />
<br />
<br />
UR says they were directed off the Bluelick Rd exit and back on. Nothing on the map to explain this. December 17, 2016 11:23 Nothing in the UR to support or contradict that assertion. No traffic issues at the time. User reports 75 mph driving here.<br />
<br />
Waze3rdParty" gas stations popping up in places that clearly aren't gas stations.<br />
JustinS83 says (1/9/17) "send them to SMs".<br />
<br />
'''What you can tell from the search results in the app'''<br />
Put Waze in debug mode and it should fill in the bubbles with a dark blue for Waze results.<br />
search code 2##2 (xanderb 1/10/17)<br />
<br />
'''Toolbox Notes''' I noticed today (1/12/17) that there were "Select Segments" (Green) and "Select Places" (purple) options between "Keyboard Shortcuts Editor" and "Measurement Tool". Didn't see "Places" CHrome. Saw both in FF. (Toolbox update?)<br />
This gives a grid with information about segments or places. Can't copy it (at least I don't know how) but can sort columns. One use is sort on state and use it to fill in missing ones.<br />
<br />
'''Bad Ad Pin Correction'''<br />
(This may primarily be useful for incorrect locations.)<br />
From RoadTechie:<br />
Normally when we see a bad ad pin we can edit the point place within WME and staff will fix it in a few days. Please continue to do so whenever you see a bad ad-locked point place within WME. Here as of late there have also been reports of bad ad pins visable from the client but there is not an ad-locked point place within WME. If you run across one of these please send an email to one of the SMs with the following information. Email is preferred because a screenshot is required.<br />
<br />
[https://www.waze.com/forum/viewtopic.php?f=631&t=212731 Bad Ad Pin Corrections]<br />
<br />
When I sent my first one in, Todd replied:<br />
btw, I adjusted the final destination before I sent it to Terry with a zoom 10 centered on the point place.<br />
the lat lon of that pl determines exactly where the new ad pin will go [and not the location of the point place.]<br />
<br />
TerryPurdue is an OH state manager: TerryPurdue.Waze@gmail.com<br />
Todd-roadtechie is an IN state manager: roadtechie79@gmail.com<br />
<br />
<br />
'''Ignore Traffic selection on Road Closures'''<br />
(Need to clean this up. Raw comments in GHO from TerryPurdue, 1/2017)<br />
Can we tell if that happens? (I'm just curious how things work. If cleared by traffic, does the closure still show in WME and LiveMap? Should be gone in the app, right?)<br />
The closure will be in place, but it will retest traffic every 15 minutes<br />
If it sees sufficient traffic compared to "normal" it will roll back<br />
It will disappear from livemap and app during that 15 minute window, until next traffic test<br />
That is the clearest explanation anyone has ever been able to give on the "ignore traffic" check box. Thanks<br />
Thats more then I knew about it<br />
So a closure would be re-enabled in the app if not sufficient traffic during a 15 minute interval? (And, agree, best information I've heard on how this works.)<br />
Correct. There's a brand-new test every 15 minutes (until closure hits its expire time).<br />
<br />
That 15 minute test has no visibility to historical tests. IT does a snapshot test in time and makes a call on "closure on" or "closure rolled back" for the subsequent 15 minutes<br />
Which is why we try to remove closures when we know traffic is flowing freely.<br />
<br />
If we don't, due to traffic test, the closure can warp in and warp out unpredictably until the closure expire time.<br />
<br />
Causes URs that are impossible to reproduce and infuriates drivers.<br />
The natural assumption is that on the first traffic test where sufficient traffic is seen, the closure deletes itself.<br />
<br />
Absolutely untrue.<br />
<br />
'''In defense of SLURs'''<br />
When speed limits became visible in the app, there was also an ability to report errors in those limits. The volume of these Speed Limit URs created a lot of unhappiness in the editor community. On Sept 11 2016 the display of these SLURs was removed from WME. App users can still report and have no idea why their reports are not being acted upon. This situation seems horrible. There has been a suggestion that these URs might be made visible in a separate layer, as URs and MPs are now. But the possible time for this to be done is not soon.<br />
<br />
On 2/9/17, MapSir announced in the forum that all SLURs over 2 weeks old had been discarded and they were working on way of presenting the new SLURs. 2/12/17 MapSir said "support for changing/temporary speed limits is planned for the not so near future."<br />
<br />
2/19/17 MapSir said "We're almost ready to launch the new SLUR's.". (These are aggregates of reports on segments. Others call these super-SLURs.) There was a request the new SLURs show in beta first, but that might not be possible because URs go directly to production.<br />
<br />
'''Difficult turns'''<br />
Navigation option in app for "Reduce difficult intersections" in v4.18.0.1 (Jan 2017). The word is that the penalty is currently 7 minutes.<br />
<br />
'''Personal clean-up projects'''<br />
Since we are all volunteers, we get to work on items that interest us. Here are a list of "pet peeve" projects I'm working on. The list is mainly to remind me.<br />
<br />
* Make sure private residences are listed like that.<br />
If you search in the app, you won't get residences properly classified. Here are some search terms that will turn up incorrectly listed residences. House, home, residence, other, Mom, Dad, Aunt, Uncle, job. Need to make sure for "relations" that they aren't really businesses. Select the option menu, "report a problem" and then "residential place". This puts a flag on the place pretty quickly. You get a message in the app when an editor deals with it. I haven't tested what happens if you do this multiple times. I'm a little worried this can be perceived as spamming.<br />
<br />
* Have at least "state" on all places.<br />
It seems the basemap impor of places don't (always?) have state. The easiest way to find these (since Wide Area Lens won't find these yet) is to use the Toolbox "Select Places" option and sort on state. You will get some even at zoom=0 so it when I'm editing in an area, I should just take a quick look to see if there are addresses I can at least have state on. An Indiana SM(?) is also working on this.<br />
<br />
* Get I-80 turnpike in NE Indiana correctly listed as "not toll"<br />
Toll road attribute should only be when there is a collection point on the segment. Much of I-80 is incorrectly listed. Here's a link to one place. (This won't be a continuing issue. If no Indiana editor addresses this, I should chip away at it with GHO requests for change. All of it is OOA.<br />
[https://www.waze.com/editor/?env=usa&lon=-86.48300&lat=41.74433&zoom=2&mode=0 Turn on Highlight:Toll Road to see misclassified]<br />
Sample posting: <br />
<br />
R5+ - Please remove Toll Road attribute. There are no toll collection points on these segments. (I-80 in NE Indiana. OOA for me) xxx<br />
<br />
Group by direction (since if names don't match, can't change attribute.) Work east to west from Ohio state line.<br />
<br />
Note: I-44 in Oklahoma is also handled incorrectly (I think) in places.<br />
<br />
* Add parking lots<br />
When Waze started showing parking lots in the app, they wanted all parking lots to be mapped. When I'm editing, if I see an unmapped parking lot, I'll normally add it. If there are a lot of missing lots, I won't necessarily try to get them all. That wasn't why I was in the area. Also, any time I drive somewhere and the nearest parking lot shown to the destination is not really the nearest, I'll add at least the nearest.<br />
<br />
'''Where to find who the state managers are'''<br />
You can go to the Wiki for the state and find them, but TerryPurdue says this will always be current<br />
[https://wiki.waze.com/wiki/State_Manager/USA#State_Manager_list State Managers]<br />
<br />
'''Searching network'''<br />
<br />
I have been told that the server disconnects the client session after 10 minutes of no communication. However, the client (app) continues to try to connect with the old session number, which is why after a long period of no cellphone coverage, the app will never reconnect even though stopping and starting the app will connect immediately.<br />
<br />
'''Source for "everything" in a certain category'''<br />
<br />
(KY uses this to do projects to update "everything" of certain categories)<br />
This site gives us a way to build those lists for schools (among other things), without having to dig through school/district/county websites.<br />
It's actually kind of interesting all the stuff they've mapped (in a map-nerd kind of way, of course). If you're interested:<br />
https://hifld-dhs-gii.opendata.arcgis.com/<br />
<br />
'''Indiana County Road naming'''<br />
From Enfcer74-Barry (4/2017)<br />
The most recent Discussion with the other SM;s is, For this:<br />
{N/S/E/W} Co Rd xxxx {N/S/E/W}<br />
<br />
Primary - when general county-wide lgs omits leading cardinal):<br />
CR-xxxx {N/S/E/W} (trailing cardinal required if present)<br />
<br />
Alt - if current name or county-GIS reference contains leading cardinal:<br />
{N/S/E/W} CR-xxxx {N/S/E/W}<br />
<br />
And I confirmed:<br />
So just to be sure..."E Co Rd 350 N" currently on the map with a lgs of "350 N" should be primary "CR-350 N" with an alternate of "E CR-350 N"?<br />
<br />
Currently in Waze as "W 1000 S" with alts of " W Co Rd 1000 N" and " W Co Rd 1000 S" with lgs of "1000 N" (It's on the county line)...<br />
CR-1000 N for primary, W CR-1000 N and W CR-1000 S as alts? (Barry agreed)</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=153040User:Bill4732017-04-02T04:56:00Z<p>Bill473: </p>
<hr />
<div>Bill473 is an editor living in Richmond, Indiana. He mainly drives in east central Indiana and west central Ohio but does make several long-distance drives every year.<br />
<br />
He was appointed co-Large Area Manager for SW Ohio in January 2016. In October 2016, he agreed to transfer to NW Ohio LAM.<br />
<br />
'''Notes:'''<br />
(What follows are notes on methods and guidance that isn't part of the official Wiki, but I thought this would be a convenient place to record things I might forget.)<br />
<br />
'''How to fix routing issues:'''<br />
<br />
Type 1 problem - Location of address in the app search is not correct.<br />
1. Check this address in Google Maps. If it is wrong there, that is most likely the reason for Waze to have the wrong location. I think fixing it in GM is best since it helps both GM and Waze users.<br />
<br />
<br />
'''Policy question''': If the 3 BGS leading to an exit have two control cities and the first 2 signs have them in one order and the final sign has them reversed, how should the exit be labeled? <br />
What ever the final sign does<br />
TTS is to match final sign<br />
<br />
(Answer from Travis - OhioStMusicMan 11/28/16)<br />
<br />
'''Wazers Near You'''<br />
From TerryPurdue, 1/2017:<br />
He has no Near You Now (NYN) polygon where he starts his drive. NYNs are only drawn around certain areas across the globe. Many areas are covered but not all.<br />
<br />
Staff says: Unfortunately we can't change the shape of the NYN polygons, the reason is that these metro polygons are used for all kinds of advertising, statistics, and data collection.<br />
<br />
The NYN feature is just tagging along, the polygons were never meant for it.<br />
<br />
And Terry checked:<br />
Can confirm there is a NYN polygon in Ohio due east of Richmond that ends hard at the IN/OH border.<br />
You'll see the feature work in both Greenfield and New Castle, but not on the stretch of I-70 between them.<br />
<br />
And Terry also added: Talking with other Champs, we were thinking it'd be good if you're outside the polygon if the app would fall back to a "radius sweep" of N km so you didn't feel so alone.<br />
<br />
[https://waze.uservoice.com/forums/59223-waze-suggestion-box/suggestions/17753275-make-wazers-near-you-work-everywhere I created a suggestion]<br />
<br />
I need to transition all this to Wazeopedia, but my link takes me here so I'll do that some other day.<br />
<br />
Cases where BDP seems to be working incorrectly:<br />
<br />
<br />
https://www.waze.com/livemap?lon=-84.0685&lat=40.7724&zoom=15&from_lat=40.80436&from_lon=-84.02009&to_lat=40.7724&to_lon=-84.0685&at_req=0&at_text=Now<br />
<br />
<br />
UR says they were directed off the Bluelick Rd exit and back on. Nothing on the map to explain this. December 17, 2016 11:23 Nothing in the UR to support or contradict that assertion. No traffic issues at the time. User reports 75 mph driving here.<br />
<br />
Waze3rdParty" gas stations popping up in places that clearly aren't gas stations.<br />
JustinS83 says (1/9/17) "send them to SMs".<br />
<br />
'''What you can tell from the search results in the app'''<br />
Put Waze in debug mode and it should fill in the bubbles with a dark blue for Waze results.<br />
search code 2##2 (xanderb 1/10/17)<br />
<br />
'''Toolbox Notes''' I noticed today (1/12/17) that there were "Select Segments" (Green) and "Select Places" (purple) options between "Keyboard Shortcuts Editor" and "Measurement Tool". Didn't see "Places" CHrome. Saw both in FF. (Toolbox update?)<br />
This gives a grid with information about segments or places. Can't copy it (at least I don't know how) but can sort columns. One use is sort on state and use it to fill in missing ones.<br />
<br />
'''Bad Ad Pin Correction'''<br />
(This may primarily be useful for incorrect locations.)<br />
From RoadTechie:<br />
Normally when we see a bad ad pin we can edit the point place within WME and staff will fix it in a few days. Please continue to do so whenever you see a bad ad-locked point place within WME. Here as of late there have also been reports of bad ad pins visable from the client but there is not an ad-locked point place within WME. If you run across one of these please send an email to one of the SMs with the following information. Email is preferred because a screenshot is required.<br />
<br />
[https://www.waze.com/forum/viewtopic.php?f=631&t=212731 Bad Ad Pin Corrections]<br />
<br />
When I sent my first one in, Todd replied:<br />
btw, I adjusted the final destination before I sent it to Terry with a zoom 10 centered on the point place.<br />
the lat lon of that pl determines exactly where the new ad pin will go [and not the location of the point place.]<br />
<br />
TerryPurdue is an OH state manager: TerryPurdue.Waze@gmail.com<br />
Todd-roadtechie is an IN state manager: roadtechie79@gmail.com<br />
<br />
<br />
'''Ignore Traffic selection on Road Closures'''<br />
(Need to clean this up. Raw comments in GHO from TerryPurdue, 1/2017)<br />
Can we tell if that happens? (I'm just curious how things work. If cleared by traffic, does the closure still show in WME and LiveMap? Should be gone in the app, right?)<br />
The closure will be in place, but it will retest traffic every 15 minutes<br />
If it sees sufficient traffic compared to "normal" it will roll back<br />
It will disappear from livemap and app during that 15 minute window, until next traffic test<br />
That is the clearest explanation anyone has ever been able to give on the "ignore traffic" check box. Thanks<br />
Thats more then I knew about it<br />
So a closure would be re-enabled in the app if not sufficient traffic during a 15 minute interval? (And, agree, best information I've heard on how this works.)<br />
Correct. There's a brand-new test every 15 minutes (until closure hits its expire time).<br />
<br />
That 15 minute test has no visibility to historical tests. IT does a snapshot test in time and makes a call on "closure on" or "closure rolled back" for the subsequent 15 minutes<br />
Which is why we try to remove closures when we know traffic is flowing freely.<br />
<br />
If we don't, due to traffic test, the closure can warp in and warp out unpredictably until the closure expire time.<br />
<br />
Causes URs that are impossible to reproduce and infuriates drivers.<br />
The natural assumption is that on the first traffic test where sufficient traffic is seen, the closure deletes itself.<br />
<br />
Absolutely untrue.<br />
<br />
'''In defense of SLURs'''<br />
When speed limits became visible in the app, there was also an ability to report errors in those limits. The volume of these Speed Limit URs created a lot of unhappiness in the editor community. On Sept 11 2016 the display of these SLURs was removed from WME. App users can still report and have no idea why their reports are not being acted upon. This situation seems horrible. There has been a suggestion that these URs might be made visible in a separate layer, as URs and MPs are now. But the possible time for this to be done is not soon.<br />
<br />
On 2/9/17, MapSir announced in the forum that all SLURs over 2 weeks old had been discarded and they were working on way of presenting the new SLURs. 2/12/17 MapSir said "support for changing/temporary speed limits is planned for the not so near future."<br />
<br />
2/19/17 MapSir said "We're almost ready to launch the new SLUR's.". (These are aggregates of reports on segments. Others call these super-SLURs.) There was a request the new SLURs show in beta first, but that might not be possible because URs go directly to production.<br />
<br />
'''Difficult turns'''<br />
Navigation option in app for "Reduce difficult intersections" in v4.18.0.1 (Jan 2017). The word is that the penalty is currently 7 minutes.<br />
<br />
'''Personal clean-up projects'''<br />
Since we are all volunteers, we get to work on items that interest us. Here are a list of "pet peeve" projects I'm working on. The list is mainly to remind me.<br />
<br />
* Make sure private residences are listed like that.<br />
If you search in the app, you won't get residences properly classified. Here are some search terms that will turn up incorrectly listed residences. House, home, residence, other, Mom, Dad, Aunt, Uncle, job. Need to make sure for "relations" that they aren't really businesses. Select the option menu, "report a problem" and then "residential place". This puts a flag on the place pretty quickly. You get a message in the app when an editor deals with it. I haven't tested what happens if you do this multiple times. I'm a little worried this can be perceived as spamming.<br />
<br />
* Have at least "state" on all places.<br />
It seems the basemap impor of places don't (always?) have state. The easiest way to find these (since Wide Area Lens won't find these yet) is to use the Toolbox "Select Places" option and sort on state. You will get some even at zoom=0 so it when I'm editing in an area, I should just take a quick look to see if there are addresses I can at least have state on. An Indiana SM(?) is also working on this.<br />
<br />
* Get I-80 turnpike in NE Indiana correctly listed as "not toll"<br />
Toll road attribute should only be when there is a collection point on the segment. Much of I-80 is incorrectly listed. Here's a link to one place. (This won't be a continuing issue. If no Indiana editor addresses this, I should chip away at it with GHO requests for change. All of it is OOA.<br />
[https://www.waze.com/editor/?env=usa&lon=-86.48300&lat=41.74433&zoom=2&mode=0 Turn on Highlight:Toll Road to see misclassified]<br />
Sample posting: <br />
<br />
R5+ - Please remove Toll Road attribute. There are no toll collection points on these segments. (I-80 in NE Indiana. OOA for me) xxx<br />
<br />
Group by direction (since if names don't match, can't change attribute.) Work east to west from Ohio state line.<br />
<br />
Note: I-44 in Oklahoma is also handled incorrectly (I think) in places.<br />
<br />
* Add parking lots<br />
When Waze started showing parking lots in the app, they wanted all parking lots to be mapped. When I'm editing, if I see an unmapped parking lot, I'll normally add it. If there are a lot of missing lots, I won't necessarily try to get them all. That wasn't why I was in the area. Also, any time I drive somewhere and the nearest parking lot shown to the destination is not really the nearest, I'll add at least the nearest.<br />
<br />
'''Where to find who the state managers are'''<br />
You can go to the Wiki for the state and find them, but TerryPurdue says this will always be current<br />
[https://wiki.waze.com/wiki/State_Manager/USA#State_Manager_list State Managers]<br />
<br />
'''Searching network'''<br />
<br />
I have been told that the server disconnects the client session after 10 minutes of no communication. However, the client (app) continues to try to connect with the old session number, which is why after a long period of no cellphone coverage, the app will never reconnect even though stopping and starting the app will connect immediately.<br />
<br />
'''Source for "everything" in a certain category'''<br />
<br />
(KY uses this to do projects to update "everything" of certain categories)<br />
This site gives us a way to build those lists for schools (among other things), without having to dig through school/district/county websites.<br />
It's actually kind of interesting all the stuff they've mapped (in a map-nerd kind of way, of course). If you're interested:<br />
https://hifld-dhs-gii.opendata.arcgis.com/<br />
<br />
'''Indiana County Road naming'''<br />
From Enfcer74-Barry (4/2017)<br />
The most recent Discussion with the other SM;s is, For this:<br />
{N/S/E/W} Co Rd xxxx {N/S/E/W}<br />
<br />
Primary - when general county-wide lgs omits leading cardinal):<br />
CR-xxxx {N/S/E/W} (trailing cardinal required if present)<br />
<br />
Alt - if current name or county-GIS reference contains leading cardinal:<br />
{N/S/E/W} CR-xxxx {N/S/E/W}<br />
<br />
And I confirmed:<br />
So just to be sure..."E Co Rd 350 N" currently on the map with a lgs of "350 N" should be primary "CR-350 N" with an alternate of "E CR-350 N"?</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=151942User:Bill4732017-02-28T13:43:07Z<p>Bill473: </p>
<hr />
<div>Bill473 is an editor living in Richmond, Indiana. He mainly drives in east central Indiana and west central Ohio but does make several long-distance drives every year.<br />
<br />
He was appointed co-Large Area Manager for SW Ohio in January 2016. In October 2016, he agreed to transfer to NW Ohio LAM.<br />
<br />
'''Notes:'''<br />
(What follows are notes on methods and guidance that isn't part of the official Wiki, but I thought this would be a convenient place to record things I might forget.)<br />
<br />
'''How to fix routing issues:'''<br />
<br />
Type 1 problem - Location of address in the app search is not correct.<br />
1. Check this address in Google Maps. If it is wrong there, that is most likely the reason for Waze to have the wrong location. I think fixing it in GM is best since it helps both GM and Waze users.<br />
<br />
<br />
'''Policy question''': If the 3 BGS leading to an exit have two control cities and the first 2 signs have them in one order and the final sign has them reversed, how should the exit be labeled? <br />
What ever the final sign does<br />
TTS is to match final sign<br />
<br />
(Answer from Travis - OhioStMusicMan 11/28/16)<br />
<br />
'''Wazers Near You'''<br />
From TerryPurdue, 1/2017:<br />
He has no Near You Now (NYN) polygon where he starts his drive. NYNs are only drawn around certain areas across the globe. Many areas are covered but not all.<br />
<br />
Staff says: Unfortunately we can't change the shape of the NYN polygons, the reason is that these metro polygons are used for all kinds of advertising, statistics, and data collection.<br />
<br />
The NYN feature is just tagging along, the polygons were never meant for it.<br />
<br />
And Terry checked:<br />
Can confirm there is a NYN polygon in Ohio due east of Richmond that ends hard at the IN/OH border.<br />
You'll see the feature work in both Greenfield and New Castle, but not on the stretch of I-70 between them.<br />
<br />
And Terry also added: Talking with other Champs, we were thinking it'd be good if you're outside the polygon if the app would fall back to a "radius sweep" of N km so you didn't feel so alone.<br />
<br />
[https://waze.uservoice.com/forums/59223-waze-suggestion-box/suggestions/17753275-make-wazers-near-you-work-everywhere I created a suggestion]<br />
<br />
I need to transition all this to Wazeopedia, but my link takes me here so I'll do that some other day.<br />
<br />
Cases where BDP seems to be working incorrectly:<br />
<br />
<br />
https://www.waze.com/livemap?lon=-84.0685&lat=40.7724&zoom=15&from_lat=40.80436&from_lon=-84.02009&to_lat=40.7724&to_lon=-84.0685&at_req=0&at_text=Now<br />
<br />
<br />
UR says they were directed off the Bluelick Rd exit and back on. Nothing on the map to explain this. December 17, 2016 11:23 Nothing in the UR to support or contradict that assertion. No traffic issues at the time. User reports 75 mph driving here.<br />
<br />
Waze3rdParty" gas stations popping up in places that clearly aren't gas stations.<br />
JustinS83 says (1/9/17) "send them to SMs".<br />
<br />
'''What you can tell from the search results in the app'''<br />
Put Waze in debug mode and it should fill in the bubbles with a dark blue for Waze results.<br />
search code 2##2 (xanderb 1/10/17)<br />
<br />
'''Toolbox Notes''' I noticed today (1/12/17) that there were "Select Segments" (Green) and "Select Places" (purple) options between "Keyboard Shortcuts Editor" and "Measurement Tool". Didn't see "Places" CHrome. Saw both in FF. (Toolbox update?)<br />
This gives a grid with information about segments or places. Can't copy it (at least I don't know how) but can sort columns. One use is sort on state and use it to fill in missing ones.<br />
<br />
'''Bad Ad Pin Correction'''<br />
(This may primarily be useful for incorrect locations.)<br />
From RoadTechie:<br />
Normally when we see a bad ad pin we can edit the point place within WME and staff will fix it in a few days. Please continue to do so whenever you see a bad ad-locked point place within WME. Here as of late there have also been reports of bad ad pins visable from the client but there is not an ad-locked point place within WME. If you run across one of these please send an email to one of the SMs with the following information. Email is preferred because a screenshot is required.<br />
<br />
[https://www.waze.com/forum/viewtopic.php?f=631&t=212731 Bad Ad Pin Corrections]<br />
<br />
When I sent my first one in, Todd replied:<br />
btw, I adjusted the final destination before I sent it to Terry with a zoom 10 centered on the point place.<br />
the lat lon of that pl determines exactly where the new ad pin will go [and not the location of the point place.]<br />
<br />
TerryPurdue is an OH state manager: TerryPurdue.Waze@gmail.com<br />
Todd-roadtechie is an IN state manager: roadtechie79@gmail.com<br />
<br />
<br />
'''Ignore Traffic selection on Road Closures'''<br />
(Need to clean this up. Raw comments in GHO from TerryPurdue, 1/2017)<br />
Can we tell if that happens? (I'm just curious how things work. If cleared by traffic, does the closure still show in WME and LiveMap? Should be gone in the app, right?)<br />
The closure will be in place, but it will retest traffic every 15 minutes<br />
If it sees sufficient traffic compared to "normal" it will roll back<br />
It will disappear from livemap and app during that 15 minute window, until next traffic test<br />
That is the clearest explanation anyone has ever been able to give on the "ignore traffic" check box. Thanks<br />
Thats more then I knew about it<br />
So a closure would be re-enabled in the app if not sufficient traffic during a 15 minute interval? (And, agree, best information I've heard on how this works.)<br />
Correct. There's a brand-new test every 15 minutes (until closure hits its expire time).<br />
<br />
That 15 minute test has no visibility to historical tests. IT does a snapshot test in time and makes a call on "closure on" or "closure rolled back" for the subsequent 15 minutes<br />
Which is why we try to remove closures when we know traffic is flowing freely.<br />
<br />
If we don't, due to traffic test, the closure can warp in and warp out unpredictably until the closure expire time.<br />
<br />
Causes URs that are impossible to reproduce and infuriates drivers.<br />
The natural assumption is that on the first traffic test where sufficient traffic is seen, the closure deletes itself.<br />
<br />
Absolutely untrue.<br />
<br />
'''In defense of SLURs'''<br />
When speed limits became visible in the app, there was also an ability to report errors in those limits. The volume of these Speed Limit URs created a lot of unhappiness in the editor community. On Sept 11 2016 the display of these SLURs was removed from WME. App users can still report and have no idea why their reports are not being acted upon. This situation seems horrible. There has been a suggestion that these URs might be made visible in a separate layer, as URs and MPs are now. But the possible time for this to be done is not soon.<br />
<br />
On 2/9/17, MapSir announced in the forum that all SLURs over 2 weeks old had been discarded and they were working on way of presenting the new SLURs. 2/12/17 MapSir said "support for changing/temporary speed limits is planned for the not so near future."<br />
<br />
2/19/17 MapSir said "We're almost ready to launch the new SLUR's.". (These are aggregates of reports on segments. Others call these super-SLURs.) There was a request the new SLURs show in beta first, but that might not be possible because URs go directly to production.<br />
<br />
'''Difficult turns'''<br />
Navigation option in app for "Reduce difficult intersections" in v4.18.0.1 (Jan 2017). The word is that the penalty is currently 7 minutes.<br />
<br />
'''Personal clean-up projects'''<br />
Since we are all volunteers, we get to work on items that interest us. Here are a list of "pet peeve" projects I'm working on. The list is mainly to remind me.<br />
<br />
* Make sure private residences are listed like that.<br />
If you search in the app, you won't get residences properly classified. Here are some search terms that will turn up incorrectly listed residences. House, home, residence, other, Mom, Dad, Aunt, Uncle, job. Need to make sure for "relations" that they aren't really businesses. Select the option menu, "report a problem" and then "residential place". This puts a flag on the place pretty quickly. You get a message in the app when an editor deals with it. I haven't tested what happens if you do this multiple times. I'm a little worried this can be perceived as spamming.<br />
<br />
* Have at least "state" on all places.<br />
It seems the basemap impor of places don't (always?) have state. The easiest way to find these (since Wide Area Lens won't find these yet) is to use the Toolbox "Select Places" option and sort on state. You will get some even at zoom=0 so it when I'm editing in an area, I should just take a quick look to see if there are addresses I can at least have state on. An Indiana SM(?) is also working on this.<br />
<br />
* Get I-80 turnpike in NE Indiana correctly listed as "not toll"<br />
Toll road attribute should only be when there is a collection point on the segment. Much of I-80 is incorrectly listed. Here's a link to one place. (This won't be a continuing issue. If no Indiana editor addresses this, I should chip away at it with GHO requests for change. All of it is OOA.<br />
[https://www.waze.com/editor/?env=usa&lon=-86.48300&lat=41.74433&zoom=2&mode=0 Turn on Highlight:Toll Road to see misclassified]<br />
Sample posting: <br />
<br />
R5+ - Please remove Toll Road attribute. There are no toll collection points on these segments. (I-80 in NE Indiana. OOA for me) xxx<br />
<br />
Group by direction (since if names don't match, can't change attribute.) Work east to west from Ohio state line.<br />
<br />
Note: I-44 in Oklahoma is also handled incorrectly (I think) in places.<br />
<br />
* Add parking lots<br />
When Waze started showing parking lots in the app, they wanted all parking lots to be mapped. When I'm editing, if I see an unmapped parking lot, I'll normally add it. If there are a lot of missing lots, I won't necessarily try to get them all. That wasn't why I was in the area. Also, any time I drive somewhere and the nearest parking lot shown to the destination is not really the nearest, I'll add at least the nearest.<br />
<br />
'''Where to find who the state managers are'''<br />
You can go to the Wiki for the state and find them, but TerryPurdue says this will always be current<br />
[https://wiki.waze.com/wiki/State_Manager/USA#State_Manager_list State Managers]<br />
<br />
'''Searching network'''<br />
<br />
I have been told that the server disconnects the client session after 10 minutes of no communication. However, the client (app) continues to try to connect with the old session number, which is why after a long period of no cellphone coverage, the app will never reconnect even though stopping and starting the app will connect immediately.<br />
<br />
'''Source for "everything" in a certain category'''<br />
<br />
(KY uses this to do projects to update "everything" of certain categories)<br />
This site gives us a way to build those lists for schools (among other things), without having to dig through school/district/county websites.<br />
It's actually kind of interesting all the stuff they've mapped (in a map-nerd kind of way, of course). If you're interested:<br />
https://hifld-dhs-gii.opendata.arcgis.com/</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=151720User:Bill4732017-02-22T04:21:34Z<p>Bill473: </p>
<hr />
<div>Bill473 is an editor living in Richmond, Indiana. He mainly drives in east central Indiana and west central Ohio but does make several long-distance drives every year.<br />
<br />
He was appointed co-Large Area Manager for SW Ohio in January 2016. In October 2016, he agreed to transfer to NW Ohio LAM.<br />
<br />
'''Notes:'''<br />
(What follows are notes on methods and guidance that isn't part of the official Wiki, but I thought this would be a convenient place to record things I might forget.)<br />
<br />
'''How to fix routing issues:'''<br />
<br />
Type 1 problem - Location of address in the app search is not correct.<br />
1. Check this address in Google Maps. If it is wrong there, that is most likely the reason for Waze to have the wrong location. I think fixing it in GM is best since it helps both GM and Waze users.<br />
<br />
<br />
'''Policy question''': If the 3 BGS leading to an exit have two control cities and the first 2 signs have them in one order and the final sign has them reversed, how should the exit be labeled? <br />
What ever the final sign does<br />
TTS is to match final sign<br />
<br />
(Answer from Travis - OhioStMusicMan 11/28/16)<br />
<br />
'''Wazers Near You'''<br />
From TerryPurdue, 1/2017:<br />
He has no Near You Now (NYN) polygon where he starts his drive. NYNs are only drawn around certain areas across the globe. Many areas are covered but not all.<br />
<br />
Staff says: Unfortunately we can't change the shape of the NYN polygons, the reason is that these metro polygons are used for all kinds of advertising, statistics, and data collection.<br />
<br />
The NYN feature is just tagging along, the polygons were never meant for it.<br />
<br />
And Terry checked:<br />
Can confirm there is a NYN polygon in Ohio due east of Richmond that ends hard at the IN/OH border.<br />
You'll see the feature work in both Greenfield and New Castle, but not on the stretch of I-70 between them.<br />
<br />
And Terry also added: Talking with other Champs, we were thinking it'd be good if you're outside the polygon if the app would fall back to a "radius sweep" of N km so you didn't feel so alone.<br />
<br />
[https://waze.uservoice.com/forums/59223-waze-suggestion-box/suggestions/17753275-make-wazers-near-you-work-everywhere I created a suggestion]<br />
<br />
I need to transition all this to Wazeopedia, but my link takes me here so I'll do that some other day.<br />
<br />
Cases where BDP seems to be working incorrectly:<br />
<br />
<br />
https://www.waze.com/livemap?lon=-84.0685&lat=40.7724&zoom=15&from_lat=40.80436&from_lon=-84.02009&to_lat=40.7724&to_lon=-84.0685&at_req=0&at_text=Now<br />
<br />
<br />
UR says they were directed off the Bluelick Rd exit and back on. Nothing on the map to explain this. December 17, 2016 11:23 Nothing in the UR to support or contradict that assertion. No traffic issues at the time. User reports 75 mph driving here.<br />
<br />
Waze3rdParty" gas stations popping up in places that clearly aren't gas stations.<br />
JustinS83 says (1/9/17) "send them to SMs".<br />
<br />
'''What you can tell from the search results in the app'''<br />
Put Waze in debug mode and it should fill in the bubbles with a dark blue for Waze results.<br />
search code 2##2 (xanderb 1/10/17)<br />
<br />
'''Toolbox Notes''' I noticed today (1/12/17) that there were "Select Segments" (Green) and "Select Places" (purple) options between "Keyboard Shortcuts Editor" and "Measurement Tool". Didn't see "Places" CHrome. Saw both in FF. (Toolbox update?)<br />
This gives a grid with information about segments or places. Can't copy it (at least I don't know how) but can sort columns. One use is sort on state and use it to fill in missing ones.<br />
<br />
'''Bad Ad Pin Correction'''<br />
(This may primarily be useful for incorrect locations.)<br />
From RoadTechie:<br />
Normally when we see a bad ad pin we can edit the point place within WME and staff will fix it in a few days. Please continue to do so whenever you see a bad ad-locked point place within WME. Here as of late there have also been reports of bad ad pins visable from the client but there is not an ad-locked point place within WME. If you run across one of these please send an email to one of the SMs with the following information. Email is preferred because a screenshot is required.<br />
<br />
[https://www.waze.com/forum/viewtopic.php?f=631&t=212731 Bad Ad Pin Corrections]<br />
<br />
When I sent my first one in, Todd replied:<br />
btw, I adjusted the final destination before I sent it to Terry with a zoom 10 centered on the point place.<br />
the lat lon of that pl determines exactly where the new ad pin will go [and not the location of the point place.]<br />
<br />
TerryPurdue is an OH state manager: TerryPurdue.Waze@gmail.com<br />
Todd-roadtechie is an IN state manager: roadtechie79@gmail.com<br />
<br />
<br />
'''Ignore Traffic selection on Road Closures'''<br />
(Need to clean this up. Raw comments in GHO from TerryPurdue, 1/2017)<br />
Can we tell if that happens? (I'm just curious how things work. If cleared by traffic, does the closure still show in WME and LiveMap? Should be gone in the app, right?)<br />
The closure will be in place, but it will retest traffic every 15 minutes<br />
If it sees sufficient traffic compared to "normal" it will roll back<br />
It will disappear from livemap and app during that 15 minute window, until next traffic test<br />
That is the clearest explanation anyone has ever been able to give on the "ignore traffic" check box. Thanks<br />
Thats more then I knew about it<br />
So a closure would be re-enabled in the app if not sufficient traffic during a 15 minute interval? (And, agree, best information I've heard on how this works.)<br />
Correct. There's a brand-new test every 15 minutes (until closure hits its expire time).<br />
<br />
That 15 minute test has no visibility to historical tests. IT does a snapshot test in time and makes a call on "closure on" or "closure rolled back" for the subsequent 15 minutes<br />
Which is why we try to remove closures when we know traffic is flowing freely.<br />
<br />
If we don't, due to traffic test, the closure can warp in and warp out unpredictably until the closure expire time.<br />
<br />
Causes URs that are impossible to reproduce and infuriates drivers.<br />
The natural assumption is that on the first traffic test where sufficient traffic is seen, the closure deletes itself.<br />
<br />
Absolutely untrue.<br />
<br />
'''In defense of SLURs'''<br />
When speed limits became visible in the app, there was also an ability to report errors in those limits. The volume of these Speed Limit URs created a lot of unhappiness in the editor community. On Sept 11 2016 the display of these SLURs was removed from WME. App users can still report and have no idea why their reports are not being acted upon. This situation seems horrible. There has been a suggestion that these URs might be made visible in a separate layer, as URs and MPs are now. But the possible time for this to be done is not soon.<br />
<br />
'''Difficult turns'''<br />
Navigation option in app for "Reduce difficult intersections" in v4.18.0.1 (Jan 2017). The word is that the penalty is currently 7 minutes.<br />
<br />
'''Personal clean-up projects'''<br />
Since we are all volunteers, we get to work on items that interest us. Here are a list of "pet peeve" projects I'm working on. The list is mainly to remind me.<br />
<br />
* Make sure private residences are listed like that.<br />
If you search in the app, you won't get residences properly classified. Here are some search terms that will turn up incorrectly listed residences. House, home, residence, other, Mom, Dad, Aunt, Uncle, job. Need to make sure for "relations" that they aren't really businesses. Select the option menu, "report a problem" and then "residential place". This puts a flag on the place pretty quickly. You get a message in the app when an editor deals with it. I haven't tested what happens if you do this multiple times. I'm a little worried this can be perceived as spamming.<br />
<br />
* Have at least "state" on all places.<br />
It seems the basemap impor of places don't (always?) have state. The easiest way to find these (since Wide Area Lens won't find these yet) is to use the Toolbox "Select Places" option and sort on state. You will get some even at zoom=0 so it when I'm editing in an area, I should just take a quick look to see if there are addresses I can at least have state on. An Indiana SM(?) is also working on this.<br />
<br />
* Get I-80 turnpike in NE Indiana correctly listed as "not toll"<br />
Toll road attribute should only be when there is a collection point on the segment. Much of I-80 is incorrectly listed. Here's a link to one place. (This won't be a continuing issue. If no Indiana editor addresses this, I should chip away at it with GHO requests for change. All of it is OOA.<br />
[https://www.waze.com/editor/?env=usa&lon=-86.48300&lat=41.74433&zoom=2&mode=0 Turn on Highlight:Toll Road to see misclassified]<br />
Sample posting: <br />
<br />
R5+ - Please remove Toll Road attribute. There are no toll collection points on these segments. (I-80 in NE Indiana. OOA for me) xxx<br />
<br />
Group by direction (since if names don't match, can't change attribute.) Work east to west from Ohio state line.<br />
<br />
Note: I-44 in Oklahoma is also handled incorrectly (I think) in places.<br />
<br />
* Add parking lots<br />
When Waze started showing parking lots in the app, they wanted all parking lots to be mapped. When I'm editing, if I see an unmapped parking lot, I'll normally add it. If there are a lot of missing lots, I won't necessarily try to get them all. That wasn't why I was in the area. Also, any time I drive somewhere and the nearest parking lot shown to the destination is not really the nearest, I'll add at least the nearest.<br />
<br />
'''Where to find who the state managers are'''<br />
You can go to the Wiki for the state and find them, but TerryPurdue says this will always be current<br />
[https://wiki.waze.com/wiki/State_Manager/USA#State_Manager_list State Managers]<br />
<br />
'''Searching network'''<br />
<br />
I have been told that the server disconnects the client session after 10 minutes of no communication. However, the client (app) continues to try to connect with the old session number, which is why after a long period of no cellphone coverage, the app will never reconnect even though stopping and starting the app will connect immediately.<br />
<br />
'''Source for "everything" in a certain category'''<br />
<br />
(KY uses this to do projects to update "everything" of certain categories)<br />
This site gives us a way to build those lists for schools (among other things), without having to dig through school/district/county websites.<br />
It's actually kind of interesting all the stuff they've mapped (in a map-nerd kind of way, of course). If you're interested:<br />
https://hifld-dhs-gii.opendata.arcgis.com/</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143850User:RonRover2016-05-01T18:55:16Z<p>Bill473: /* BIG DETOUR PREVENTION (BDP) Explained by Bill473 */</p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was originally presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has made changes based on feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions. If you have suggestions to make this better, please contact either [https://www.waze.com/forum/ucp.php?i=pm&mode=compose&username=RonRover Ron] or [https://www.waze.com/forum/ucp.php?i=pm&mode=compose&username=Bill473 Bill].''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going northbound, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. <br />
#: The " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route Waze is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. Adding US-36 E as an alternate name to the second ramp segment was sufficient to fix the problem. A more robust solution is to add US-36 E to all ramp segments that carry that route.<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment. However, unless there is a reason to leave the name off the first segment, it is safer to add it.<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way. <br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
Although currently only the last of the three segments is checked for BDP (probably to make checking faster), PesachZ suggests that is likely to change. The best fix is to have I-35 N on all. Indeed, if that single ramp segment had I-35 N added earlier, even though not required to prevent a BDP error (since 2 ramp segments required for BDP here), when it was cut into 3 segments no BDP error would have occurred.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge. <br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed, changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
Here is an example where Small Detour Prevention doesn't seen to be working.<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143849User:RonRover2016-05-01T18:41:23Z<p>Bill473: </p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was originally presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has made changes based on feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions. If you have suggestions to make this better, please contact either [https://www.waze.com/forum/ucp.php?i=pm&mode=compose&username=RonRover Ron] or [https://www.waze.com/forum/ucp.php?i=pm&mode=compose&username=Bill473 Bill].''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. <br />
#: The " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route Waze is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. Adding US-36 E as an alternate name to the second ramp segment was sufficient to fix the problem. A more robust solution is to add US-36 E to all ramp segments that carry that route.<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment. However, unless there is a reason to leave the name off the first segment, it is safer to add it.<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way. <br />
<br />
Although currently only the last of the three segments is checked for BDP (probably to make checking faster), PesachZ suggests that is likely to change. The best fix is to have I-35 N on all. Indeed, if that single ramp segment had I-35 N added earlier, even though not required to prevent a BDP error (since 2 ramp segments required for BDP here), when it was cut into 3 segments no BDP error would have occurred.<br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge. <br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed, changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
Here is an example where Small Detour Prevention doesn't seen to be working.<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143848User:RonRover2016-05-01T18:40:05Z<p>Bill473: </p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was originally presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has made changes based on feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions. If you have suggestions to make this better, please contact either Ron or Bill.<br />
[https://www.waze.com/forum/ucp.php?i=pm&mode=compose&username=Bill473 Bill]''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. <br />
#: The " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route Waze is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. Adding US-36 E as an alternate name to the second ramp segment was sufficient to fix the problem. A more robust solution is to add US-36 E to all ramp segments that carry that route.<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment. However, unless there is a reason to leave the name off the first segment, it is safer to add it.<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way. <br />
<br />
Although currently only the last of the three segments is checked for BDP (probably to make checking faster), PesachZ suggests that is likely to change. The best fix is to have I-35 N on all. Indeed, if that single ramp segment had I-35 N added earlier, even though not required to prevent a BDP error (since 2 ramp segments required for BDP here), when it was cut into 3 segments no BDP error would have occurred.<br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge. <br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed, changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
Here is an example where Small Detour Prevention doesn't seen to be working.<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143847User:RonRover2016-05-01T18:31:55Z<p>Bill473: </p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was originally presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has made changes based on feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions. If you have suggestions to make this better, please contact either Ron or Bill.''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. <br />
#: The " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route Waze is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. Adding US-36 E as an alternate name to the second ramp segment was sufficient to fix the problem. A more robust solution is to add US-36 E to all ramp segments that carry that route.<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment. However, unless there is a reason to leave the name off the first segment, it is safer to add it.<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way. <br />
<br />
Although currently only the last of the three segments is checked for BDP (probably to make checking faster), PesachZ suggests that is likely to change. The best fix is to have I-35 N on all. Indeed, if that single ramp segment had I-35 N added earlier, even though not required to prevent a BDP error (since 2 ramp segments required for BDP here), when it was cut into 3 segments no BDP error would have occurred.<br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge. <br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed, changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
Here is an example where Small Detour Prevention doesn't seen to be working.<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143846User:RonRover2016-05-01T18:29:09Z<p>Bill473: </p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was originally presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has made changes based on feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions. If you have suggestions to make this better, please contact either Ron or Bill.''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. <br />
<br />
#: The " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route Waze is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. Adding US-36 E as an alternate name to the second ramp segment was sufficient to fix the problem. A more robust solution is to add US-36 E to all ramp segments that carry that route.<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment. However, unless there is a reason to leave the name off the first segment, it is safer to add it.<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way. <br />
<br />
Although currently only the last of the three segments is checked for BDP (probably to make checking faster), PesachZ suggests that is likely to change. The best fix is to have I-35 N on all. Indeed, if that single ramp segment had I-35 N added earlier, even though not required to prevent a BDP error (since 2 ramp segments required for BDP here), when it was cut into 3 segments no BDP error would have occurred.<br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge. <br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed, changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
Here is an example where Small Detour Prevention doesn't seen to be working.<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143845User:RonRover2016-05-01T18:05:04Z<p>Bill473: /* BIG DETOUR PREVENTION (BDP) Explained by Bill473 */</p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was originally presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has made changes based on feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions. If you have suggestions to make this better, please contact either Ron or Bill.''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. <br />
<br />
#: The " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route Waze is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. Adding US-36 E as an alternate name to the second ramp segment was sufficient to fix the problem. A more robust solution is to add US-36 E to all ramp segments that carry that route.<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment. However, unless there is a reason to leave the name off the first segment, it is safer to add it.<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way. <br />
<br />
Although currently only the last of the three segments is checked for BDP (probably to make checking faster), PesachZ suggests that is likely to change. The best fix is to have I-35 N on all. Indeed, if that single ramp segment had I-35 N added earlier, even though not required to prevent a BDP error (since 2 ramp segments required for BDP here), when it was cut into 3 segments no BDP error would have occurred.<br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge. <br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed. changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
Here is an example where Small Detour Prevention doesn't seen to be working.<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143844User:RonRover2016-05-01T17:55:25Z<p>Bill473: /* BIG DETOUR PREVENTION (BDP) Explained by Bill473 */</p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has received useful feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions. If you have suggestions to make this better, please contact either Ron or Bill.''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. <br />
<br />
#: The " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route Waze is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. Adding US-36 E as an alternate name to the second ramp segment was sufficient to fix the problem. A more robust solution is to add US-36 E to all ramp segments that carry that route.<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment. However, unless there is a reason to leave the name off the first segment, it is safer to add it.<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way. <br />
<br />
Although currently only the last of the three segments is checked for BDP (probably to make checking faster), PesachZ suggests that is likely to change. The best fix is to have I-35 N on all. Indeed, if that single ramp segment had I-35 N added earlier, even though not required to prevent a BDP error (since 2 ramp segments required for BDP here), when it was cut into 3 segments no BDP error would have occurred.<br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge. <br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed. changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
Here is an example where Small Detour Prevention doesn't seen to be working.<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:RonRover&diff=143843User:RonRover2016-05-01T17:25:59Z<p>Bill473: Acknowledge input from other editors</p>
<hr />
<div>==== <u>SAMPLE LETTERS</u> ====<br />
<b>Sample Editor Outreach Message:</b><br />
<br />
Hi,<br /><br />
I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.<br /> <br />
In the meantime please read these two pages:<br /><br />
<nowiki>https://wiki.waze.com/wiki/Waze_Map_Editor/Welcome</nowiki><br />
<nowiki>https://wiki.waze.com/wiki/Edits_to_avoid_(USA)</nowiki><br /><br />
(You will have to add the closing parenthesis the the above link)<br /><br />
<br />
If you would like to pursue joining with us, just read this and request to be added.<br /><br />
<nowiki>https://www.waze.com/forum/viewtopic.php?f=261&t=133427</nowiki><br /><br />
<br />
Hope to see you editing,<br /><br />
<br />
Your Name/Editor Name<br />
<br />
<br />
<br />
==== <u>LINKS TO CITIES AND VILLAGES PDF IN OHIO</u> ====<br />
http://www.omlohio.org/Municipal%20Resources/listofmunicipalities.pdf<br />
<br />
<br />
<br />
==== <u>WME HELPFUL LINKS FOR URs </u> ====<br />
How to <b>remove locations</b> from the Waze App<br /><br />
https://goo.gl/WbYjyQ<br /><br />
<br />
How to <b>set or change Home and Work</b><br /><br />
https://goo.gl/rTbTVx<br /><br />
<br />
How to <b>collect logs</b> from the App. (see next item also)<br /><br />
https://goo.gl/1G3Wx3<br /><br />
<br />
Form to fill out <b>for Waze reporting to accompany the logs</b>. (see above item also)<br /><br />
https://goo.gl/967r1F<br /><br />
<br />
<b>Waze Help Center</b><br /><br />
https://goo.gl/svEPRF<br /><br />
<br /><br />
<b>Waze Bug Report Form</b><br /><br />
https://goo.gl/967r1F<br /><br />
<br /><br />
<br />
==== BIG DETOUR PREVENTION (BDP) Explained by Bill473 ====<br />
''The following was presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both of us. Bill has received useful feedback from PesachZ and TerryPurdue but remains responsible for any errors or omissions.''<br />
<br />
This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.<br />
<br />
First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.<br />
<br />
When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.<br />
<br />
When checking BDP errors, you need to look at primary and alternate names on segments.<br />
<br />
A very useful user script is [http://www.waze.com/forum/viewtopic.php?f=819&t=173983 WME Show Alt Names]. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.<br />
<br />
<br />
I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.<br />
<br />
Here's a real-life example of a BDP error (fixed now, of course):<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-1.jpg<br />
<br />
<br />
<br />
And here's the [http://www.waze.com/livemap?lon=-84.60657&lat=40.10016&zoom=17 LiveMap link] to the area so you can see where the segments are.<br />
<br />
<br />
The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.<br />
<br />
So why didn't Waze recommend that? Because it thought that would be a detour!<br />
<br />
Let me try to explain the "detour" before getting into all the details. <br />
US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.<br />
<br />
Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W which is not considered a detour due to more advanced criteria discussed later.)<br />
<br />
(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening. For this reason that old guidance is ''old'', and no longer recommended.)<br />
<br />
* If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.<br />
<br />
The global Wiki entry on Detour Prevention is<br />
[[Detour Prevention Mechanisms]], however is it rather vague, and partially inaccurate leading to confusion.<br />
<br />
A more detailed version written for the US is<br />
[[Detour Prevention Mechanisms/USA]]<br />
<br />
This latter link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:<br />
<br />
# '''Road Name Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name<br />
#:Yes: US-36 E on both. (Primary or alternate, makes no difference)<br />
# '''Road Type Discontinuity''' - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.' <br />
#:(The grouping is Freeway/MH in one group, mH in another)<br />
#:Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.<br />
# '''Existence Of Direct Route''' - The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. ''I'm having a little trouble with the exact wording because I think it is slighly misstated. (Both the detour and the "direct route" share the first ramp segment.) Can we say "yes, there is a direct route, Waze is showing it in the picture?''<br />
#: No, the " direct route" doesn't need to be "direct", it just needs be a different route which does not use any segments used by the "detour route" being evaluated. The "direct route" here is not the route wazs is suggesting, rather a different more circuitous option.<br />
#: The second portion of the "direct route" is that there is another way to approach the segment after the potential detour from a matching road type. For the potential detour here, the alternate approach is coming EB on the Fwy which becomes US-36 E. (This is also the reason the route suggested above is not a detour, the only alternative path to the post-detour segment would be via the ramps, which are not in the same road type group. So no alternate pathway to the post detour segment, means that this route can not be considered a detour.)<br />
# '''Minimum Length''' - The possible detour must be more than one segment long.<br />
#: Yes: 2 (ramp) segments.<br />
# '''Maximum Length''' - The possible detour must be shorter than the threshold length <br />
#: Yes: Threshold for this group is 5km.<br />
<br />
Whew!<br />
Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.<br />
<br />
Here is the basic idea that I think makes this "simple".<br />
<br />
You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.<br />
<br />
There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)<br />
<br />
So what's the fix? Let Waze know that this ramp is part of US-36 E. {{Red|You can't touch the first ramp segment since you need the name discontinuity to get the "to US-36 / SR-571 / Greenville / Piqua" instruction. But you can add US-36 E as an alternate name to the second ramp segment.}}<br />
<br />
''You can add the alt name to both ramp segments, the fact that they are a different type (ramp) that the preceding segment (Fwy) is what dictates that a prompt will be given.''<br />
<br />
At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment (to support the wayfinder function.)<br />
<br />
<hr><br />
<br />
Des Moines Iowa<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-2%20DesMoines.png<br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-93.5782&lat=41.65459&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way.<br />
<br />
<i>(Slight update: the current implementation of BDP is that to make sure something is not a detour is to have the name carried through on the last ramp segment. You can gap any segments before the last.<br />
Probably best to carry names through all segments as that implementation is likely to change)</i><br />
<br />
My feeling is the checking of the last segment only is to make the process faster. But you certainly can't expect that to always be the case.<br />
<br />
The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.<br />
<br />
It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge.<br />
<br />
That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)<br />
<br />
Are we OK with the Des Moines example and fix? <br />
<br />
Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:<br />
<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-3.jpg <br />
<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-80.7823&lat=41.27324&zoom=15 LiveMap link] to the area so you can see where the segments are.<br />
<br />
The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed. changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.<br />
<br />
<i>(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)</i><br />
<br />
I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Shift-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.<br />
<br />
If we're OK with BDP, there is also there is also [https://wiki.waze.com/wiki/Detour_Prevention_Mechanisms/USA#Small_Detours Small Detour Prevention]. <br />
<br />
This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "<br />
<br />
I do wonder if this is an example where the prevention isn't working:<br />
<br />
http://i82.photobucket.com/albums/j242/ronbien/BDP-4.png <br />
<br />
It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.<br />
<br />
And here's the [https://www.waze.com/livemap?lon=-85.39021&lat=39.88796&zoom=15 LiveMap link] to the area.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=Indiana/AM/Editor/Area2&diff=142033Indiana/AM/Editor/Area22016-04-11T15:11:40Z<p>Bill473: */Other Area editor table update*/</p>
<hr />
<div><!---------------------- DO NOT MODIFY THIS TOP CODE ------------------------------<br />
------------------------ SCROLL DOWN FOR INSTRUCTIONS -----------------------------><noinclude><!--Keep hard coded due to unique page address--><div class="center"><span class="noprint plainlinks purgelink" style="{{Road/style}}background-color:#93c4d3">[{{FULLURL:{{#titleparts:{{PAGENAME}}|-3}}|action=purge}}#Other_Area_Editors <span title="Return to the Other Area Editor table">&nbsp;Press here to return to the Other Area Editors table to see your changes&nbsp;</span>]</span></div></noinclude><includeonly><!--<br />
-------------------------------------------------------------------------------------<br />
-- Editors: To add yourself to this Other Editor Area table, copy and paste the<br />
-- following template into the space below with the other {{AM/Editor|...}}<br />
-- templates. Add yourself into rank order (higher at top)then alphabetical order<br />
-- by user name (A-Z)<br />
-------------------------------------------------------------------------------------<br />
{{AM/Editor|YOUR_USER_NAME|YOUR_RANK#|YOUR_AREA|ANY_COMMENT}}<br />
-------------------------------------------------------------------------------------<br />
-- then in the Summary field enter "Added YOUR_USER_NAME" and press "Save page"<br />
-------------------------------------------------------------------------------------<br />
---------------------- DO NOT MODIFY CONTENT ABOVE THE LINE -------------------------<br />
--------------------------------------------------------------------------------->|-<br />
{{AM/Editor|Bill473|4|East Central Indiana/West Central Ohio|LAM SW Ohio}}<br />
{{AM/Editor|RonRover|4|SE Indiana|}}<br />
{{AM/Editor|Aqualung812|3|Columbus, Indiana|}}<br />
{{AM/Editor|BobTheWikipedian|3|Evansville, Indiana|}}<br />
{{AM/Editor|fbisurveillancevan21|3| South Central Indiana, Marion/Johnson Counties|}}<br />
{{AM/Editor|MrVanMeter|2|Kokomo, Indiana, Howard County|}}<br />
{{AM/Editor|ScottG76|2|Indianapolis, Indiana|}}<br />
{{AM/Editor|NoWareMan9|1|NE Indiana, Fort Wayne, Allen County|}}<br />
<!-----------------------------------------------------------------------------------<br />
---------------------- DO NOT MODIFY CONTENT BELOW THE LINE -------------------------<br />
-------------------------------------------------------------------------------------<br />
-------------------------------------------------------------------------------------<br />
--></includeonly></div>Bill473https://www.waze.com/wiki/USA/index.php?title=West_Virginia/AM/Editor/Area2&diff=141433West Virginia/AM/Editor/Area22016-03-30T05:32:10Z<p>Bill473: */Other Area editor table update*/</p>
<hr />
<div><!---------------------- DO NOT MODIFY THIS TOP CODE ------------------------------<br />
------------------------ SCROLL DOWN FOR INSTRUCTIONS -----------------------------><noinclude><!--Keep hard coded due to unique page address--><div class="center"><span class="noprint plainlinks purgelink" style="{{Road/style}}background-color:#93c4d3">[{{FULLURL:{{#titleparts:{{PAGENAME}}|-3}}|action=purge}}#Other_Area_Editors <span title="Return to the Other Area Editor table">&nbsp;Press here to return to the Other Area Editors table to see your changes&nbsp;</span>]</span></div></noinclude><includeonly><!--<br />
-------------------------------------------------------------------------------------<br />
-- Editors: To add yourself to this Other Editor Area table, copy and paste the<br />
-- following template into the space below with the other {{AM/Editor|...}}<br />
-- templates. Add yourself into rank order (higher at top)then alphabetical order<br />
-- by user name (A-Z)<br />
-------------------------------------------------------------------------------------<br />
{{AM/Editor|YOUR_USER_NAME|YOUR_RANK#|YOUR_AREA|ANY_COMMENT}}<br />
-------------------------------------------------------------------------------------<br />
-- then in the Summary field enter "Added YOUR_USER_NAME" and press "Save page"<br />
-------------------------------------------------------------------------------------<br />
---------------------- DO NOT MODIFY CONTENT ABOVE THE LINE -------------------------<br />
--------------------------------------------------------------------------------->|-<br />
{{AM/Editor|xanderb|5|Statewide|CM/KY AM|badge1=cm|badge2=sm|badge3=m|badge4=mr|gho=[https://plus.google.com/105059969927895628910/about Xander (GHO)]|pic=File:Avatar_xanderb.jpg}}<br />
{{AM/Editor|bill473|4|I-64 mostly|Lives in Indiana|gho= <span style="font-size:88%”>[https://plus.google.com/u/0/112602412736830861580/about GHO: Bill473]</span>|pic=File:Bill473.jpeg}}<br />
{{AM/Editor|Lentz2|2|Eastern Panhandle||gho= <span style="font-size:88%”>GHO: Samuel</span>}}<br />
{{AM/Editor|markr4468|2|Morgantown| }}<br />
{{AM/Editor|musicmanwins|2|Charleston/Alum Creek|GHO: Colton Toney }}<br />
{{AM/Editor|ymerejo42|2|Charleston/Dunbar||gho= [https://plus.google.com/111877001933514912138/about GHO: Jeremy 'Zilocke']|pic=File:ymerejo42.jpg}}<br />
<br />
<!-----------------------------------------------------------------------------------<br />
---------------------- DO NOT MODIFY CONTENT BELOW THE LINE -------------------------<br />
-------------------------------------------------------------------------------------<br />
-------------------------------------------------------------------------------------<br />
--></includeonly></div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=137966User:Bill4732016-02-20T13:41:58Z<p>Bill473: </p>
<hr />
<div>Bill473 is an editor living in Richmond, Indiana. He mainly drives in east central Indiana and west central Ohio but does make several long-distance drives every year.<br />
<br />
He was appointed co-Large Area Manager for SW Ohio in January 2016.</div>Bill473https://www.waze.com/wiki/USA/index.php?title=User:Bill473&diff=137965User:Bill4732016-02-20T13:34:41Z<p>Bill473: Created new page</p>
<hr />
<div>Bill is just starting to practice, 2/2016. More details to follow</div>Bill473https://www.waze.com/wiki/USA/index.php?title=Ohio/Training_Raids/SuggestionBox&diff=117333Ohio/Training Raids/SuggestionBox2015-08-24T14:05:35Z<p>Bill473: /* Suggestions */</p>
<hr />
<div>== Motivation ==<br />
<br />
There will be more training raids inside Ohio during 2015. Let's keep track of ideas of things to do more of, less of, or differently so we're continually improving raid experience for all participants!<br />
<br />
== Suggestions ==<br />
<br />
* Keep responsible areas separate, but grant all editors all the area (e.g., "Mentoring area") <br />
* When working rural areas, assign larger areas to ensure there's enough work for all editors<br />
* (From Aug 2015 raid) In addition to the "standard" scripts, some other useful ones should be listed. Justin's mention of WME Road Selector was very useful.</div>Bill473