Turn restrictions based on Mapbox machine learning models

[daniel-j-h]

We are releasing our initial turn restriction sign detections based on our internal machine learning models with more data to come in the future. Here is the raw data for the first batch of detections:

Map

GeoJSON

Our internal machine learning models are based on Bing StreetSide's imagery for which Mapbox acquired the rights to contribute off of. We do not own the imagery and therefore are not allowed to make it available for the OSM community.

I will write up a diary post with details in the coming days.

[daniel-j-h]

[daniel-j-h]

Diary post:

https://www.openstreetmap.org/user/daniel-j-h/diary/43242

[JakeSmarter]

Guys, before you run off mindlessly to the job, please be aware of what you are actually mapping: Turn restrictions or traffic signs denoting turn restrictions. In OpenStreetMap terms these are two totally different concepts!

• Traffic signs (traffic_sign=*) denote the legal situation on the road.
• Turn restrictions (type=restriction) model the flow of traffic.

Most importantly: DO NOT add default turn restrictions. This especially pertains to restriction=no_u_turn restrictions on single way junctions. Hence, do not add turn restriction relations with identical members in the to and from roles, like in this [bad example](). This kind of restriction=no_u_turn restriction is the default.

In these cases, if you still want to add data about this turn restriction to OSM—because it is veritably (via Mapillary etc) signed—then map with:

• traffic_sign=US:R3-4[! or traffic_sign=US:R3-18 with a node on the way
• direction=forward/backward depending on way direction and the direction of traffic flow this traffic sign applies to

alternatively

• traffic_sign:forward=US:R3-4/traffic_sign:backward=US:R3-4 or traffic_sign:forward=US:R3-18/traffic_sign:backward=US:R3-18 depending on way direction and the direction of traffic flow this traffic sign applies to

R3-4	R3-18

I have already contacted @bhousel and others from Mapbox about this common mistake. Any comments appreciated. See also #354.