Difference between revisions of "Ohio/Mapping conventions"

From Wazeopedia

< Ohio

(New page: =Mapping conventions around Ohio= The following practices and techniques are used around ohio. ==Dealing with system-detected problems== Waze is constantly analyzing tracking information g...)
 
m (Mapping conventions around Ohio)
Line 1: Line 1:
 
=Mapping conventions around Ohio=
 
=Mapping conventions around Ohio=
The following practices and techniques are used around ohio.
+
The following practices and techniques are used around Ohio.
 
==Dealing with system-detected problems==
 
==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.
 
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.

Revision as of 06:48, 28 September 2012

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.