Mapping turn restrictions using Mapillary in San Francisco

[jinalfoflia]

Lets focus on improving OSM for routing in SF which has a very dense Mapillary coverage and detected turn restrictions.

• Area SF City, work down list of highest traffic roads with maximum probability of turn restrictions
• Timeline 5 days
• Team @oini @jinalfoflia @shvrm @planemad @ramyaragupathy @srividyacb

Objectives

• Use Mapillary vector tiles to add missing turn restrictions, access restrictions and speed limits on OSM
• Determine the acceptance criteria for complete mapping coverage for routing in an area using available data sources
• Estimate data gaps in Mapillary data to achieve acceptance criteria for complete routing coverage

Features

• Turn Restrictions type=restriction+restriction=*: No U-turn, no left turn, no right turn

Project spreadsheet

Workflow

• Use the spreadsheet to to pick a street to review and track progress
• Use the Mapillary vector tiles to review each junction on the road
• Analyze the Mapillary street view coverage of the junction, validate existing turn restrictions and add missing ones

Caution 🚨

• Be careful with interpreting signage and don't blindly follow Mapillary. This is a sign for no free right that Mapillary interpreted as no-right-turn. This is NOT a turn restriction, always ask if in doubt.
  
• The location and bearing of the Mapillary photo is not reliable and is prone to usual GPS errors. Cross check the photograph with the map to confirm you are looking at the intersection from the correct bearing. This photograph is facing the reverse of actual heading.
  
  
• Mapillary will detect only one sign type per image. Lookout for multiple restrictions in the photograph
  
  

Special cases

• Conditional restrictions during peak hours are common in SF. Tag them as restriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00)
  
• Conditional restriction during baseball games. Ignore
  
  

Reference

• OSM tags for routing http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing
• Turn restrictions http://wiki.openstreetmap.org/wiki/Relation:restriction
• Access restrictions http://wiki.openstreetmap.org/wiki/Key:access
• Conditional restrictions http://wiki.openstreetmap.org/wiki/Conditional_restrictions

Changeset

• Comment Updating missing turn restrictions in SF using Mapillary https://github.com/mapbox/mapping/issues/177
• Source Bing;Mapillary

cc @mapbox/team-data

[ramyaragupathy]

Came across a different type of condition for a turn restriciton, other than the one mentioned in the ticket.
Marking this as restriction:conditional.

cc @jinalfoflia @srividyacb @oini @planemad

[planemad]

@ramyaragupathy good example, i'm leaning towards adding this as a regular restriction since it applies for all regular personal vehicles.

Lets add a conditional restrictions when the restriction is conditionally applied to a private vehicles:

• On certain times of the day. eg. Restriction during peak hours 7AM-10AM
• On a certain day of the year. eg. Restriction on baseball game days only

[oini]

Updating conditional turn restrictions

The existing tagging scheme for conditional turn restrictions is of the format:

_[wiki](http://wiki.openstreetmap.org/wiki/Relation:restriction#Tags)_

The proposal from the team is to use a more concise tagging format as per this wiki commenti:

restriction:conditional=no_left_turn @ (Mo-Fr 07:00-10:00,15:00-19:00)

This format follows the well documented convention for conditional access restrictions.

Migrating existing restrictions

The existing conditional turn restrictions using the old format will be queried and a new restriction:conditional tag will be added using information from the other keys hour_on hour_off day_on day_off. None of the the existing tags will be modified

Querying Overpass in SF, we found that currently there are:

• 22 relations with the restriction=conditional tag (new scheme)
• 92 relations with any of hour_on=* or hour_off=* tags (existing scheme). Of these:
  • 6 relations have the restriction:conditional=* tag
  • 86 relations have the restriction=* tag
• 17 relations with restriction:conditional=* and no timing information

In order to have a consistent tagging scheme, I'll be following the workflow mentioned below:

• As a first pass, I'll work on updating the 86 relations having the restriction=* tag with a new restriction:conditional=* tag
• Once done, we'll work on each of the relations with the restriction:conditional=* tag and add the timings for each from the Mapillary images or the already existing hour_on=*, hour_off=*, day_on=*, day_off=* tags following the current format. For example, restriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00).

cc @planemad @lxbarth @jinalfoflia @shvrm @maning @srividyacb

[oini]

The 86 relations having the restriction=* tag have been updated with a new restriction:conditional=* tag in this changeset: http://www.openstreetmap.org/changeset/39119075

Next Action: Each of the 103 restrictions with the restriction:conditional=* tag but lacking the timing information according to the new tagging scheme will be reviewed and the timing information will be updated in the following format: restriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00)

[oini]

I have manually inspected each of the 103 restrictions with the restriction:conditional=* tag that lacked the timing information according to the new tagging scheme.

Current State of Conditional Turn Restrictions on OSM

• Total number of Conditional Turn Restrictions (restriction:conditional=* tag) currently present in SF: 106
  Of these:
  • 87 have both the restriction=* and restriction:conditional=* tags
  • 19 Conditional Turn Restrictions have only the restriction:conditional=* tag

State of Conditional Turn Restrictions before the modifications

• Conditional turn restrictions already present on OSM: 88 Of which:
  • 5 already had the timing information added according to the new tagging scheme (restriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00))

Modifications made to the Conditional Turn Restrictions

• Conditional turn restrictions added by the team: 18
• restriction:conditional=* tag was added to 86 restrictions as a part of the first pass
• timing information was added to 101 following the new tagging scheme (restriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00))
  • Of the 103 restrictions that were inspected, 2 were incorrectly tagged as restriction:conditional=*. For these two, I have removed the restriction:conditional=* tag

Other Observations

I came across the below instance where the restriction is applicable only on School Days. Per discussion with @planemad I added the restriction for Monday - Friday

cc @shvrm @lxbarth @jinalfoflia @srividyacb @ramyaragupathy

[planemad]

@gyllen The Mapillary detected sign layer has been super useful in adding turn restrictions to OpenStreetMap. Is there any way that certain important signages can show up at a lower zoom level than z16? This will allow quickly eyeballing an entire city instead of zooming in.

https://www.mapbox.com/bites/00249/#16.94/37.76504/-122.41987

cc @oini @jinalfoflia @geohacker

[jinalfoflia]

Here is the work-flow that we followed to add turn restrictions on OpenStreetMap using Mapillary.

/cc @planemad @shvrm @oini @lxbarth @srividyacb @ramyaragupathy

[gyllen]

@planemad Would up to 14 help?

Also we have a full set of pngs for signs if you need it. Will make it more visible than text.

[planemad]

@gyllen z14 would be a definite improvement 👍 Since we're using GL, svg icons would be most convenient. Was planning on assembling them with traffico, but this just ended up much quicker 😸

[oini]

@gyllen Just checked that the signs are now loading at z14.

This makes our search 👀 through the map much easier. Thanks a lot! 😺

[planemad]

@gyllen can you let us know if the mapillary-vector.mapillary.io supports https? We currently end up redirecting using crossorigin.me and thats not very reliable.

[gyllen]

@planemad You are using our test tiles now, we are rewriting our API so all spatial data will be served as vector tiles. This will for sure support https. Will let you know as soon as we are done, meanwhile I have two questions

1. What tool are you using above?
2. Now is the time if you have any feedback of anything you miss in the tiles.

By the way you will also need a Mapillary client_id for those tiles

[oini]

Now is the time if you have any feedback of anything you miss in the tiles.

@gyllen The traffic sign detection algorithm that you are using is commendable as even very tiny, badly angled or lit up signs have been identified. Although, while investigating the detected traffic signs in NYC, I came across a couple of instances where the image that was identified to contain a turn restriction, actually had none in it. For example:

Another thing that we often notice is that the traffic signs have blurred out parts which makes it difficult for us to identify the exact traffic information that the sign contains. Would it be possible for us to hit an end API with images having un-blurred signs? Also, it would be great to have the Traffic Sign detection at z10/z12 and a way to identify if one image has more than one detected traffic sign. Thanks again! 😸

cc @planemad @maning

[gyllen]

@ybkuang Is this a well known problem in our detector?

@oini I can see what I can do with the some levels. I will make sure that all detected signs in one image is listed.

[gyllen]

@oini @planemad @maning Have you guys thought about integrating MapillaryJS to the planemad viewer -> https://github.com/mapillary/mapillary-js

If you do that you would be able to try to move closer to an object. Also be able to zoom and navigate panos. Here is an easy example of MapillaryJS integrated http://mapillary.github.io/mapillary-js-examples/highline/ we also have a tagging system going, http://blog.mapillary.com/update/2016/05/19/mapillary-js-tagging.html

Will be used for tagging feedback so we can train better.

[maning]

@kepta, this should interesting for you since you've worked on a similar thing in iD.

[kepta]

@maning which tool are we using here.

[maning]

Related to false detection, today, I encountered a shop sign that was detected as a turn restriction. The 🎯 sign seems to be detected as a turn restriction.

See below:

@gyllen

[ybkuang]

@oini The false blur is due to errors of the face/license plate detectors. We will work on improving that. Right now, you will have to request an un-blur and look at the photos again once un-blur is done. @gyllen , can we figure something easier UI wise?

@maning The target sign confuses the traffic sign detector. We are doing an iteration of US signs improvement. This should be fixed once the new version is out.

[jinalfoflia]

The false blur is due to errors of the face/license plate detectors. We will work on improving that. Right now, you will have to request an un-blur and look at the photos again once un-blur is done.

Oh this is great @ybkuang! Is there a specific procedure to request for un-blur images?

/cc @planemad @gyllen

[AndrewSnow]

Realize this was a commercial MBox effort and most likely you have moved on, but wanted to let you know that after stumbling on to it and noting the intersections of interest where you had no data, I set out on my E-bike to fill in as many as I could. Didn't note many new restrictions except the ones you would expect at intersections with one way streets.

@ybkuang You may want to set a detection rule that triggers a review for speed limits above 70 in the US. In the new data I uploaded, I saw at least two register as detecting an 85 mph limit on a city street.

[planemad]

@AndrewSnow thank you for the special effort ❤️

[jinalfoflia]

No next actions here, closing this.