Mapping turn lanes for navigation in 30 cities in US

abhisheksaikia commented 8 years ago

Objective: Map missing turn lanes from secondary and up in 30 US cities.

turnlanes

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

Source	Description	Quality	Coverage	License
Mapbox Satellite	Imagery	Intermediate	Good	:white_check_mark:
Bing Imagery	Imagery	High	Good	:white_check_mark:
USGS large scale imagery	Imagery	High	limited	:white_check_mark:

Tasks

Location	Start	End(ETA)	Validation
San Francisco	05/5/2016	05/11/2016	Done
Portland	05/16/2016	05/17/2016	Done
Dallas & Fort Worth	05/18/2016	5/23/2016	Done
New York	05/23/2016	05/30/2016	Done
Detroit	05/30/2016	06/02/2016	Done
Houston	06/03/2016	06/09/2016	Done
Philadelphia	06/08/2016	06/15/2016	Done
Baltimore	06/15/2016	06/16/2016	Done
Oklahoma	06/22/2016	06/22/2016	Done
Boston	06/22/2016	06/27/2016	Done
Denver	06/28/2016	06/29/2016	Done
Seattle	06/29/2016	07/01/2016	Done
Chicago	07/01/2016	08/05/2016	Done
San Diego	08/08/2016	08/10/2016	Done
Austin	08/10/2016	08/11/2016	Done
Phoenix	08/11/2016	08/18/2016	Done
DC	23/01/2017	30/01/2017	Done
LA_exterior	13/02/2017

JOSM Workflow

Setup

Activate the following in from JOSM preferences > Map Settings
- Map Paint Styles: Lanes and road attributes
- Tagging Presets: lane attributes
Filter out non road features with boundary: | leisure: | landuse: | waterway: | amenity: | natural: | building:
Add inverse filter: highway=motorway|trunk|primary|secondary|*link|motorway_link or untagged
Read http://wiki.openstreetmap.org/wiki/Key:turn:lanes
Read https://github.com/mapbox/mapping/wiki/Mapping-guide-for-turn-lanes-from-imagery
Install the 🔪 tool in JOSM to easily split the roads: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Knife-tool

Mapping

Check the roads for turn lanes at exits and entry points
Split the road into segments based on the total number of lanes for the segment
For each road segment tag the turn lanes based on the road markings in the direction of the way. Eg. turn:lanes=left|through|right. See OSM turn:lanes
For bi-directional segments, use turn:lanes:backward= and turn:lanes:forward= to specify turn lanes in each direction.
Verify correct tagging using the Lane attributes style
Issues to keep in mind:
For QA and edge cases in turn lanes mapping and how to handle them(parking lanes, splitting roads for start and end of turn lanes, handling of dual carriageways, etc) look into the QA for turn lane data document.

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

abhisheksaikia commented 8 years ago

Capturing the initial estimates for turn lanes mapping sprint in top 30 US cities:

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)

Optimizing the workflow and initial time estimates:

These statistics are heavily dependent upon our LA turn lanes mapping sprint. LA had a very high density of turn lanes in even primary, secondary and tertiary roads which is generally not the case in other cities. This will immediately lead to a reduction in our mapping effort.
Optimizing the JOSM toolset to help map turn lanes better: a knife tool for quick splitting of road segments in turn lanes mapping, a JOSM plugin that automatically sets the first lane as left and also automatically predicts the turn lane scheme for the next junction, once a junction has been tagged.
This time estimate also does not include the amount of time taken for validation. As 30 cities will be a huge mapping project, we need to find faster and better ways of validating turn lanes than the traditional method of validating tasks in the tasking manager.

Next actions:

[x] @planemad to work with @samely and @Rub21 and create the turn lanes mapping tools to optimize our mapping effort.
[x] @jothirnadh and me to capture and update daily statistics for turn lanes mapping in each city and consequently review our timeline based on the mapping speed by our team for the first 2 cities (Portland and San Francisco).

cc @mapbox/team-data

abhisheksaikia commented 8 years ago

@mapbox/team-data have completed adding turn lanes in SF Bay area.

Final Statistics in SF bay area turn lanes mapping sprint(excluding validation):

Total number of working days: 4
Average number of mappers working per day: 12 (average 6 hours per day)
Total number of personal hours by the team: 288
Total number of turn lanes mapped: 10,977
Turn lanes/mapper/hour: ~ 38 turn lanes
Total existing turn lanes in SF bay in OSM: 15386
Total area covered in SF bay: 1925.66 square kilometers
Turn lanes density in San Francisco Bay area: ~8 turn lanes/square kilometer

Observations:

The mapping speed for @mapbox/team-data has increased from an estimated 25 turn lanes per mapper per hour to 38 turn lanes per mapper per hour.
The Turn lanes density in SF is ~8 turn lanes/sq. km, down from our initial estimate of 10 turn lanes per square kilometer.
This will immediately lead to a significant reduction in our initial mapping estimate of 100 working days for 30 cities. The estimate can be reviewed based on the average of density of turn lanes we get from the first three cities we map.

Next Actions:

[x] @mapbox/team-data to complete validation of turn lanes in SF bay area.
[x] @mapbox/team-data to start turn lanes mapping in Portland
[x] @jothirnadh and me to update this mapping ticket with updated workflow and initial status of Portland City coverage: missing highways, turn lanes coverage, satellite imagery coverage.

abhisheksaikia commented 8 years ago

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.

We are going to map all turn lanes from secondary and up instead of tertiary and up. *Use this inverse filter: `highway=motorway|trunk|primary|secondary|link|motorway_link`**
Use the knife tool for quick splitting of ways: Steps for activating the Knife tool

cc @mapbox/team-data

jothirnadh commented 8 years ago

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

jothirnadh commented 8 years ago

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:

Turn lanes added by the Peru and India teams combined during the sprint: 10,323
Turn lanes added by the community during the sprint: 674

cc:/ @mapbox/team-data

abhisheksaikia commented 8 years ago

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

oini commented 8 years ago

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.

screen shot 2016-05-16 at 4 12 49 pm

screen shot 2016-05-16 at 4 13 00 pm

oini commented 8 years ago

Another Observation: Portland has pretty unclear satellite imagery (both Bing and USGS Large Scale Imagery).

screen shot 2016-05-16 at 4 24 56 pm

jothirnadh commented 8 years ago

The 🔪 tool is updated with the auto select way option as per this issue. Please do update your plugin with the following jar file and restart your JOSM to see the changes.

cc:/ @mapbox/team-data

jothirnadh commented 8 years ago

Portland Task Completion Summary

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.

Pre-mapping Checklist

We looked at satellite imagery coverage and assessed for clarity as this significantly impacts one's ability to clearly identify turn lanes :100:
We assessed the existing road network coverage to determine the number of roads under mapped :100:
We researched the presence of unmapped dual-carriageways to determine the extent to which roads need to be split so as to avoid creating conflicts when mapping turn-lanes 👍

Mapping roads classified as secondary and above

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.

Final Statistics in Portland turn lanes mapping sprint (excluding validation):

Total number of working days: 1
Number of mappers worked: 16 (average 6.5 hours per day)
Total number of people hours by the team: 104
Existing turn lanes before sprint: 193
Total number of turn lanes mapped during sprint: 2,823
Turn lanes/mapper/hour: ~24 turn lanes
Total area covered: 500.38 square kilometers
Turn lanes density: ~6 turn lanes/ square kilometer

Observations:

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.

Going Forward

we're kicking off adding turn lanes in the cities of Dallas and Forth Worth, Texas
we're kicking off researching the coverage of turn lanes, satellite imagery quality, and road network in New York city

We'll be posting details here, and welcome whomever is interested to join us in mapping turn lanes 😄

dobratzp commented 8 years ago

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.

planemad commented 8 years ago

@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

dobratzp commented 8 years ago

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.

dobratzp commented 8 years ago

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:

Number of lanes greater than *:lanes

For example, if you have lanes=2, then you should have 2 items in your various turn:lanes tags

oneway=yes together with turn:lanes:forward

Use turns:lanes and not turns:lanes:forward for oneway streets

dobratzp commented 8 years ago

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:

Download a short segment of road
Edit the turn lanes
Upload
Restart JOSM

planemad commented 8 years ago

@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

Number of lanes greater than *:lanes. We leave the lanes tag untouched and only focus on turn:lanes. The reasoning is that for a routing system the 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.
oneway=yes together with turn:lanes:forward. This is taken care of in our validation workflow. I just fixed 24 such cases in Portland using this overpass query.

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.

dobratzp commented 8 years ago

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.

osMatt commented 8 years ago

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.

abhisheksaikia commented 8 years ago

@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

abhisheksaikia commented 8 years ago

@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

abhisheksaikia commented 8 years ago

Dallas Task Completion Summary

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.

Improved Tooling

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.

Community participation

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:

There was a significant issue of breaking of turn restrictions and bus routes relations in Portland raised by @dobratzp. A separate ticket was created for this cleanup and @dobratzp reverted the broken relations to their previous versions.

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.
Wrong 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 query

Observations

The satellite imagery quality in Dallas and Fort Worth was not of the highest quality for adding turn lanes. For this purpose, imagery had to be alternated frequently between Bing, Mapbox and USGS satellite imagery for verification and mapping missing turn lanes.
The density of turn lanes was the lowest among all the three cities mapped till now: ~2.5 turn lanes per square kilometer but this advantage was offset by the relatively poor image quality and the need to eyeball a huge area (~2,653 square kilometers)

Going forward

The 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.

jothirnadh commented 8 years ago

New York task completion summary:

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.

Community participation

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.

Final Statistics in New York turn lanes mapping sprint (including validation):

Total number of working days: 6
Existing turn lanes before sprint: 49
Total number of turn lanes mapped during sprint: 7,731
Total area covered: 1827 square kilometers
Turn lanes density: ~4.5 turn lanes/ square kilometer

Observations

The Satellite imagery coverage in New York is good enough to map turn lanes. We stuck to Bing imagery for the entire task.
There are on an average of ~4.5 turn lanes per square kilometer in New York which is higher than the turn lanes in Dallas.
We encountered many missing highway links during the process of mapping turn lanes which can be covered in further mapping projects.

Going forward

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.

jothirnadh commented 8 years ago

Detroit task completion summary:

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.

Final Statistics in Detroit turn lanes mapping sprint (including validation):

Total number of working days: 4
Existing turn lanes before sprint: 225
Total number of turn lanes mapped during sprint: 2,409
Total area covered: 1125.22 square kilometers
Turn lanes density: ~2 turn lanes/ square kilometer

Observations

The Satellite imagery coverage in Detroit is good enough to map turn lanes. We stuck to Bing imagery for the entire task.
There are on an average of ~2 turn lanes per square kilometer in Detroit which is lower than the turn lanes in other cities that we mapped so far.

Going forward

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.

jothirnadh commented 8 years ago

Houston task completion summary:

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.

Final Statistics in Detroit turn lanes mapping sprint (including validation):

Total number of working days: 5
Existing turn lanes before sprint: 115
Total number of turn lanes mapped during sprint: 9,133
Total area covered: 3503.25 square kilometers
Turn lanes density: ~3 turn lanes/ square kilometer

Observations

The Satellite imagery coverage in Houston is not good enough to map turn lanes. We switched between Bing and USGS large scale imagery to map turn lanes for better guidance. This led us to invest a bit more time than usual to add a proper turn lane.
There are on an average of ~3 turn lanes per square kilometer in Houston which is lower than the average turn lanes in other cities that we mapped so far.

Going forward

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.

rickmastfan67 commented 8 years ago

"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. :/

abhisheksaikia commented 8 years ago

@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

Andygol commented 8 years ago

@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

👇

key turn openstreetmap wiki 2016-06-13 15-39-12

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

planemad commented 8 years ago

@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.

jothirnadh commented 8 years ago

Philadelphia and Baltimore task completion summary:

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.

Final Statistics in Philadelphia turn lanes mapping sprint (including validation):

Total number of working days: 5
Existing turn lanes before sprint: 178
Total number of turn lanes mapped during sprint: 2,823
Total area covered: 893.09 square kilometers
Turn lanes density: ~3 turn lanes/ square kilometer

Final Statistics in Baltimore turn lanes mapping sprint (including validation):

Total number of working days: 2
Existing turn lanes before sprint: 480
Total number of turn lanes mapped during sprint: 1,438
Total area covered: 671.21 square kilometers
Turn lanes density: ~3 turn lanes/ square kilometer

Observations

The satellite imagery(Bing) in both the cities is good enough to map turn lanes.
There are on an average of ~3 turn lanes/sq km in both the cities.

Going forward

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.

abhisheksaikia commented 8 years ago

Oklahoma and Boston Task Completion Summary

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.

Going forward

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.

drkludge commented 8 years ago

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.

Again thank you very much for your efforts.
The efforts are something that I can build on when the time comes.
Would you please consider putting your documentation in the tag? Right now you are working on turn lanes. You all have worked through many cases that have not been developed well at this point in the current OSM wiki page. However, I do not feel that I can take your github work and put the documentation in the wiki. Where my eyes have glazed over looking at the OSM turn lane page before, your work would be a great addition because of the clarity brought by a number of edits. That's something that can be built on. You may have to add the work in a section below the current tag documentation.
Would you please consider other tags that you have worked on in the past or future? Ditto for adding the documentation below the existing page doc.
Thank you for the JOSM plugin.

I'll have to give these features a whirl when I get a chance.

Regards, Greg

abhisheksaikia commented 8 years ago

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 :).

jothirnadh commented 8 years ago

Denver and Seattle task completion summary:

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.

Final Statistics in Denver turn lanes mapping sprint (including validation):

Total number of working days: 3
Existing turn lanes before sprint: 537
Total number of turn lanes mapped during sprint: 3,898
Total area covered: 1730.48 square kilometers
Turn lanes density: ~3 turn lanes/ square kilometer

Final Statistics in Seattle turn lanes mapping sprint (including validation):

Total number of working days: 3
Existing turn lanes before sprint: 1,159
Total number of turn lanes mapped during sprint: 4,839
Total area covered: 1584.34 square kilometers
Turn lanes density: ~4 turn lanes/ square kilometer

Going forward

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.

drkludge commented 8 years ago

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

RichRico commented 8 years ago

Chicago task completion summary:

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.

Final Statistics in Chicago turn lanes mapping sprint (including validation):

Total number of working days: 5
Existing turn lanes before sprint: 161
Total number of turn lanes mapped during sprint: 12,388
Total area covered: 1915.60 square kilometers
Turn lanes density: ~7 turn lanes/ square kilometer

Observations

There are on an average of ~7 turn lanes per square kilometer in Chicago which is higher than the turn lanes in Seattle and in other cities that we mapped so far.
The Satellite imagery coverage in Chicago is good, also we guided whith USGS Large Scale Imagery to map turn lanes.

Going forward

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.

RichRico commented 8 years ago

San Diego task completion summary:

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.

Final Statistics in San Diego turn lanes mapping sprint (including validation):

Total number of working days: 3
Existing turn lanes before sprint: 631
Total number of turn lanes mapped during sprint: 8,869
Total area covered: 1458.49 square kilometers
Turn lanes density: ~7 turn lanes/ square kilometer

Observations

There are on an average of ~7 turn lanes per square kilometer in SanDiego which is same than the turn lanes in Chicago.
The Satellite imagery coverage in San Diego is good, also we guided whith USGS Large Scale Imagery to map turn lanes.

Going forward

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.

RichRico commented 8 years ago

Austin task completion summary:

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.

Final Statistics in Austin turn lanes mapping sprint (including validation):

Total number of working days: 2
Existing turn lanes before sprint: 167
Total number of turn lanes mapped during sprint: 2,178
Total area covered: 1065.09 square kilometers
Turn lanes density: ~2 turn lanes/ square kilometer

Observations

There are on an average of ~2 turn lanes per square kilometer in Austin which is lower than the turn lanes in other cities that we mapped so far.
The Satellite imagery coverage in Austin is not good enough to map turn lanes. We switched between Bing and USGS large scale imagery to map turn lanes for better guidance

Going forward

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.

karitotp commented 8 years ago

Phoenix task completion summary:

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.

Final Statistics in Phoenix turn lanes mapping sprint (including validation):

Total number of working days: 4
Existing turn lanes before sprint: 94
Total number of turn lanes mapped during sprint: 13,841
Total area covered: 2226.58 square kilometers
Turn lanes density: ~6 turn lanes/ square kilometer

Observations

There are on an average of ~6 turn lanes per square kilometer in Phoenix.
The Satellite imagery coverage in Phoenix is good enough to map turn lanes.

Going forward

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.

drkludge commented 8 years ago

Please see my two issues that I have raised. You need to fix your process before moving to another city!

RichRico commented 8 years ago

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.

samely commented 8 years ago

@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.

anim

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.

Ref1 Ref2

Next action

[x] @mapbox/team-data stop working on turn:lanes
[x] @samely and @dannykath obtain a list of broken relations in all cities where turn:lanes were added and fix them.
[ ] @rub21, @planemad and @andygol find a way to avoid editing the same relations at the same time.

Andygol commented 8 years ago

per chat with @dannykath

This table contains list of route=bus relations that could be affected during working on adding turn:lanes.

https://docs.google.com/spreadsheets/d/1zlkn7IB2QtQwmeE-UBcEoH8_7DD1N2mbaCqyiYC0PdE/edit#gid=343191480

/cc @mapbox/team-data

samely commented 8 years ago

Great work @Andygol!

Andygol commented 8 years ago

@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;

drkludge commented 8 years ago

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.

planemad commented 8 years ago

@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.

drkludge commented 8 years ago

@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.

drkludge commented 8 years ago

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.

drkludge commented 8 years ago

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.

rickmastfan67 commented 8 years ago

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.

mapbox / mapping