Hi! My name is Stepan and I’m a mapper on the OSM team at Lyft.
You’re right, there are some inaccuracies with my edits since I didn’t double check the street level images to confirm that the road is closed. (https://drive.google.com/file/d/1fgJzRo6UM9YqNqSOsMC6JaIwNV2gH4Tx/view?usp=drive_link )
Many thanks for your attentiveness and the correction of my mistaken edits, I appreciate it!
Sorry for any trouble caused.
Best regards, Stepan

The ways were splitted 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). The presence of building polygons is not obligatory to split the road that is actually covered by the roof.
The main goal of the Missing Roads project (https://github.com/Test-DCT/OSM-LYFT-DCT/issues/27 ), within the scope of which these edits were made, is to map missing roads to improve navigation. Adding building polygons is out of the project's scope

According to OSM history, the building polygon was added after my edits (https://pewu.github.io/osm-history/#/way/1265843794) For some reason, the roads were left disconnected from it.
I have now connected these roads with the roof in changeset (changeset/155546435)
Thank you for catching this error!
Best regards, Stepan

Thank you for your feedback and for sharing your approach! I agree that detailed explanations help clarify the situation, but it can indeed be challenging with complex edits. However, we are always ready to share our evidence if needed.

Hi, jleedev!

My name is Stepan and I’m a mapper on the OSM team at Lyft.
On the changeset I modified the geometry of the motorway according to the Lyft-owned background, GPS tracks, and street-level images.
The access to the Mon/Fayette Expressway (way/1302471898) is possible only from the westbound direction of Jefferson Boulevard, which became bidirectional due the construction works. (See satellite image https://drive.google.com/file/d/1u4VqngiwEnmhdKQt173x8QWWoqWzkQDo/view?usp=drive_link and street level imagery https://drive.google.com/file/d/1AxcG4a0R5ZmixMOusS6mi2xlrjL_Go5b/view?usp=drive_link taken at 40.29654, -79.91361).
Northbound direction is divided into two directions till the node/12062931437 according to satellite imagery and GPS tracks (https://drive.google.com/file/d/1GFoJBuNTlIbt_A7h3yzpKkGWSQ-N_BSR/view?usp=drive_link)
If you find any inaccuracies in my edits, please let me know what they are and it will be fixed.
Best regards, Stepan

Hi MxxCon!
While making edits I relied on the instruction with :lanes:psv tag lanes:psv=*#:~:text=OSM%20way%20points%20in%20direction%20of%20photographer where tag lanes:backward uses in combination with lanes:psv:backward. Added the lanes:hgv:backward=1 in combination with lanes:backward=1 to specify the number of HGV lanes that are present in the backward direction.
The same is for the oneway=yes tag, it is used in combination with oneway:hgv=no like highlighted in the OSM wiki.

Best regards, Stepan

HI!
According to the Lyft-owned satellite from December 2023 the intersection is still under construction and without a solid surface (https://drive.google.com/file/d/16nXVIZq31GQ5vq6jlCZ7-z5-GI0K-rdl/view?usp=sharing ), also there are no Lyft drivers’ tracks.
And this is street level image taken from the HEFT and way/83194112 (25.9308967, -80.3716766) intersection https://drive.google.com/file/d/1bullhAmkPpomC9ZSaEiidOyEqXQ_TAfQ/view?usp=sharing
If you have any questions feel free to contact me.
Best regards, Stepan

Unfortunately, we didn’t get permission from the owner before using this video. We’re very sorry for this. Thanks for paying attention to it. We connected with our legal department to clarify this question and decided that it would be better to remove our edits until a final decision is made. I deleted pedestrian roads under the station in changeset changeset/143058861.
We promise not to use any sources again without full confidence that they are allowed and open for free use.

Lyft OSM-team recognise the value of protecting intellectual property, and I'll take proactive measures to prevent copyright violations in the future.

Thank you for your contribution.

Stepan

Hi, Udarian!
My name is Stepan and I’m a mapper on the OSM team at Lyft. The edits within covered areas are made based on several available sources, like Lyft-owned images, Bing and Mapillary streetside views, plans of the areas from the official sources and other open sources like YouTube. For example the road way/1215018332 was added using this YouTube video
https://www.youtube.com/watch?v=MmPpWOcWsHU: way/831944761 and Bing streetside images:
https://www.bing.com/maps?cp=25.798934~-80.258408&lvl=17&dir=263.678&style=x&v=2&sV=1.
The tags on way/831944805 were added using Lyft-owned imagery https://drive.google.com/file/d/1Pryq8HHNR3GUVUGvKAhIEvCsZ3e2wWrj/view?usp=sharing
You can read more about Lyft-owned sources here:
https://github.com/Test-DCT/OSM-LYFT-DCT/blob/1beae15649f43e0bef043fc0ef3950d7cbfdc867/osmtrainingmaterialsfeatures/Lyft-owned%20sources%20(ex.%20proprietary%20sources).md
Thanks for the question. Please let us know if there are any inaccuracies in our edits, we would appreciate any insights.
Stepan

Hi, pluton_od!
My name is Stepan and I’m a mapper on the OSM team at Lyft. I'm sorry for adding the wrong tag for the segment: way/1187792165. Of course the hov:lanes tag is more appropriate for such cases, but on this segment there are really no hov lanes. I deleted the wrong tag in the changeset: changeset/138413356 .
Thank you so much for bringing this to our attention.
Best regards, Stepan!

Hi!
My name is Stepan and I am a mapper on the OSM team at Lyft.
According to OSM wiki tag construction is used to denote active construction sites that typically take several years to complete.

construction=*

These edits are designed to make traffic safer. As you mentioned, the construction on the motorway will last for an extended period of time. If we leave it without modifying the geometry and the construction tag, it would interfere with localization and confuse the users.
I think it would be better for the map users to see the current road situation.
As motorways are high-traffic roads any changes are noticed quickly and I think as soon as the construction work on the road is over, the geometry of the road will be corrected in a short period.

Thank you for your contribution,
Stepan

According to the OSMwiki access=no (access=*#) tag prohibits general access to the road. “Stronger interdiction than access=private. Examples: a fully closed road; a restricted military facility.” In my opinion, by the level of access to this correctional facility we could equate it with a military base. So, yes, routing will ignore these roads. The only way to indicate that the road isn’t restricted for certain vehicles with the permission is to add the motor_vehicle=private tag, but for the navigation this tag is superior to access=no and the road becomes drivable for everyone. So it will be highlighted on the map but routing won’t be accurate.
So I can see 2 potential approaches to tag the roads. We may add the motor_vehicle=private tag, but it opens the roads for general access or the second one is to leave everything as it is now, but navigation wouldn’t work on this territory for all drivers. I find the option to leave the roads with access=no more preferable, so nobody could be incorrectly routed to the area. However, we can go with either of them.

I will be happy to know your thoughts and figure out the best approach together!

Hi, MxxxCon!
Thank you for paying attention to this.
The access=no tag was added based on the fact that it is a correctional facility and doesn’t have public access. According to the OSMwiki, access=permit is used if the access is restricted, but everyone can get the access, so it is more like just a procedure. In this case, it is a correctional facility with strict rules, where not everyone is allowed to get access to the territory, besides, it is necessary to observe a number of rules, including the form of clothing, the availability of documents, which also requires time and preparation. Also the tag already exists on the gate and some of the facility’s roads, and for the map’s accuracy the access=no tag would be preferable.
access=permit
The motor_vehicle=yes tag was deleted for the same reason. According to the Rikers Island Visitor Guide(https://www.libertyfund.nyc/wp-content/uploads/2019/06/2016-Rikers-Island-Visitor-Guide.pdf) and some other sources, to get to the island you need to take a bus and there is no evidence that all motor vehicles are allowed.
We would appreciate hearing your thoughts on this situation and find any potential solutions.

Best regards, Stepan

Hi, heretofore!
My name is Stepan and I am a mapper on the OSM team at Lyft
Thank you for your question. There is indeed a sign here only for Airport traffic https://www.mapillary.com/app/?pKey=1329286604145674&focus=photo&lat=38.924637887718&lng=-77.196989113286&z=17&x=0.46447061703292597&y=0.483405619346755&zoom=1.6714980385520235. And based on the OSM wiki, it can be assumed that such signs are the reason for adding the access=destination tag. (access=destination)

On the other hand, the tag description in the OSM wiki is rather modest and the main focus is placed on local traffic (access=*#List_of_possible_values.) In our understanding, the destination access should apply to roads in a specific location, where roads can be used as a destination or a starting point. That is, if we add this tag by sign, then we need to do it for the entire way and for all the airport roads. We came to such conclusions based on our experience in OSM. Motorway and motorway links rarely have destination access in USA and more often the whole location is tagged with access=destination, for example, here almost all roads at the airport have a destination access tag (way/42789202/history#map=18/28.38059/-81.54990).
Applying this tag only on part of the road makes the road unroutable in OSRM. So that’s why I have decided to remove forementioned tag. Please let me know if you have any further questions or insights that could help me to understand your point in this case.

Thank you for your contribution,
Stepan

Hi, EricTheLinguist!
My name is Stepan and I am a mapper on the OSM team at Lyft. I'm so sorry for missing the construction here and adding these service roads according to outdated satellite imagery. Thank you so much for noticing and correcting my mistake.

Best regards, Stepan

Thank you for sharing your opinion and for raising this issue. We appreciate it. We will consider updating our approach concerning mapping turn lanes based on your comment and your geometry edits at this interchange.
Best regards, Stepan

Hi, Baloo Uriza!
My name is Stepan and I am a mapper on the OSM team at Lyft. ​​The main objective of our changeset was to add the missing links. These links are separated with barriers, so just adding a turn:lanes tag would not solve the issue. In this changeset I have added two new links according to Bing Maps Aerial. Regarding the link way/1105445457, perhaps there is another option to map it not so long along the Northwest Sheridan Road and add turn:lanes on the way way/589542113 to show left turn. But here I decided to add a long left turn link because of a solid lane. With such a road geometry there will be no routes crossing the solid lane, which is a traffic violation. As for this link way/1105445456, the way I have added does not have a typical curve in OSM in such cases. So I have fixed it in this changeset: changeset/128000152.
I’m sorry in advance for any inconvenience my edits may have caused.
Thank you for your contribution!
Best regards,
Stepan

Hi, oba510!
My name is Stepan and I am a mapper on the OSM team at Lyft. I'm so sorry for missing the construction here and adding these service roads according to outdated satellite imagery. Thank you so much for noticing and correcting the mistake.

Best regards, Stepan

Hi, Minh Nguyen!
My name is Stepan and I am a mapper on the OSM team at Lyft. I'm sorry for adding the wrong value for the access tag. Of course the access=no, emergency=designated are more appropriate tags for such cases. Thank you so much for paying attention to this and correcting the mistake.

Best regards, Stepan

Thank you so much for resolving the anonymous comment and your contribution to OSM! I greatly appreciate it.
Best Regards, Stepan