Draw City Boundaries More Accurately
Currently City Boundary layers are not drawn precisely, which can result in the wrong city name being displayed to users in the app. I continue to get URs on this regularly in my area.
This issue seems to be seen commonly when cities are divided by an undulating river. Users should not be shown that they are in a city that they are not in. The system to "draw" the city layer should rely on more data points to draw a more accurate city layer. I will attach screenshots to show this more clearly.
https://www.waze.com/en-US/editor?env=usa&lon=-122.59338&lat=49.19848&zoom=2
https://imgur.com/V9kFFp4
Incorrect city "Maple Ridge" is displayed on the north section of "Langley" (Blue Circle)
The reverse is also true Incorrect city "Langley" is displayed on a portion of Maple Ridge (Red Circle)
The areas have been meticulously scanned there is no place or street with the wrong city name.
-
Anonymous commented
I would like to bring this topic back up.
In the following we have 3 examples where the layer from a city a is over one from another city (mostly or complete)
Example 1:
"Siebengewald" (Netherland) is covered by german city "Goch"
https://ibb.co/ZHmMtVc // Permalink: https://waze.com/de/editor?env=row&lat=51.65641&lon=6.13457&zoomLevel=14
Example 2:
City "Markkleeberg" is mostly covered by city of "Leipzig"
https://ibb.co/dBNpVvP // Permalink: https://waze.com/de/editor?env=row&lat=51.30688&lon=12.43872&zoomLevel=12
Example 3:
City "Oberheldrungen" is complety covered by city "An der Schmücke"
https://ibb.co/cTy2Yf8 // Permalink: https://waze.com/de/editor?env=row&lat=51.29013&lon=11.26961&marker=true&zoomLevel=13In all cases the segments have the correct citys there, the form of the citys is not correctly builded up by the waze city layers.
So an improvement is necessary. -
Trexer0 commented
I can also share a UR from a user reporting the same problem.
https://www.waze.com/en-US/editor?env=usa&lon=-122.39218&lat=49.14933&zoomLevel=15&mapUpdateRequest=9290371 -
Trexer0 commented
I managed to grab a screenshot today to demonstrate this problem in the app.
https://imgur.com/jSiw7sB
https://imgur.com/lATvs5u
https://imgur.com/Kc0ZGoW"Abbotsford" was displayed despite being in "Mission"
Once again this appears to be related due to the curvature of the river. Nonetheless the wrong city name is being displayed by the app.
-
Bob McCormick commented
In the US we use the WME Cities Overlay script, which I find invaluable. As Vermont US state manager I obtained very accurate polygons from VT GIS and had the script author load those into a database that the script uses to draw the polygons.
Note: many states appear to have US Census Bureau TIGER polygons in that database. My experience is that much of that data: 1) contains inaccurate polygons, and 2) is missing a significant amount of cities and towns.
The ideal situation would be the functionality of the WME Cities Overlay script was native to WME, and the database(s) of polygons would be something coming from the editing community and submitted to and maintained by Waze.
-
DwarfLord commented
Two thoughts:
1. The image is from WME, not the app. What matters is the app display, which at present doesn't show city boundaries at all. Rather it "floats" the city name above the other items on the display in a way it hopes is unobtrusive. Is there any complaint with how the app is doing this?
2. My understanding is that there are two "flavors" of city in Waze. One flavor consists of cities that were part of the original basemap import; they are "hard-coded" into the database and their display boundaries cannot be changed, regardless of anything editors do, without intervention by HQ (which can be requested, but can take some time). The other flavor consists of cities added by editors since the basemap import. The display boundaries for these are fluid, and can change as the primary city names on various segments change.
I believe your best shot at relief from Waze is to (a) demonstrate that the display on the app is messed up, not just the WME cities layer; AND (b) consequently request that HQ modify their hard-coded city boundary. In the US, this process generally implies RC involvement.