Ohio/Mapping conventions

From Wazeopedia

< Ohio

Revision as of 06:56, 28 September 2012 by Jhfrontz (talk | contribs) (Non-roadways)

Mapping conventions around Ohio

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. In most cases, 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 is missing.

Some of the cases where no action is warranted:

  • heavy traffic around fast-food restaurants confuses Waze into thinking that a road is missing.
  • erratic GPS readings/recordings indicate 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 puts a heavier load on the servers and make for confusing maps. The inappropriate roads can also cause routing problems-- e.g., sending a user through a parking lot 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.

Landmarks

When considering adding a non-road feature (i.e., a landmark), 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 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 in both in the app and in the editor, especially in denser areas -- the plethora of landmark information obscures the streets, which makes navigation 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.

Non-roadways

Generally, if a route can't be driven on (e.g., it's a walking trail, railroad, airport taxiway) then it shouldn't be shown in Waze. 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 directed to drive on a walking trail.

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. The easiest way is to make a non-directional railroad track and use the streetname to leave a note for subsequent editors (e.g., something like "BRIDGE OUT UNTIL AUGUST 2024")