Closed abhisheksaikia closed 6 years ago
According to the statistics that we generated during the LA turn lanes mapping sprint, this is the estimated timeline for completing the turn lanes mapping sprint in the full 30 cities:
Total area to be covered in 30 US cities: 37,545 square kilometers Estimated features to map: ~375,450 turn lanes in 30 US cities(~10 turn lanes per square kilometer) Turn lanes per person per hour:~25 Total number of team members working full time(6 hours per day): 15 Total estimated working days: ~100 working days(5 months)
left
and also automatically predicts the turn lane scheme for the next junction, once a junction has been tagged.cc @mapbox/team-data
@mapbox/team-data have completed adding turn lanes in SF Bay area.
As part of our discussion with @planemad @maning @jothirnadh on optimization of workflow for adding turn lanes, the following changes are made to the workflow which we will follow while mapping turn lanes in Portland and all further tasks in the turn lanes mapping sprint.
secondary and up
instead of tertiary and up
.
*Use this inverse filter: `highway=motorway|trunk|primary|secondary|link|motorway_link`**cc @mapbox/team-data
Portland City coverage: missing highways, turn lanes coverage, satellite imagery coverage.
I did an overview of the roads mapped in Portland City. The city seems to be well mapped and the quality of the satellite imagery (Bing) is good for mapping turn lanes.
CC:/ @abhisheksaikia @maning
Updating the statistics in SF bay (Stats excluding validation) from above, and providing a team wise breakup of the mapping stats between India and Peru teams:
Team | Average hours per mapper/day | Average number of mappers per day | Turn lanes added by team | Turn lane per mapper/hr |
---|---|---|---|---|
Bangalore | 5 | 6.25 | 2071 | ~17 |
Peru | 8 | 5.75 | 8252 | ~45 |
The statistics of turn lanes added during the SF bay sprint:
cc:/ @mapbox/team-data
Updating the inverse filter to include all roads until secondary (including all road links), according to our revised workflow: highway=motorway|trunk|primary|secondary|*link|motorway_link
The reason is that we have a high density of tertiary roads to review but a low density of turn lanes per km that can be mapped.
cc @mapbox/team-data
We're skipping adding turn lanes to situations where the lanes are marked by yellow lines on both sides. These are probably turn-lanes-bothways.
Another Observation: Portland has pretty unclear satellite imagery (both Bing and USGS Large Scale Imagery).
We wrapped up mapping turn lanes in the Portland area and added a total of 2,823 turn lanes. The approach to mapping in Portland was different from the work we did in San Francisco, and we only covered roads that were classfied as secondary and above. Here is a full summary of our approach, and results. We welcome feedback on our approach, and suggestions for improving this workflow.
We decided to focus on adding turn lanes on roads classified as secondary or above after our research showed that a majority of turn lanes are present on such roads, and tertiary roads and residential streets have minimal to no turn lanes to map. This also helped us keep the scope of the mapping effort more focused.
The overall mapping speed for adding turn lanes in Portland decreased from our experience mapping turn lanes in Los Angeles city. This decrease can be attributed to a higher density of turn lanes present in LA which made it faster to identify turn-lanes overall.
We'll be posting details here, and welcome whomever is interested to join us in mapping turn lanes ๐
Especially when doing large-scale editing of roads, be careful when splitting and combining Way objects. These Way objects may be members of road route relation and/or public transport route relations. The order of the Way objects within the Relation is significant.
@dobratzp this is a really serious issue since we do get conflicts on route relation members when working across cities. Sadly the JOSM relation conflict mechanism does not make it very easy to properly resolve them and I suspect relations worldwide are breaking everyday since we do not yet have a usable conflict management and integrity checking interface for all relations on the map.
From our end, the team tries to be really careful when working on roads with relations, but we're lacking a good QA workflow to ensure nothing is broken once the task is complete. For starters, we will ticket out suggestions to improve the intelligence of conflict management in JOSM so that it can suggest a resolution. Would be great to hear your thoughts as well on how this could be done.
cc @mapbox/team-data
I agree that it seems like JOSM doesn't always do the right thing when you are splitting Ways as far as bus routes and turn restrictions go. If all I had to do was fix a few bus routes by making them contiguous again, it wouldn't be so bad.
I started the process of fixing Portland area bus routes, but then I realized just how bad Changeset 39375345 is really is. There are few duplicate Way objects, which are fairly easy to remedy. However, there are a number of relations which are completely broken.
I'm not sure how you even managed to do this. Somehow, you've replaced the members of all of the following relations with the same members from Bus Route 52: Portland Community College Rock Creek => Beaverton Transit Center
Some of these are bus route relations and some of them are turn restriction relations.
Also, all of the members of Bus 52: Beaverton Transit Center => Portland Community College Rock Creek have been deleted.
Unfortunately, I can't cleanly revert Changeset 39375345, so I may have to ask for help with the Data Working Group.
Before I got to the mess of Changeset 39375345, I did want to mention a few JOSM warning that you should definitely be paying attention to as they relate specifically to turn lanes:
For example, if you have lanes=2, then you should have 2 items in your various turn:lanes tags
Use turns:lanes and not turns:lanes:forward for oneway streets
I'm wondering if end up having multiple people editing different portions of the same route relation at the same time and you are getting conflicts. I would suggest making changeset that are much smaller than what you are currently doing:
@dobratzp Looking into https://www.openstreetmap.org/changeset/39375345 its really strange, would be useful to know how it might have happened, @poornibadrinath any ideas?
Validation
turn:lane
information would override the lane information when present since they may not always be consistent as in this case. Its also an open question if turn lanes should be considered as a full width traffic lane as per the OSM wiki. This is also easily fixable via an automated edit at any point when required.Avoiding relation conflicts Making small changesets will not completely eliminate the issue since two members working on some part of a long route relation is still quite high. The only way to guarantee no conflicts is for no one else to edit in the same city simultaneously. The long term solution maybe smarter conflict resolution on the software side since it is extremely easy for a human to break relations with the current tools, even for advanced mappers with no easy mechanism to restore them either.
It seems like there is some inconsistency in how you are tagging turn lanes. Sometimes you use "none" and sometimes not. For example:
||left
vs. none|none|left
Are these values equivalent for turn:lanes? If so, please standardize on one for consistency.
While I was looking for some recently added left turns at intersections, I noticed a wrong turn lane tagging. It should be possible to check for these systematically with an overpass query. http://www.openstreetmap.org/way/419223674 is tagged with ||left|
. Pattern to check: the turn lane string does not start with left, but there is some left turn after a pipe symbol. It is very unlikely to have a left turn lane that is to the right of a lane that is not tagged at a left turn lane.
@dobratzp I have run a overpass query to determine the number of turn lanes that have none
in the tag and it comes out to 278 in Portland.The query is: http://overpass-turbo.eu/s/gnF. Both left||
and left|none|none
are used widely as seen here: http://taginfo.openstreetmap.org/keys/?key=turn%3Alanes&filter=ways#values. Also the Lane and road attributes
style appears to take both these styles of tagging as equivalent. But thanks for bringing this up. From now on we will standardise this for consistency and stick to the style of left||
instead of left|none|none
.
cc @mapbox/team-data
@osMatt I have run a overpass query in Dallas for all the turn lanes containing left
but not starting with left
. At present it shows all the turn lanes that does not start with l
. It can be modified to include only those turn lanes which start with |
. For now, it's showing 196 suspicious ways, which will be eyeballed and validated during our validation work. Thanks for pointing this out. This and other common errors like oneway-yes
with turn:lanes:forward
and turn:lanes:
backward` is definitely something we need to validate and correct en masse once each city is completed. Have opened a ticket documenting these issues here: https://github.com/osmlab/osmlint/issues/109
We wrapped up mapping turn lanes in Dallas and Fort Worth and added and validated a total of 6,267 turn lanes in Dallas. The total turn lanes count in Dallas after the sprint is 6622 at present. Similar to our approach in Portland we only focused on adding turn lanes to roads classified secondary and above.
We regularly used the knife tool for quick splitting of ways while adding turn lanes. Give it a try and share any feedback you have for improving it.
We got a lot of help from OpenStreetMap contributors for this sprint, especially when it involved validating the data we added. Here are a few examples of this:
We have tightened up our validation work based on feedback received to clean up two common errors en masse:
Oneway=yes
mixed with turn:lanes:forward
and turn:lanes:backward
by using this overpass query for cleanup.left
turn lane tagging: The suspicious turn:lanes
which have a left
after a |, through or right
can be cleaned up by using this overpass queryThe team will continue adding turn lanes in New York. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
We wrapped up mapping turn lanes in New York and added a total of 7,509 turn lanes. The total turn lanes count in New York after the sprint is 7780 at present. Similar to our approach in Dallas and Fort Worth we only focused on adding turn lanes to roads classified as secondary and above.
As per the community suggestions in our Portland task we tried to be more concrete wihile mapping turn lanes on the roads with pre existing relations.
The team will continue adding turn lanes in Detroit. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
We wrapped up mapping turn lanes in Detroit and added a total of 2,409 turn lanes. The total turn lanes count in Detroit after the sprint is 2,634 at present. Similar to our approach in New York we only focused on adding turn lanes to roads classified as secondary and above.
The team will continue adding turn lanes in Houston. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
We wrapped up mapping turn lanes in Houston and added a total of 9,133 turn lanes. The total turn lanes count in Houston after the sprint is 9,248 at present. Similar to our approach in Detroit we only focused on adding turn lanes to roads classified as secondary and above.
The team will continue adding turn lanes in Philadelphia. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
"none" is a completely valid tag in "turn:lanes*". It's needed to tell people how lanes are splitting properly. I've seen SEVERAL of my turn lane edits in Pittsburgh, PA messed around with today, even though you didn't mention above that you'd be editing in this area.
"turn:lanes:backward=none;slight_right" is a completely valid tag telling people that the section of highway is splitting into 2 lanes for that direction and telling them which side the new lane is being added to. You need to look at the adjacent way(s) or the satellite imagery first instead of just thinking, "oh, this has to be wrong and I need to fix it". This is one way to really upset local mappers.
I would recommend stopping this immediately till this is rectified, as you're damaging the data now.
Here's a few examples of this here in Pittsburgh: https://www.openstreetmap.org/changeset/39930495 https://www.openstreetmap.org/changeset/39934184 https://www.openstreetmap.org/changeset/39935935
Damaging valid data that I take awhile to get right like this makes me upset and getting closer to just stop editing in OSM if people who are getting paid are just going to come along and damage it as I can't keep up against 50+ edits a day verifying everything is correct in my local area. :/
@rickmastfan67 Thank you for pointing the issues out. We are constantly looking for feedback from the community on our mapping ticket. It was an oversight on our part to not capture the validation workflow with to-fix on this ticket. We are presently making sure that the edge cases documented by you are incorporated into the to fix task and will also make sure that all future validation work through to-fix will be properly documented and ticketed in public in the mapping repo.
cc @mapbox/team-data
@rickmastfan67
I highly appreciate your hard work on improving map data in your area.
But you allow yourself to judge tags values on your own. All values (none
, through
, left
, right
and so on) of turn:lanes
are valid but not all combination of them.
I've just re-read again description of turn:lanes
. Value none
is used only in this cases
- There are no turn indications on this lane.
- Used especially for better readability in case of many lanes
Based on this โ๏ธ, combination of none;slight_right
isn't valid.
For purposes that you described have to be used tag transit:lanes
, see example on Wiki-OSM - http://wiki.openstreetmap.org/wiki/Key:turn#Motorway_with_links_and_destinations
๐
I am so sorry that you have spent so much time to indicate places where roads are branching using a false picture of the application values of tag turn:lanes
.
It would be great if you consider the usage of another tag such as transit:lanes
for this purpose!
/cc @planemad @Rub21 @jothirnadh @abhisheksaikia
@rickmastfan67 do you think you can create an overpass query for the lanes you might have tagged like ๐ We could try migrating them to transit:lanes
.
We wrapped up mapping turn lanes in Philadephia & Baltimore and added a total of 2,823 turn lanes in Philadephia and 1,438 turn lanes in Baltimore. The total turn lanes count in Philadelphia after the sprint is 3,024 and 1,918 in Baltimore. Similar to our previous mapping approach we only focused on adding turn lanes to roads classified as secondary and above.
The team will continue adding turn lanes in Oklahoma. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
We wrapped up mapping turn lanes in Oklahoma and Boston. We have added and validated a total of 1613 turn lanes in Oklahoma and a total of 872 turn lanes in Boston. The total turn lanes count in Oklahoma and Boston after the sprint is 3226 and 911 at present.
We have also introduced a plugin called TurnLanes-tagging plugin for adding turn lanes in Java OpenStreetMap Editor (JOSM)
in a hassle free way during this time. The plugin intuitively provides presets for the most common, and recently used, turn lane combinations, and also automatically updates lane count based on the number of turn lanes for the road. You can install it from JOSM Preferences > Plugins > turnlanes-tagging
and restarting your JOSM. Please make sure that you check out the plugin and provide inputs and feedback on further improvements that can be made to it.
The team will continue adding turn lanes in Denver and Seattle. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
On Tue, Jun 28, 2016 at 12:37 AM, Abhishek Saikia notifications@github.com wrote:
We have also introduced an plugin called TurnLanes-tagging plugin https://www.mapbox.com/blog/turnlanes-tagging/ for adding turn lanes in Java OpenStreetMap Editor (JOSM) in a hassle free way during this time. The plugin intuitively provides presets for the most common, and recently used, turn lane combinations, and also automatically updates lane count based on the number of turn lanes for the road. You can install it from JOSM Preferences > Plugins > turnlanes-tagging and restarting your JOSM. Please make sure that you check out the plugin and provide inputs and feedback on further improvements that can be made to it.
Abhishek and et all MapBox Staff,
Thank you for these reports. I understand that they are important to your work because there is still a large question in some mappers view about these paid mapper efforts. It violates the "we always did it this way" method of doing business.
I'll have to give these features a whirl when I get a chance.
Regards, Greg
Hey @drkludge Thanks for the encouraging feedback and your suggestions. We have already gone ahead and added the turn lanes tagging
plugin to the wiki page. Currently we are reviewing and working on adding our documentation on turn lanes mapping and other tags we have used during this sprint to the wiki page. This will be done ASAP. Meanwhile please do keep reviewing our tools and keep the feedback coming on our tooling and processes :).
We wrapped up mapping turn lanes in Denver & Seattle and added a total of 3,898 turn lanes in Denver and 4,839 turn lanes in Seattle. The total turn lanes count in Denver and Seattle after the sprint is 4,435 and 5,998.
The team will continue adding turn lanes in Chicago. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
So I am now beginning to believe that there is a certain fragility with OSM relation. I think turn restrictions, lanes counts, bus routes or routes in general and perhaps a bug in the knife tool are at odds with each other. The problem could be how JOSM handles splitting ways so that you don't end up with a conflict with yourself during a relation change. The long story short is that the Phoenix/Maricopa County bus routes are being shredded right now with the turn lane changes that are being made right now. I have a list of the relations so that they can be repaired http://www.openstreetmap.org/way/436781523/history#map=15/33.4972/-112.1005&layers=T . I will be happy to pitch in and fix these after a way in complete. I don't know if you have a way of determining the order of ways, etc.
By the way, I think that this is great progress and thank you for your help in the Metro Phoenix area.
The problem almost feels like a whole way with history is deleted and a new way is created in its place. I wonder if this is the knife tool and JOSM interaction. Perhaps the knife tool is not considering the relations on a way when it splits a way. It also feels like JOSM requires a mapper to add the new way segment to replace the one way that existed before it was split in two. Would you please look into the problem?
Smile. I told a fellow mapper in email, "Hans, we should have labeled all of our roads as secondary." Again, it is nice having some fresh eyes editing roads in Metro Phoenix Arizona.
Thanks, Greg
We wrapped up mapping turn lanes in Chicago and added a total of 12,388 turn lanes. The total turn lanes count in Chicago after the sprint is 12,577 at present. Similar to our approach in Seattle we only focused on adding turn lanes to roads classified as secondary and above.
USGS Large Scale Imagery
to map turn lanes.The team will continue adding turn lanes in San Diego. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
We wrapped up mapping turn lanes in San Diego and added a total of 8,869 turn lanes. The total turn lanes count in San Diego after the sprint is 9,627 at present. Similar to our approach in Chicago we only focused on adding turn lanes to roads classified as secondary and above.
USGS Large Scale Imagery
to map turn lanes.The team will continue adding turn lanes in Austin. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
We wrapped up mapping turn lanes in Austin and added a total of 2,178 turn lanes. The total turn lanes count in Austin after the sprint is 2,345 at present. Similar to our approach in San Diego we only focused on adding turn lanes to roads classified as secondary and above.
The team will continue adding turn lanes in Phoenix. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
We wrapped up mapping turn lanes in Phoenix and added a total of 13,841 turn lanes. The total turn lanes count in Phoenix after the sprint is 14,069 at present. Similar to our approach in Austin we only focused on adding turn lanes to roads classified as secondary and above.
The team will continue adding turn lanes in Indianapolis. Join in if you are interested in mapping or let us know how we can improve the workflow at any time.
Please see my two issues that I have raised. You need to fix your process before moving to another city!
Hello @drkludge Sorry for the delay in the response, our team taking this as a serious issue and looking into it. We will get back to you soon with our finding.
@drkludge thank you for reviewing and fixing our edits. We identified the broken relation error is not related to the knife tool, as this maintains all relations in the new segment. See bellow.
We also did further analysis on this issue and found that due to the existing of many relations in Phoenix we have conflicts while editing roads that are part of the same relation. As we know the task manager allows us to work in a certain zone at the same time to avoid conflicts in highways, but we didn't consider that one relation can even cross over more than 10 blocks.
Two users made changes with few minutes apart
You are totally right, we need to improve our process before continue working on turn:lanes
. If you have a solution for this, please let us know so the process can be improved.
turn:lanes
per chat with @dannykath
This table contains list of route
=bus
relations that could be affected during working on adding turn:lanes
.
/cc @mapbox/team-data
Great work @Andygol!
@samely @dannykath
to get list of relation you can use overpass query similar to this:
[out:xml][timeout:25];
// fetch area โPhiladelphiaโ to search in
{{geocodeArea:"Philadelphia"}}->.searchArea;
// gather results
(
relation["type"="route"]["route"="road"](area.searchArea);
);
// print results
out ids;
Thank you for looking into to the issue. I wonder if the Phoenix issue is what happened in Portland Oregon? Portland is the poster child for a city that uses OSM and has extensive multi-modal routing support in their bus system. You may want to consider other relations. For example, USBR 90 is only 572 miles long. The one small segment in the southeast corner of the state that bypasses the mountains is as long as Indiana is wide. I believe Indiana will fit in other main segment 11 times. The route runs through several cities. I just looked at USBR 90 along Union Hills. It has problems too. There's a bus route along Union Hills that also must have issues in the same spots. The challenge with the cycle map is that it renders bi-weekly and sometimes only feels like weekly. Hence, I am just now seeing the broken route issues in the cycle map. The bus lines and other highway oriented relationships can have the same lengthy relations too. I peeked at AZ 87 that runs along Country Club but did not do a careful investigation of the whole highway route. The bus route looks okay but I'd have to look at AZ 87 closer.
Based on this review I believe that you will want to have tofix or your tasker look at relationships. I stopped using tofix along time ago. tofix has a race condition. It needs to take an item out of play for 24 hours--the length of time that OSM will keep a change set open. That's even if someone cannot fix the task. I think other MapBox editing staff complained about the issue but the author of the code did not understand the problem.
When @samely stated, "...but we didn't consider that one relation can even cross over more than 10 blocks...", now you are beginning to understand the big city/small city divide in OSM. MapBox and other providers need to enhance where the major markets are at. However, that leaves out a whole class of potential OSM contributors. Most of the map designs favor large cities verses small towns. Hours of Montana at 80 MPH looks like this picture verses hours of California at a snails pace.. It would be great if I could get a stop sign, yield sign(give way), mile post, or cattle guard(cattle grid) out in the land where towns only have one stop light for the whole city. Likewise, Phoenix fits into this small town oddity because of the massive urban sprawl that is consumed by Metro Phoenix. Note that all the tech conventions bypass Phoenix for San Francisco or San Antonio. The active mappers in Phoenix don't run into the editing conflicts that we have seen in this bug because we are so few and far between that I have only had three conflicts in the six plus years of OSM edits. Your turn lane edits were like we just had a stable base of mappers show up at the same time! I hope these descriptions of the vastness of the Rocky Mountains helps you understand the problem that you ran into. I am not surprised.
Would you please make your Google Doc readable to others outside of MapBox? I am happy to work on the the cleanup because the issue gives me a chance to go back through some of the major streets. I think that I'll be able to make better headway on the corrections because I understand the routes.
He!He! Did I tell you that I laugh snort when the arm chair mapping page says that I should visit everything I map? See even these OSM conventions and rhetoric are all geared toward large urban areas that have a stable population.
@drkludge appreciate your detailed feedback. We've been looking into this and the problem seems to stem from confusion using JOSM relationship conflict dialog. Opening a new ticket to investigate and track the cleanup.
@mapbox Do you have a better way of getting relation history than I do right now? I am getting timeouts from OSM. Here's the reason that I ask. North and South bound route 7 really got hammered. Here's the parent relation of the two routes: 4499305. I am thinking that it will be easier for me to get the history of all the route relations. Then I can edit the .osm file to add the original members back. Finally, I can add the new segments from the turn lane edits. In the case of bus route 7, one of the child relations was completely cleared out. I am guessing the empty route is generating the OSM time out. In the other child relation, only two members are left. I have the complete list of Maricopa County Bus route relations in the wiki. Would you be able to provide me history of these relations before the turn lane mapping started?
Also I repaired the USBR 90 bike route this morning.
geofabrik.de had an Arizona file back to 8/1/2016. It looks like MapBox wasn't in the valley until 8/12ish based on the WhoDidIT map and Project 56. That should speed the cleanup.
The good news is that I am able to repair the route with my regex of the osmosis member file. The even better news is that the bus route looks like it should with missing segments. The interesting news is that bus route 7 issues occurred before the lane expansion. Change set 41628004 repaired the north bound route.
Sounds like what happened here is that some of the Mapbox team didn't refresh the data on their end before continuing onto another road to add in turn lanes, thus creating the problems @drkludge mentioned above with the damaged relations. Looking at this screenshot that @samely posted above, it seems you aren't taking advantage of a major item in JOSM that helps to try to prevent stuff like this. The "Update Modified" tool (which I've personally pinned right beside the 'upload' button in the toolbar, Ctrl+Alt+M should be the shortcut for it) is something I ALWAYS use before even attempting to upload anything to the OSM database to help prevent any possible chance of a conflict. Normally, I never do get a conflict, but in the rare times I have, this has saved me from screwing anything up. And if what I did was a minor change, I just delete the layer, and restart with fresh data to prevent any problems. Otherwise, I do attempt to solve the conflict right there before attempting to upload.
Another tactic I've been using is whenever I have finished uploaded something (after of course doing the "Update Modified" before the upload), I always completely delete the data layer I was working on, and download a completely fresh copy of the area data before I continue on editing. This should always be done between uploads, and really should become second nature to ANY experienced OSM mapper using JOSM. This also helps prevents any problems when somebody else has uploaded a new version of a way/relation that they split since you downloaded the data from the OSM servers. For example, if somebody had just created a new relation that covers two ways, but it isn't in your copy of the data, and you split one of the ways in that relation? That's a great example of how the data can easily get broken and possibly create unintended gaps in relations that shouldn't be there. Sure, it might slow you down by 20 seconds or so between tasks, but would you rather spend an hour or more fixing relation data that got damaged because of not keeping the data synced on your end? I'd chose the 20 seconds over the hour myself. lol.
Objective: Map missing turn lanes from secondary and up in 30 US cities.
Team: @mapbox/team-data
Features to map: Turn lanes (motorway, trunk, primary and secondary) from satellite imagery
Focus Area: 30 top cities in US as per population
Available data sources
Tasks
JOSM Workflow
Setup
boundary: | leisure: | landuse: | waterway: | amenity: | natural: | building:
highway=motorway|trunk|primary|secondary|*link|motorway_link or untagged
Mapping
turn:lanes=left|through|right
. See OSM turn:lanesturn:lanes:backward=
andturn:lanes:forward=
to specify turn lanes in each direction.Lane attributes
styleIssues to keep in mind:
Changeset Comment:
Add missing turn lanes from satellite imagery https://github.com/mapbox/mapping/issues/180
Source:
Bing/Mapbox/USGS Large Scale Imagery
Turn lane mapping tickets: #144, #153