Hello icerooster,

I’m Artem, Lyft’s OSM Policy Lead. We appreciate you reaching out with your feedback. Regarding the left turn restriction added in this changeset, it is specifically limited to the maneuver from West Glebe Road (way/590831832) onto South Four Mile Run Drive (way/8796267). This particular restriction is substantiated by Lyft street-level imagery dated 2026-04-23 (https://drive.google.com/file/d/1CuNdadm1qaKjZKQKQkvxOl-idSS-xlDM/view?usp=sharing). Additionally, other navigation platforms—including GraphHopper, Valhalla, and OSRM—do not show restrictions for any other maneuvers at this intersection.
Please let us know if you possess more recent data or evidence regarding changes in this vicinity.

Best regards, Artsiom

Hi Ygramul,

I'm Artem, the OpenStreetMap Quality Control Team Lead at Lyft. Thanks for pointing this out. As far as I can see, the incorrect tennis courts have been deleted, so thank you for editing these elements. We will revisit our policy on deleting outdated areas that could be overlapped by newly added roads, to avoid issues in future.

Best regards,
Artem

Hi VigilantPenguin,

I'm Artem, the OSM Policy Lead at Lyft. Thanks for raising this issue. You are absolutely right. I have removed the toll conditions from all affected ways in this changeset (changeset/178069341). I apologize for any issues this may have caused
Best regards,
Artem

Hi Udarian,
My name is Artem, and I'm the OSM Policy Lead at Lyft. Thanks for bringing this up. It looks like something is broken in preview mode. Please try using this link with preview: https://www.arcgis.com/apps/mapviewer/index.html?panel=gallery&layers=eef6b33da60d47c0964387960c840eea
If that also doesn't work, please refer to the initial page where you can load the map by yourself: https://gis-mdc.opendata.arcgis.com/datasets/MDC::address/about

Best regards,
Artem

Hi, wolfy1339
My name is Artem, and I'm OSM Policy Lead at Lyft. Thank you for the comment. According to our current policy, we only tag the segment closest to the exit. Our policy is based on widely accepted practices within OSM. As you know links can be very long, and it seems unnecessary to overload OSM with information without a clear need. At present, we adhere to this approach. However, we may be overlooking something. We would appreciate it if you could share your thoughts or provide links to OSM wiki/ OSM forum discussions explaining why you believe it is important to tag the entire ramp.
Best regards, Artem

Hi Baloo Uriza,

We’ve created a topic on OSM community forum to engage a wider discussion on this topic:

https://community.openstreetmap.org/t/consensus-regarding-lane-and-turn-lane-tagging-guidelines/133364#:~:text=on%20this%20recommendations-,However%2C%20some%20mappers%20believe,-that%20explicit%20turn

Best regards, Artem

Hi Baloo Uriza,

We’ve created a topic on OSM community forum to engage a wider discussion on this topic:

https://community.openstreetmap.org/t/consensus-regarding-lane-and-turn-lane-tagging-guidelines/133364#:~:text=Currently%2C%20the%20wiki%20states

Best regards, Artem

Hi Baloo Uriza,

We’ve created a topic on OSM community forum to engage a wider discussion on this topic:

https://community.openstreetmap.org/t/consensus-regarding-lane-and-turn-lane-tagging-guidelines/133364#:~:text=2.2.-,We%20also%20encountered,-inconsistencies%20in%20where

Best regards, Artem

Hi, Baloo Uriza,

My name is Artem, and I'm OSM Policy Lead at Lyft. As we mentioned in the comment to changeset/166200809 we informed our entire team about this case to prevent such mapping in the future. I apologize for any inconvenience caused by the edit.

Best regards, Artem

Hi Baloo Uriza,

My name is Artem, and I am OSM curation Policy Lead at Lyft. Thank you for your comment. We take into account the vision shared by you and will consider the opportunity to exclude from our workflow the tagging of lanes and turn lanes on slip roads and one-lane links altogether.

We are grateful for your contribution and wish you happy mapping!

Best regards, 
Artem

Hi, Udarian

Sorry, now shared as a public. Please, double-check

Hi, CurlingMan13
My name is Artem, and I'm OSM Policy Lead at Lyft. Thank you for bringing this to our attention and fixing my mistake. I apologize for any issues this may have caused

Best regards, Artem

Hi, Aduxas, sorry for the late response

My name is Artem, and I'm OSM Policy Lead at Lyft.
About the 'way' you mentioned in the comment. According to our street level from September 2024 (https://drive.google.com/file/d/1Dx7kWdayU9bx-Ki462ELRXOKB44tzkwd/view?usp=drive_link), the ramp changes level from the ground truth, so we decided to mark the bridge from the part where the level of the ramp is different from the base ground level.
If you have any concerns about this tagging, we might delete the bridge tag on this part and add the embankment tag (embankment=*)
But if you have another approach for this case, please share it with us. Thanks for your contribution!

Best regards, Artem

Hi Spaghetti Monster!!

Thank you for your message, and for catching this error!
You’re right, it should be tagged as residential, my mistake.
My apologies. I will be more attentive when pushing change sets up.
Best regards!

Hi, skquinn

My name is Artem, and I’m a mapper on the OSM team at Lyft. Thank you for bringing this to our attention and fixing my mistake. We apologise for any trouble this may create.
We value your contribution to OSM!

Best regards, Artem

Hi, csomerville,

Thank you for your contribution! We will be waiting for any updates that you can find out about mapping such intersections.

Best regards, Artem

Hi, SomeoneElse,

My name is Artem, and I’m a mapper on the OSM team at Lyft. Many thanks for this note!
The incorrect ‘changesets_count’ display was caused by our internal issue in the hosted version of IDeditor. We have contacted our tooling team and the issue is expected to be resolved shortly.

Best regards, Artem

Hi, TheAdventurer64,
My name is Artem, and I'm Ruslan’s teammate. Thanks for your kind words!

I will gladly share with you our reasoning on the indoor facilities. We see the matter like this: there are two ways for its mapping according to OSM wiki (osm.wiki/Indoor_Mapping#Tagging_proposals):
- the tag you mentioned “highway=corridor”
- the tag combination “highway=footway+indoor=yes” (osm.wiki/Guidelines_for_pedestrian_navigation)

In the United States many buildings are mapped with tags highway=footway+indoor=yes. At the end of this page (osm.wiki/Simple_Indoor_Tagging) you can find different examples of mapping indoor features. Therefore, we consider this method of tagging to be quite appropriate.

We also take into account the OSM routing: (osm.wiki/Guidelines_for_pedestrian_navigation)
In the Simple Indoor Tagging model, pedestrian ways can be added to indoor areas and used by a routing engine.
So we changed the tag highway=corridor to highway=footway+indoor=yes for the ways located inside the airport buildings to ensure correct route building for pedestrians. Currently the tag highway=corridor is not injected for OSM walking routes. Perhaps we are missing something and the tag “highway=corridor” is more appropriate here. In general, we don’t change the highway corridor anymore based on our current flow. We are grateful to you for opening the discussion and will take your possible reversing our edits with understanding since highway=corridor tag is also acceptable in OSM. Thanks for your contribution!

Best regards, Artem

Hi, csomerville,

My name is Artem, and I'm Polina’s teammate. I don’t see any significant reasons to remap the road and at the same time there are some doubts on how to do it right for such an atypical road. However, I have nothing against the first approach. If you are sure that a bidirectional road is more beneficial here, please feel free to change our edits. We really appreciate your intention to find the best option and discuss it with us. Thank you for your contribution!

Best regards, Artem

Hello, nickvet419!
I'm a Data Curator from the Lyft Mapping team. Thank you very much for your edits and adding new detail on the map! Please, could you clarify, what source did you use for editing?
We found out that some tags in ORD that were added recently are deleted. So I would like to discuss the best way of mapping indoor features in the airport.
According to OSM wiki (osm.wiki/Indoor_Mapping#Tagging_proposals), there are 2 different ways to map indoor facilities:
- highway=corridor - indoor ways, under some previous indoor tagging schemes, and as of 2019 a de facto standard. This tag was used in ORD airport, and it was used correctly. But when we are trying to create the pedestrian route inside the terminals, OSM doesn’t show the route correctly.
- Another de facto standard for mapping (osm.wiki/Guidelines_for_pedestrian_navigation) interior routes is tags combination highway=footway+indoor=yes. In the United States many buildings are mapped with tags highway=footway+indoor=yes, for example:
example 1 (osm.org/edit#map=17/40.75217/-73.97640),
example 2 (osm.org/edit#map=19/34.05617/-118.23598), example 3 (osm.org/edit#map=19/39.75322/-105.00006). Also, most airports in the USA are mapped this way:
example 1 (way/208889095),
example 2 (way/158042008),
example 3 (way/545819287),
example 4 (​​relation/9313825),
example 5 (way/209681674)
At the end of this page (osm.wiki/Simple_Indoor_Tagging) you can find different examples of mapping indoor features.
You can also find some useful info here: osm.wiki/Guidelines_for_pedestrian_navigation
In the Simple Indoor Tagging model, pedestrian ways can be added to indoor areas and used by a routing engine.
Our suggestion is to change the tag highway=corridor to highway=footway+indoor=yes for the ways located inside the airport building. We won’t change the geometry of the ways you added, but we need to change tag value for main footways in the terminals for correct routing. OSM routing doesn't include in route ways with tag highway=corridor, so the highway=footway+indoor=yes will allow to show the correct route for pedestrians.
Thank you for your edits.