Closed jinalfoflia closed 7 years ago
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
@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:
The existing tagging scheme for conditional turn restrictions is of the format:
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.
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:
restriction=conditional
tag (new scheme)hour_on=*
or hour_off=*
tags (existing scheme). Of these:
restriction:conditional=*
and no timing informationIn order to have a consistent tagging scheme, I'll be following the workflow mentioned below:
restriction=*
tag with a new restriction:conditional=*
tagrestriction: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
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)
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.
restriction:conditional=*
tag) currently present in SF: 106
Of these:
restriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00)
)restriction:conditional=*
tag was added to 86 restrictions as a part of the first passrestriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00)
)
restriction:conditional=*
. For these two, I have removed the restriction:conditional=*
tagI 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
@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
Here is the work-flow that we followed to add turn restrictions on OpenStreetMap using Mapillary.
/cc @planemad @shvrm @oini @lxbarth @srividyacb @ramyaragupathy
@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.
@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 😸
@gyllen Just checked that the signs are now loading at z14.
This makes our search 👀 through the map much easier. Thanks a lot! 😺
@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.
@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
By the way you will also need a Mapillary client_id for those tiles
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
@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.
@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.
@kepta, this should interesting for you since you've worked on a similar thing in iD.
@maning which tool are we using here.
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
@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.
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
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.
@AndrewSnow thank you for the special effort ❤️
No next actions here, closing this.
Lets focus on improving OSM for routing in SF which has a very dense Mapillary coverage and detected turn restrictions.
Objectives
Features
type=restriction
+restriction=*
: No U-turn, no left turn, no right turnProject spreadsheet
Workflow
Caution 🚨
no-right-turn
. This is NOT a turn restriction, always ask if in doubt.Special cases
restriction:conditional=no_left_turn @ (Mo-Sa 07:00-09:00,16:00-18:00)
Reference
Changeset
Updating missing turn restrictions in SF using Mapillary https://github.com/mapbox/mapping/issues/177
Bing;Mapillary
cc @mapbox/team-data