Hi Allison P!
Thank you for bringing this to my attention. Yes, you are right, mapping such pipestems with the service=driveway tag would be more accurate. We will take your remark into account for future mapping of similar roads
Thanks for your contribution to OSM!

Best regards, Veranika

Hi, CjMalone ! My name is Veranika and I’m a mapper in the OSM team at Lyft.
The edits were made as part of the Missing Roads project (https://github.com/Test-DCT/OSM-LYFT-DCT/issues/27 ), the main goal of which is to map missing roads to improve navigation. Modifying building polygons is out of the project's scope if it doesn’t affect the navigation.
The ways were splitted with the covered=yes tag around the gas station roof visible in the background, according to the osm wiki (covered=*#:~:text=When%20used%20this%20way%20the%20building%20and%20the%20way%20should%20have%20shared%20nodes%20at%20the%20entry%20and%20exit%20points%20of%20the%20building.%20The%20way%20should%20be%20split%20at%20the%20entry%20and%20exit%20nodes%20and%20only%20the%20part%20covered%20by%20the%20building%20should%20be%20tagged%20with%20covered%3Dyes). It is not necessary to have building polygons to split the road and add the "covered=yes" tag for ways actually covered by the roof.
Feel free to adjust the polygon's edges if needed.
Best regards!

Hi, ec90! My name is Veranika and I’m a mapper in the OSM team at Lyft.
Our team adds a name tag to new roads whenever possible. According to our policy, we add this tag based on available street level photos. Unfortunately, for this location we do not have any photos to add the name tag to the new roads. We will ensure to add the names of the streets where possible in the future.
Thank you for your contribution to the OSM.
Best regards, Veranika

Hi, Andrew Kvalheim ! My name is Veranika and I am a mapper in the OSM team at Lyft. Thank you so much for paying attention to this.
That is definitely a mistake. I apologize for the oversight in fixing the road. Thank you for pointing it out and for your contribution to OSM!
Best regards, Veranika!

Hi, Tex2002ans ! My name is Veranika and I am a mapper in the OSM team at Lyft.
We can assure you that we use only relevant information in our work and according to the Lyft-owned aerial imagery (April-May 2024) (https://drive.google.com/file/d/1ObXjiYxIeExYfl0qf9UtFStl3MnTaRip/view?usp=sharing) the geometry of the roads is correct. I see that the geometry of the Wind Creek Bethlehem Hotel building has changed but the purpose of my edit was to correct road geometry, to not check the elements of the entire territory. Here you can read about our projects and mapping specifics osm.wiki/Lyft
Best regards, Veranika

Thank you for clarifying the information. Returned the roads according to Bing background changeset/147438024.
Best regards, Veranika

Hi, finnc32 ! My name is Veranika and I am a mapper in the OSM team at Lyft.
According to Lyft-owned aerial imagery, the Joyce lot looks like a full renovation with removed surface and also, there are still no Lyft drivers GPS tracks. So I decided to remove the roads assuming there would be large geometry changes.
Thank you for letting us know about the current situation at the parking lot, but unfortunately the freshest satellite imagery indicates like there is still a construction and we cannot add roads because we don't see the current geometry and lane markings. If you were near the Joyce lot and saw that the parking markings have not changed after the construction ended, we can add the roads back in according to the Bing background.
Thanks for bringing this to our attention. Sorry for any inconvenience this may cause.

Hi, Udarian!
You’re right, according to Lyft-owned aerial imagery there is a physical barrier separating one-way roads. But at the moment of making changes to the OSM we were not sure of the direction of the roads (no markings visible) and that the exit road was already open due to lack of information. Thanks to your comment, we can now make changes to the road geometry (changeset/147088007).
Best regards, Veranika

Hi, Udarian! My name is Veranika and I am a mapper in the OSM team at Lyft.
Based on the Lyft telemetry data and street-level imagery, the roads you are interested in are not yet open for traffic (https://drive.google.com/file/d/1_2gAfut70WQyMzMRcSstmFjAp9Lya2Sh/view?usp=drive_link - the multicolored dots are drivers' tracks, showing where they can pass and where roads are most likely closed). As this area has quite active traffic, when the construction is finished, we will know that the roads opened in a short time and remove the construction tags.
As for roads way/38840050/ and way/38840051/, according to Lyft-owned aerial imagery https://drive.google.com/file/d/1EI5rH4Y2ejNC_jObndIAh542IEyEfqBK/view they can be removed as there is construction going on at this location and the roads will be changed (the roads that are under construction are already in the OSM).
Happy to help!!
Best regards, Veranika

Hi, ExecutableFiles! My name is Veranika and I am a mapper in the OSM team at Lyft.
The edits were made on July 20 https://osmcha.org/changesets/138754777/ based on Lyft owned telemetry data (https://drive.google.com/file/d/1stWgXzy86S6COrsjMWB3oWMKtIveQRpr/view?usp=sharing), that shows the actual road configuration and drivers’ trajectory. On July 31, another mapper modified these parts of the highway using outdated data https://osmcha.org/changesets/139256583/. On the Deep History page (https://osmlab.github.io/osm-deep-history/#/node/180403231 ), you may see precisely when and how one of the highway nodes' positions changed.
Thank you so much for your attention and fixing the map inaccuracies.
Best regards, Veranika

Hi, Udarian! My name is Veranika and I am a mapper in the OSM team at Lyft. Thank you so much for paying attention to this.
The NW 41st Street Interchange is under reconstruction (https://floridasturnpike.com/wp-content/uploads/2021/03/FACT-SHEET-Turnpike-Extension-Widening-from-SR-836-to-NW-106-Street-03-16-21.pdf). Based on Lyft telemetry data (https://drive.google.com/file/d/1mGmubDeyDzEhOFdgcGeKnsvkUUb-FNfX/view?usp=sharing) it's a new onramp for traffic (way/1186074524). But at this moment we cannot be sure about the future status of the way section you are talking about (way/171314596). According to Lyft-owned street-level imagery (https://drive.google.com/file/d/1WpTPkW0KLTSBA0ZbCLoPkkTzxqmckd75/view?usp=sharing) and official information source https://floridasturnpike.com/wp-content/uploads/2023/05/052623-Weekly-Advisory-South-FL.pdf this road segment is closed for construction. So it was better not to leave these two roads available for traffic at the same time. Therefore, in this changeset changeset/138696229 we have added a construction tag to the non-traffic way. Please, let me know if there are any follow up questions.
Best regards, Veranika

Hi Allison P!
Thank you for bringing this to my attention. I have added gates based on the Bing Maps Aerial. Also we have a rather blurry Lyft-owned satellite shot, where it is quite complicated to determine the type of barrier
(https://drive.google.com/file/d/1XjQQaV6T6aSAsIaHm-9-Ewl07gukDr1-/view?usp=share_link). Unfortunately that's all we have and any lyft-owned street-level images aren't located here. I hope this data, combined with your information, will help you to clarify the barrier type.

Thanks a lot for your contribution to OSM!

Best regards, Veranika

Hi, impiaaa! My name is Veranika and I am a mapper in the OSM team at Lyft. Thank you so much for paying attention to this.
That is definitely a mistake. I’m genuinely sorry for my carelessness in removing a non-existent road. The connection of the service road and the misleading foot crossing has been changed in the OSM changeset (changeset/131681250).
Thanks a lot for your contribution to OSM!
Best regards, Veranika

Hi tekim and Allison P.
My name is Veranika, and I am a mapper in the OSM team at Lyft.
Allison P, thank you for clarifying what we mean by “Proprietary”.
I want to assure you that the Lyft mapping team takes the OpenStreetMap rules seriously and that all of our resources are compliant with them. To make edits, the Lyft OSM team uses proprietary features created and owned by Lyft, specifically the street-level imagery from Lyft’s drivers taken during rides in various markets and Lyft drivers' GPS tracks. Also, as "proprietary aerial imagery" for now, we use Nearmap aerial imagery. They do allow us to use their imagery for OSM edits by license. That means our evidence fully complies with the OSM requirements. This info is updated frequently, and helps us to improve the OSM with the most recent data.
There have already been some OSM slack discussions regarding that topic (for example
https://osmus.slack.com/archives/C029HV951/p1649138722994309
https://osmus.slack.com/archives/CCJ2P6KCH/p1640129896237000, https://osmus.slack.com/archives/CCJ2P6KCH/p1663095305986359). So we added more explanation to our OSM profiles in the "Proprietary sources" section.

We are sorry that such terminology confuses you. Unfortunately, taking into account the volume of edits, as for now it is difficult for us to organize the addition of such explanations to each of our changesets. We are thinking of changing the phrase “Proprietary sources” to “Lyft-owned/owned by Lyft sources”. How do you think would it be a more accurate term?
Best regards, Veranika

Hi, GITNE and Minh Nguyen. My name is Veranika, and I’m a mapper on the OSM team at Lyft.
Many thanks for paying attention to this and for your opinions!
We understand GITNE’s arguments. That such application is least useful compared to other restriction relations. And of course the presence of a relation affects the speed of data processing.

On the other hand, adding a relation is a way to reflect the presence of a sign on the road. And as Minh Nguyen mentioned, it is a good way to distinguish an intersection that allows U-turns from the one that prohibits it. It is confusing that one specific turn restriction sign should be reflected not as a relation but with traffic_sign tag. There is only more like advice in OSMwiki about applying no_u turn on different ways. It is not forbidden to put a No_u turn on a bidirectional road: osm.wiki/Relation:restriction. And in my experience this practice is widespread at least in the USA.

Anyway, we will definitely take your arguments into account and will consider updating our approach concerning no_u_turns. But in order to make a specific decision, we need to collect and analyze information, including internal data.

Thank you for your contribution.
Veranika

Hi, skquinn.
My name is Veranika and I am a mapper in the OSM team at Lyft.
Typically our team doesn't map turn lanes separately without a physical barrier. I made a decision to add this separate left turn for clearer guidance for drivers because there is one on the East Tidwell Road according to the proprietary imagery owned by Lyft, Mappilary (https://www.mapillary.com/app/?pKey=523679259013151&focus=photo&lat=29.845525&lng=-95.391158&z=17) and Bing aerial imagery. But you are right perhaps this barrier is not significant enough to separate it with a link. Thanks for bringing this to our attention. Sorry for any inconvenience this may cause.

My name is Veranika, and I’m a mapper on the OSM team at Lyft.
Many thanks for paying attention to this. I’m so sorry I have missed the extra members addition to the relations Upper Darby and Lansdowne. I sincerely apologize for any inconvenience these changes may have caused. I have removed the extra members of the relations in this changeset https://osmcha.org/changesets/119189629/. I can promise I and my team will look deeper into the reasons why this has happened to avoid these kinds of mistakes in the future. Thank you so much for your contribution and valuable feedback!

Hi, Mundilfari.
My name is Veranika and I am a mapper in the OSM team at Lyft. Thank you so much for paying attention to this.
According to OSM wiki osm.wiki/Relation:restriction, there should be turn restrictions signs or traffic lights with direction arrows to prohibit turning. In this case, there are no such signs. But I agree with you, here the driver should use the at-grade connector to turn right. So I have added an implicit restriction of turning right in the changeset https://osmcha.org/changesets/116807798/. I apologize for any inconvenience.

Thank you so much for your input in the OSM!
Best regards, Veranika

Hi, MxxCon!

My name is Veranika and I am a mapper in the OSM team at Lyft. Thank you so much for paying attention to this. I should have been more specific while working with highway layers. Apologies for any inconvenience this may have caused. You’re right – we do use the proprietary imagery owned by Lyft to make edits, however, the coverage of it is not uniform. Specifically, the street-level imagery we have for the mentioned interchange is not enough to make all the necessary fixes. I corrected Kew Gardens Interchange based on all the available information: https://osmcha.org/changesets/115202492/; https://osmcha.org/changesets/115207841/; https://osmcha.org/changesets/115208999/.
I mainly used the proprietary aerial imagery and telematic data to edit the interchange (https://drive.google.com/file/d/12eqlerZKXtR4hAd2a1zBsbHiAUX1eqsE/view?usp=sharing; https://drive.google.com/file/d/1IzFkVRYfx5w5lK2g8TcjzohXuRMjE2Og/view?usp=sharing).If we get more imagery from this interchange, I’ll be happy to provide more details to the OSM.
Thank you for your contribution and valuable feedback!

Regards, Veranika

Hi, Mundilfari, anyway thank you for your contribution!
 Have a great weekend. Regards, Veronika