Changing the name of a piece of Castlegate Court to Stonehenge Place was an extrapolation; I'm assuming this was overlooked when Stonehenge Place was first extended east of Castlegate Court. I confirmed the other name changes from signage.

Since I didn't hear from you, I made the proposed change in osm.org/changeset/130691253 (finally; I got busy with other things).

This is mostly a revert of osm.org/changeset/130534543. See the previous discussion on osm.org/changeset/130018058.

As luck would have it, I went to the location today and saw that Towne Road is now open to Old Georgetown Road. Also, the entire segment between Josiah Henson Parkway and Old Georgetown Road is now a dual carriageway, but I don't have any source from which to draw the new ways accurately, so I'll leave that issue alone for now. So I think just reverting osm.org/changeset/130534543 will leave things in the correct state. Done in osm.org/changeset/130667240.

Oops, the "source" should have included Bing imagery.

Turns between Luxmanor Road and eastbound Tuckerman Lane would cross two double yellow lines. I wasn't confident that such turns are legal in general in this jurisdiction or advisable in this case. But there is a "do not block intersection" sign on eastbound Tuckerman Lane shortly before Luxmanor Road, and the only reason I can think of for that sign would be to accommodate a left turn from Luxmanor Road to Tuckerman Lane. So I'm presuming the left turn from Tuckerman Lane to Luxmanor Road is OK too. According to the "Roads are not to be mapped as dual carriageways" examples at the top of osm.wiki/Dual_carriageway, the relevant section of Tuckerman Lane should be mapped as a single carriageway regardless of whether the turns are OK, but if we didn't want routers to use the turns, I would have wanted to add restrictions in the same changeset.

I'm requesting review mainly for the change to the bus route (osm.org/relation/9686404) since I don't have a good understanding of how that's supposed to be represented.

Hi! On what basis did you decide that this segment is better described as highway=service than highway=path? Routers will send motor vehicles along a way with highway=service, but I was just at the location and I'm convinced that this way is not intended for motor vehicle traffic. For one thing, it's too narrow; it looks basically like osm.org/way/281335860 except that there are no gates at the ends. So I propose to change the tag back to highway=service. I'll notify osm-edit-escalations@amazon.com too as instructed on your user page, and if I don't get a response on this changeset in a week (by November 21), I'll go ahead and make the change. Thanks for your attention!

Hi! What evidence do you have for the primary name of some of the way segments in this changeset being "Washington Boulevard"? Was this from TIGER? I just surveyed the location, and all the signage I could see says "Washingtonian Boulevard", not "Washington Boulevard". So I propose to change the primary name to "Washingtonian Boulevard". I can keep "Washington Boulevard" as the alt_name if there's a reason to do so. If I don't hear from you in a week (by November 19), I'll go ahead and make the change. Thanks for your attention!

This is crude but better than not having the data at all. I added only the trails that were convenient to survey on one trip I was taking anyway; there are other trails that are not yet mapped. Coordinates could use refinement; they are from one trace of my GPS, which is not very accurate. Some tagging may also be suboptimal.

A correction to the "source" tag of this changeset: it should have included Bing imagery.

Obviously, this would have been much more valuable if I had done it right after osm.org/changeset/118146295. However, this road was well known as Montrose Parkway for many years, so I think there may still be some members of the public who are not yet aware of the rename or still think of the old name.

Survey date is 2022-04-04. (I am rushing and forgetting minor things...)

I neglected to mention another source: "copy tags from other locations on OSM".

I'm finally coming back to this. Since I didn't receive a response here, I made the proposed change and decided it made sense to revert the other ways to motorway_link too for consistency (osm.org/changeset/122614516).

This reverts osm.org/changeset/96369694 and additionally sets junction:ref on one of the ways where it is applicable. The use of motorway_link on osm.org/way/187934955 helps routers that don't support junction:ref distinguish the exit from the through road; see further discussion on osm.org/changeset/96369694. Also, the use of motorway_link on all three of the ways maintains logical symmetry because the ways that connect MD 200A to opposite directions of I-370/MD 200 are equally important, even if some go straight for a slightly longer distance than the others. This is consistent with the mapping of at least one other trumpet interchange in the region: that of the George Washington Memorial Parkway and I-495.

I did some more research into the general issue. There are junctions elsewhere on the map with two outgoing ways tagged "highway=motorway" where IMO it isn't reasonable to change one of them to "highway=motorway_link"; an example is osm.org/node/37192428. So the fact that OsmAnd announces the exit number for both outgoing ways has to be considered a bug in OsmAnd (https://github.com/osmandapp/OsmAnd/issues/13848). The right way to resolve the ambiguity in those cases is to put the "junction:ref" tag on the motorway that represents the exit, but this tag currently isn't recognized by either OsmAnd or OSRM. So I'd still like to change osm.org/way/187934955 to a motorway_link to solve the problem for now, since I believe it's a reasonable approach in this case.

Hi! I noticed that the change of osm.org/way/187934955 from highway=motorway_link to highway=motorway is causing poor route guidance in OsmAnd and possibly other OSM-based applications as well. Since both of the ways leaving the highway=motorway_junction node (osm.org/node/1985694885) are tagged highway=motorway, routers do not know which is the main road and which is the exit. OsmAnd seems to describe a route taking either of those ways as "take exit 3", while OSRM (on osm.org/) just says either "at the fork turn left" or "at the fork turn right" and does not use the exit number for either way.

What was the reason for the change? Is it OK with you if I change osm.org/way/187934955 back to highway=motorway_link? (I verified that this would fix the guidance in OsmAnd.) If I don't hear from you within a week, I'll go ahead with the change. Thanks for your attention!

I changed the road to no longer be a "link" ("highway=primary_link" -> "highway=primary") because it has a name and links normally don't have names. If you think it's better as a link with a name, feel free to change the "highway" tag back.

News articles:
- https://montgomeryplanning.org/montgomery-county-planning-board-approves-resolution-to-rename-montrose-parkway-in-honor-of-renowned-local-abolitionist-the-rev-josiah-henson/
- https://www.mymcmedia.org/montrose-parkway-becomes-josiah-henson-parkway-on-friday/

I noticed the updated signs today at the intersections with East Jefferson Street and Towne Road. I didn't take the extra time to confirm the signs along the full length of the road. But I'll hazard a guess that it's least confusing to rename the whole road on OSM at the same time (including the "proposed" part even though I'm unsure of its latest status) and it's valuable to get the change out ASAP even if some signs are not updated yet.

This change isn't complete (for one thing, there are more small parking areas that I didn't take the time to map now) and may have some mistakes, but it should be better than the status quo. As always, feel free to make further improvements.

- Move the "Congressional Plaza" name from the building to a new landuse=retail with my best guess of which areas should be included.

- Map the parking area on the Congressional Lane side.

- Add stairs and tunnel between the Congressional Lane and Halpine Road sides.

- Adjust some geometry according to current imagery. I know imagery can be misaligned in general, but it looks reasonably well aligned to other existing elements. Hopefully this is at least better on net than the previous geometry.