No edit summary |
No edit summary |
||
(3 intermediate revisions by the same user not shown) | |||
Line 10: | Line 10: | ||
Type 1 problem - Location of address in the app search is not correct. | Type 1 problem - Location of address in the app search is not correct. | ||
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. | 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. | ||
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: | |||
<span dir="ltr">'''Residential Place Point Navigation Update''' - The "match street name" issue was just reverted in NA, should be live now.</span> | |||
<span dir="ltr">i.e. - original RPP routing should be restored</span> | |||
Line 137: | Line 143: | ||
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: | 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: | ||
https://hifld-dhs-gii.opendata.arcgis.com/ | https://hifld-dhs-gii.opendata.arcgis.com/ | ||
'''Indiana County Road naming''' | |||
From Enfcer74-Barry (4/2017) | |||
The most recent Discussion with the other SM;s is, For this: | |||
{N/S/E/W} Co Rd xxxx {N/S/E/W} | |||
Primary - when general county-wide lgs omits leading cardinal): | |||
CR-xxxx {N/S/E/W} (trailing cardinal required if present) | |||
Alt - if current name or county-GIS reference contains leading cardinal: | |||
{N/S/E/W} CR-xxxx {N/S/E/W} | |||
And I confirmed: | |||
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"? | |||
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)... | |||
CR-1000 N for primary, W CR-1000 N and W CR-1000 S as alts? (Barry agreed) | |||
Overlocks | |||
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. | |||
<span dir="ltr">There | |||
<nowiki> </nowiki>is a 15 mile stretch of SR-15, a MH, near Findlay OH overlocked at L5. | |||
<nowiki> </nowiki>In the past I have been told some of these examples were because an R3 | |||
made erroneous updates to MHs. I'd like to suggest a few things: (1) | |||
That such overlocks have map comments at the begin and end of the | |||
overlock so we know it was an intentional decision. (2) That such | |||
overlocks be temporary. Once the R3 is properly educated, do we need to | |||
<nowiki> </nowiki>continue the overlock? (3) That such overlocks be +1 instead of L5. | |||
If an R3 makes a mistake, does that mean R4s shouldn't be allowed to | |||
edit? Here's the area in question, but this applies to any overlock in | |||
Ohio. <nowiki>https://www.waze.com/editor/?env=usa&lon=-83.61329&lat=40.97897&zoom=2</nowiki></span> |
Latest revision as of 13:37, 16 July 2017
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.
He was appointed co-Large Area Manager for SW Ohio in January 2016. In October 2016, he agreed to transfer to NW Ohio LAM.
Notes: (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.)
How to fix routing issues:
Type 1 problem - Location of address in the app search is not correct. 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.
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:
Residential Place Point Navigation Update - The "match street name" issue was just reverted in NA, should be live now.
i.e. - original RPP routing should be restored
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?
What ever the final sign does
TTS is to match final sign
(Answer from Travis - OhioStMusicMan 11/28/16)
Wazers Near You From TerryPurdue, 1/2017: 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.
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.
The NYN feature is just tagging along, the polygons were never meant for it.
And Terry checked: Can confirm there is a NYN polygon in Ohio due east of Richmond that ends hard at the IN/OH border. You'll see the feature work in both Greenfield and New Castle, but not on the stretch of I-70 between them.
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.
I need to transition all this to Wazeopedia, but my link takes me here so I'll do that some other day.
Cases where BDP seems to be working incorrectly:
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.
Waze3rdParty" gas stations popping up in places that clearly aren't gas stations. JustinS83 says (1/9/17) "send them to SMs".
What you can tell from the search results in the app Put Waze in debug mode and it should fill in the bubbles with a dark blue for Waze results. search code 2##2 (xanderb 1/10/17)
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?) 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.
Bad Ad Pin Correction (This may primarily be useful for incorrect locations.) From RoadTechie: 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.
When I sent my first one in, Todd replied: btw, I adjusted the final destination before I sent it to Terry with a zoom 10 centered on the point place. the lat lon of that pl determines exactly where the new ad pin will go [and not the location of the point place.]
TerryPurdue is an OH state manager: TerryPurdue.Waze@gmail.com Todd-roadtechie is an IN state manager: roadtechie79@gmail.com
Ignore Traffic selection on Road Closures
(Need to clean this up. Raw comments in GHO from TerryPurdue, 1/2017)
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?)
The closure will be in place, but it will retest traffic every 15 minutes
If it sees sufficient traffic compared to "normal" it will roll back
It will disappear from livemap and app during that 15 minute window, until next traffic test
That is the clearest explanation anyone has ever been able to give on the "ignore traffic" check box. Thanks
Thats more then I knew about it
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.)
Correct. There's a brand-new test every 15 minutes (until closure hits its expire time).
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 Which is why we try to remove closures when we know traffic is flowing freely.
If we don't, due to traffic test, the closure can warp in and warp out unpredictably until the closure expire time.
Causes URs that are impossible to reproduce and infuriates drivers. The natural assumption is that on the first traffic test where sufficient traffic is seen, the closure deletes itself.
Absolutely untrue.
In defense of SLURs 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.
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."
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.
Difficult turns 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.
Personal clean-up projects 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.
- Make sure private residences are listed like that.
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.
- Have at least "state" on all places.
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.
- Get I-80 turnpike in NE Indiana correctly listed as "not toll"
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. Turn on Highlight:Toll Road to see misclassified Sample posting:
R5+ - Please remove Toll Road attribute. There are no toll collection points on these segments. (I-80 in NE Indiana. OOA for me) xxx
Group by direction (since if names don't match, can't change attribute.) Work east to west from Ohio state line.
Note: I-44 in Oklahoma is also handled incorrectly (I think) in places.
- Add parking lots
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.
Where to find who the state managers are You can go to the Wiki for the state and find them, but TerryPurdue says this will always be current State Managers
Searching network
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.
Source for "everything" in a certain category
(KY uses this to do projects to update "everything" of certain categories) This site gives us a way to build those lists for schools (among other things), without having to dig through school/district/county websites. 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: https://hifld-dhs-gii.opendata.arcgis.com/
Indiana County Road naming From Enfcer74-Barry (4/2017) The most recent Discussion with the other SM;s is, For this: {N/S/E/W} Co Rd xxxx {N/S/E/W}
Primary - when general county-wide lgs omits leading cardinal): CR-xxxx {N/S/E/W} (trailing cardinal required if present)
Alt - if current name or county-GIS reference contains leading cardinal: {N/S/E/W} CR-xxxx {N/S/E/W}
And I confirmed: 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"?
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)...
CR-1000 N for primary, W CR-1000 N and W CR-1000 S as alts? (Barry agreed)
Overlocks
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.
There is a 15 mile stretch of SR-15, a MH, near Findlay OH overlocked at L5. In the past I have been told some of these examples were because an R3 made erroneous updates to MHs. I'd like to suggest a few things: (1) That such overlocks have map comments at the begin and end of the overlock so we know it was an intentional decision. (2) That such overlocks be temporary. Once the R3 is properly educated, do we need to continue the overlock? (3) That such overlocks be +1 instead of L5. If an R3 makes a mistake, does that mean R4s shouldn't be allowed to edit? Here's the area in question, but this applies to any overlock in Ohio. https://www.waze.com/editor/?env=usa&lon=-83.61329&lat=40.97897&zoom=2