Hi, j0hn33y!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
Many thanks for letting me know about the latest data and reverting my edits. According to the latest background, Nearmap, that we are used for edits, I didn’t notice any closures and construction works, so I decided to add roads.
Sorry for that and for any inconvenience these edits may have caused.
Best regards, Kate

Many thanks for your detailed investigation and such a responsible approach to resolving this issue. On my part, I can assure you that in the future we will try to take into account the specific features of local mapping when adding any elements to OSM.
We respect the 'access=destination' tag and use it when it is supported by the appropriate signs. In this case, the driver was directed to the gas station for a designated drop-off/pick-up, not by a navigation mistake. Therefore, the tag wouldn't prevent entry to the gas station for drop-off/pick-up.

Best regards, Kate

Hi,jhaluska80 !
My name is Kate, and I’m a mapper on the OSM team at Lyft.
Many thanks for informing us about the reverted changes.
I decided to add an implicit left turn restriction to the road near the gas station based on driver feedback. I considered that the left turn maneuver is unsafe according to the road markings and because there is a turning lane in the opposite direction.
I also have some doubts that the access=destination tag on roads near the gas station will work correctly for our navigation system, because we added the turn restriction not to exclude the possibility of driving through a gas station, but in order to avoid unsafe maneuvers and unforeseen situations in this area for our drivers.
Kindly inform us if the maneuver is indeed suitable for that location.

Best regards, Kate

Response
Hi, CjMalone!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
Many thanks for letting me know about this issue. I didn’t notice the warnings from OSM and ignored this mistake inadvertently. I have already changed it in the changeset - changeset/156386009.
Sorry for that and for any inconvenience these edits may have caused.

Best regards, Kate

Hi,Drunk501!
I recall our previous conversation on this topic.
However, in this case, I have opted to add a new road based on the
highly active Lyft-owned GPS tracks. These are automated pipelines that detect driver activity over the past two weeks. You can see it on images - https://drive.google.com/file/d/1BksbiIgg9ni_bpBMv4TEo0V-GDy0mt9g/view?usp=drive_link
Also, according to the information about the future situation in article -https://www.burnabynow.com/local-news/burnaby-approves-17-storey-tower-at-sfu-with-transit-hub-for-buses-7922772 the road that I added doesn’t contradict the planes. Therefore, I believe that adding roads in this area would be beneficial for OSM users.

Hi, CorruptComputer!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
Many thanks for letting me know about my mistake. I have already restored broken relation in changeset - changeset/153488007
Sorry for that and for any inconvenience these edits may have caused.
Best regards, Kate

Hi, jhaluska80!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
While working on the project, we received data that the certain tags which are important for routing have been changed recently. According to our workflow, we monitor edits with these tags in order to quickly identify and eliminate potentially incorrect and vandalized edits in OSM. We only make changes if we have sufficient evidence to justify fixing errors.
You can read more about Lyft's contributions to OpenStreetMap in this article - https://eng.lyft.com/keeping-osm-fresh-accurate-and-navigation-worthy-at-lyft-f27589ad1463

Best Regards

Thank you for the detailed explanation. I agree that VDOT's data should be considered more reliable than Wikipedia, especially since it was updated recently. It's interesting to learn about the common practice in Virginia.
I appreciate the clarification on this matter.
Best regards

Hi, Joseph R P!
Many thanks for sharing the link that you used for your edits.
I decided to restore the information about the "ref" tag according to the Wiki page describing route SR 124 - https://en.wikipedia.org/wiki/List_of_primary_state_highways_in_Virginia_shorter_than_one_mile#SR_124, that says that SR 124 goes between US 29 and Lorcom Lane.
Additionally, I noticed that the value of the "ref" tag for the road segments corresponds to the route relation - relation/1540478
Therefore, based on the above information, it seems appropriate to retain the "ref" tag.
Could you please share your thoughts according to your experience on whether it is common for a road number to end unexpectedly on a random segment rather than logically concluding at an intersection?
Thank you in advance for your insights.

Best regards!

Hi,Bendita Moreira!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
Many thanks for this feedback. After reviewing my edits I found a disconnected road and I have already fixed it in the changeset - changeset/151885492

In the changeset, I was primarily fixing the geometry of the roads and cycleways to prevent possible routing issues, and I'm not quite sure what points you're talking about. Are you referring to these points (node/3439363105)?
Currently, it is out of scope of our projects, and we try to avoid such fixes, on objects that do not affect routing and that are not added by our team.

Hi,Drunk501!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
Many thanks for letting me know about it. According to the latest background, Nearmap, that we are used for edits, I didn’t notice any closures and construction works, so I decided to add roads.
I apologize for that and for any trouble these changes may have caused.
Best regards, Kate

Hi, Spaghetti Monster!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
These changes were made according to the Nearmap background and Lyft telemetry data (automated pipelines that detect driver activity) https://drive.google.com/file/d/1Kf918N-_6oEkPv4FLyOy9N2zQp91nUMY/view?usp=drive_link
We realize the volume of the edits and understand the importance of releasing sources for review, especially for changes of this magnitude. We found GPS tracks activity in a different location which confirms the findings at official sources.

Many thanks for answering my question. We will take into account this information for further edits. I have added required tags for way/406459032 in the changeset changeset/147684399

HI, CRCulver!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
I made the decision to change the “lanes” tag for this short segment based on aerial imagery. According to the Lyft-owned street level image taken from Chapman Avenue in Dec '23 (33°47′20″N, 117°54′11″W).
https://drive.google.com/file/d/1LUjFOh8WKfNRN-ep4PNSziYDOawdG08C/view?usp=sharing there are 5 lanes and no evidence of lanes count changes.
If you have more actual information about the road situation in this segment, I would appreciate it if you share it with me, and then I will correct my edits as soon as possible.
Could you please explain in more detail exactly how the potential bugs that occur in Osmose may affect further mapping?
According to the OSM wiki there are no strong instructions that it is necessary to use tags ‘lanes:forward’=* and ‘lanes:backward’=* in combination with the lanes count tag for bidirectional roads -lanes=*#:~:text=in%20addition%20to%20the%20lanes%20tag.

Best regards, Kate.

HI, Hans Thompson!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
In this changeset I didn’t add the tag ‘access=private’ for Lockheed Ave, I have removed it only for the middle segment.
This tag was added long before my edits for most roads in this area (based on history the tag was added in 2007 by DaveHansenTiger https://pewu.github.io/osm-history/#/way/8910585) and in our practice, we try to avoid removing the tag ‘access’ from roads in the airport area without strong evidence.
Best regards!

Hi, Will!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
I agree with your point of view that there are no usual lane markings, but according to OSM wiki page - lanes=* it is not forbidden to add lanes tag in cases without lanes making, but the best practice will be added the tag ‘lane_markings=no ‘instead of removing the lanes tag.

While making changes I relied on the Lyft-owned images that were taken from Club View Drive in Dec,2023 (34°3′52″N, 118°25′22″W-https://drive.google.com/file/d/1t67VzDW7O4ppHS6S4cN78ic0t56aZ2ii/view?usp=sharing) with indirect new road markings ‘Ahead Stop’ and ‘Stop/Bumps’ in other place (34°3′54″N, 118°25′24″W - https://drive.google.com/file/d/1bKHHK7dUh7SrBq8GB2-lqxTHpgOuAg6b/view?usp=drive_link), also the road surface has recently been changed on this street and perhaps the road markings will be applied soon. Therefore, this all indicates that tag ‘lanes=2’ for this road is logical information, and it would be better not to remove it.

Regards, Kate

Hi, yawfle!
My name is Kate, and I’m a mapper on the OSM team at Lyft.
Many thanks for sharing the photo and informing us about reverted changes.
In this case, I decided to disconnect roads, because the passage through this barrier by cyclists or someone else looks unsafe in my view. I suggest applying tag motor_vehicle=no to the segment with barrier way/1231579385/history to exclude it completely from navigation for cars.
Another option is a combination of tags ‘access=no’ +’emergency=yes+bicycle=yes’ on the way. Perhaps, it would be also useful to add turn restrictions from alleys to North Cordova Street in order to provide a more comprehensive and accurate representation of the real situation on the map. Please, let me know if any suggestions will be acceptable for you.

Regards, Kate.

Hi! My name is Kate, and I’m a mapper on the OSM team at Lyft.

Many thanks for your question, because after reviewing my edits I found some issues with the construction tag.
In this case, I intended to partially fix the construction tag according to the Lyft telemetry data (https://drive.google.com/file/d/10laBKngisvCHzhA6eIckCi3mCu70v0EP/view?usp=sharing). On this image, we can see that the part of Mearns Meadow Blvd is open for the traffic and may be used by drivers. Also, it could be confirmed by the street level image from 2023-09-08, taken from Mearns Meadow Boulevard (30°22'19.9"N 97°42'11.9"W - https://drive.google.com/file/d/1tNM9S2rwuwCZWaMLeq3yFrBsPZCru2Gs/view?usp=drive_link).
But I accidentally removed this tag from the entire segment. Therefore, I have already changed it in the changeset - changeset/143681185. I’m really sorry for my mistakes and any inconvenience these changes may have caused.

Regards, Kate

Many thanks for this note! You make a really good point, and I share your opinion that the solid line isn’t the valid reason for adding a separate link.
However, the link was added earlier by another OSM member -https://osmcha.org/changesets/103197300/ and in our practice, we try not to change geometry without apparent reasons for that.
In my view, there is no reason to delete the link since the physical barrier can be seen on a street -level image from 2023-06 taken from South Potomac Street (39°34′26″N; 104°49′37″W - https://drive.google.com/file/d/1l22n6PWOJ6V0NTMEeTyzLAX7TJuKoSAH/view?usp=sharing)

Hi, Mateusz! My name is Kate, and I’m a mapper on the OSM team at Lyft.
In this changeset, I made edits only with lanes and turn:lanes tags without modifying the existing geometry - https://osmcha.org/changesets/123321403/.
It seems to me that this version of adding a separate link is reasonable here due to the physical barrier at the intersection and the long solid marking line. We can see this barrier on Lyft-owned street level image from 06-01-2023 - https://drive.google.com/file/d/1l22n6PWOJ6V0NTMEeTyzLAX7TJuKoSAH/view?usp=sharing.
There are different approaches for mapping such cases, in our practice we try to follow general logic and principles adopted in the OSM and stick to the short links, but at the same time we don’t correct other options of mapping.

Regards, Kate.