|This revision of the page is currently undergoing modifications. The information presented should be considered a draft, not yet ready for use. If you would like to contribute to this content, please consider posting in the Wiki Updates and Discussion forum first to discuss your ideas. Please use the talk page for thoughts and ideas on setting up this content.|
|A significant amount of information on this page is no longer valid. Please refer to the national Best Practices guidance until this page can be revised.|
The following practices and techniques are used around Ohio.
Dealing with system-detected problems
Waze is constantly analyzing tracking information generated by users; it compares this information with the existing mapping data. After this comparison, Waze is often able to determine the directions of travel permitted on "unknown" roads or through intersections and will automatically update the maps. In other cases, the analysis shows traffic patterns that conflict with what Waze is expecting but the analysis isn't conclusive enough to effect an automatic change. In these situations Waze generates a problem indication to prompt editor review. In these cases, the editor should further analyze the problem. Most of the time, no action will be warranted and the error should just be marked "Not identified". In some cases, there may be an improper turn restriction that needs to be corrected. In a very few cases, a necessary road might be missing.
Some of the cases where no action is warranted:
- heavy traffic around fast-food restaurants that confuses Waze into thinking that a road is missing.
- erratic GPS readings/recordings indicating travel that does not follow an actual road.
- illegal through-traffic on private roadways.
Parking Lots, Private Roads, and Alleys
Waze is primarily a commuting app. Thus, adding lots of private roads, alleys, and parking lot lanes doesn't really help the app fulfill its main purpose. Instead, these decorative roads put a heavier load on the servers and make for confusing maps. These inappropriate roads can also cause routing problems-- e.g., sending a user through a parking lot or into an alley to get to a house or business that is best accessed from an actual street. Short private roads leading to one or two buildings, from one part of a field to another, or in/out of simple parking lots should be avoided.
When considering adding a non-road feature (i.e., a place), generally only actual landmarks should be added. A landmark is a place unlikely to change or require updates (e.g., parks, cemeteries, universities, major sports venues, major cultural institutions, etc.). Businesses (other than gas stations--see below) are best represented in the back-end GIS which is updated more systematically.
In addition, landmarks should be few and far between. Otherwise, the names on landmarks (depending on app settings, speed, etc.) can end up obscuring road names (In one case, an editor decided it'd be a good idea to make landmarks of every building on a dense university campus; this made it impossible to actually see the roads let alone the road names in the area of the university).
Too many landmarks also makes for visual clutter that can be distracting both in the app and in the editor, especially in denser areas -- the plethora of landmark information obscures the streets, which makes navigation (as well as editing) difficult.
As this quickly degenerates into a "where do you draw the line" situation, the convention is to take a zero-tolerance approach so that new editors aren't confused and enticed into mapping every business, elementary school, post office, etc. Generally any landmark that isn't a park, cemetery, university, major sports venue or, major cultural institutions should be removed.
Once the need for a new Place has been determined, creation/placement should follow the Places guidelines.
Unlike other businesses, gas stations are mapped, since they are used for the gas price feature. If you find a station mapped to the wrong location, drag it to the correct location by pulling the handle (circle in the middle) to the right spot. Check to make sure the brand is correct and change the name to Title Case if necessary. It is not necessary (and is undesirable) to expand the station's outline larger than the small default rectangle -- this keeps the station from appearing as a polygon in-app (thus minimizing visual clutter).
Generally, if a route can't be driven on (e.g., it's a walking trail, railroad, airport taxiway) then it shouldn't be mapped in the Waze editor. In particular, walking trails should be removed, especially if they intersect with actual roadways. Because of the routing mechanism, it's conceivable that user could be misdirected to drive to/on a walking trail when trying to reach a destination.
Exception: passenger rail lines (e.g., RTA, Amtrak, etc.) may be mapped in order to discourage paving by riders. Rail segments should never intersect with any drivable segment. See the US railroad mapping instructions for best practices on how to map a railroad.
Marking temporary changes
When making a change to the map to reflect temporary road closure/restrictions, make a note of the change in a prominent position adjacent to the changed roadway. A good way to do this is by creating a problem report from the LiveMap (click on the "Live Map" link from the editor, then click in an area adjacent to your change and click on "Report a problem") and leave a note for subsequent editors (e.g., something like "BRIDGE OUT UNTIL AUGUST 2024 per http:
//odot/some-such-page. PLEASE DO NOT DELETE UNTIL ROADWAY IS RESTORED" -- with the last bit to help discourage new editors from erroneously "solving" the UR).
If the temporary change will last more than a few weeks and/or is in an area that isn't actively managed, consider adding it to the Ohio/Construction page.