Hi! I've been trying to keep the construction status of this area up to date on OSM for the last few months, and I noticed that your changeset opens several important roads and closes others. I briefly visited the area yesterday and confirmed that the status of these roads is still as it was in my osm.org/changeset/110811542, not as in this changeset: most importantly, a segment of Executive Boulevard is still closed and the entirety of Grand Park Avenue is still open. Where did you get your information? From imagery? (It looks consistent with the current "Esri World Imagery".) Remember that imagery can be months or years out of date, so you should think carefully before overwriting OSM data recently changed by other users in a survey with your own data based on imagery.

Is it OK with you if I go ahead and revert the open/closed status changes? In the process of making those changes, your editor seems to have created, deleted, and repurposed several way objects with no net effect on the resulting geometry, which makes the object-level history more confusing to view. I'd like to take the opportunity to revert those object manipulations as well so that it will be easier for users to compare the object-level state before your changeset and after my partial revert. I'll keep the changes from your changeset that seem plausible to me:
- Adjustments to node coordinates and refinements of ways with additional nodes, except for the intersection of Executive Boulevard and Grand Park Avenue, which I am sure is now at node 5537854486 (as I had it) and not 5344536417.
- Changes of "highway" tags from "service" to "residential" and from "unclassified" to "tertiary".
- The naming of several segments as Grand Park Avenue. I left them unnamed because I thought the signage was unclear on the ground: it just said "Grand Park Avenue" at one end and "Executive Boulevard" at the other.
- The "lanes=4" tag on Grand Park Avenue.

Concretely, the changeset I'm proposing is https://mattmccutchen.net/private/20210927-restore-exec-grand-park.osm . You can open it in JOSM and review the specific changes by searching for "modified OR deleted" with "all objects" enabled and pressing the "History" button on individual objects. Is it OK with you if I submit this now?

Thanks for your attention!

Per the discussion at https://help.openstreetmap.org/questions/81647/best-practice-for-mapping-5-month-road-closure-with-approximate-end-date, this may not be the ideal solution, but it should be no worse than the status quo.

Unfortunately, this change seems to have made pedestrian routing _less_ accurate in some cases, at least in OsmAnd. From what I read, the difficulty of pedestrian routing is a known problem in OpenStreetMap, and it's acceptable to not alter my mapping to accommodate routing limitations.

My hope in mapping sidewalks separately was to provide some information about potential wheelchair accessibility. I guess I'd like to specify that pedestrians are allowed to cross the residential roads anywhere, but there is a kerb, and most sidewalks have frequent breaks in the kerb that I did not want to do the work to map (house driveways), while the sidewalks adjacent to the park have only the mapped kerb breaks.

The connectivity and restrictions are from a survey, while the coordinates of added elements are from the imagery.
- Signed "no U turn" on eastbound Montrose Road at Montrose Parkway. (Now, OsmAnd proposes an unreasonable U turn where Montrose Road becomes a single carriageway, but I won't address that now.)
- Westbound Montrose Parkway can turn into 2101 East Jefferson Street.
- There is now access between eastbound Montrose Parkway and Stonehenge Place. The imagery shows the gap in the median, but the markings in the imagery that prohibit access are gone in my survey. Also fix typo in the name of Stonehenge Place.
- There is a separated left turn lane from northbound Rockville Pike to Hubbard Drive, presumably to prevent traffic entering from Montrose Parkway from making that turn.

Sidewalks are traced from Esri Clarity (with extrapolation where the view was blocked by trees) since my GPS receiver is less accurate. Crossings are surveyed.

This change is big enough and uses enough mapping conventions new to me that at least some minor things are probably wrong. Coordinates are approximated from imagery and/or my phone's GPS receiver and may be off a bit.

In addition to the important correction to the "from" and "via" members, I changed this from "only_left_turn" to "no_straight_on" because OsmAnd had trouble with the "only_left_turn" in my tests.

This is an attempt to correct all of my previous changesets according to https://help.openstreetmap.org/questions/80073 . With the help of Bing and Esri imagery, I was able to come up with reasonable estimates of the starting points for all but one turn:lanes tag. I hope I got everything right; it doesn't seem worth the trouble to check it all again.

Clarification: Having read osm.org/note/1791672, I confirmed that the sign said "Elementary" and not "High" school, but I didn't check the spelling of the rest of the name.

FWIW, I was mistaken: OsmAnd seems to recognize access:conditional. I think this code (https://github.com/osmandapp/OsmAnd/blob/feadaa0da5804d9f3312e6df852ef96093fb82ec/OsmAnd-java/src/main/java/net/osmand/binary/BinaryMapRouteReaderAdapter.java#L237) is involved, though I haven't traced the entire data flow.

Apparently access:conditional is well-established, but I can't find a router that supports it to test this change. :(

The segment of eastbound O Street that I changed is somewhat artificial to OSM's representation of the complex intersection, and I didn't see any turn:lanes signage for it specifically. But the combination of the turn:lanes I added with the existing value for southbound 1st Street seems to correctly model the reachability of eastbound New York Avenue and O Street from the left three southbound lanes of 1st Street (see osm.wiki/Relation:connectivity#Basic_summary). Indeed, it fixes the lane guidance in OsmAnd for the maneuver from southbound 1st Street to eastbound New York Avenue. It might be better to use connectivity relations directly from southbound 1st Street to eastbound New York Avenue and O Street, but fewer routers support those, and I'm unsure of the exact target lanes on eastbound New York Avenue and O Street, which would need to be stated in the connectivity relations.

turn:lanes:conditional seems to be very unofficial (in particular, I'm unsure how I'm supposed to protect the semicolon in the conditional value; I took a look at taginfo for prior art), but that's the fun of OpenStreetMap, right? I'm having fun anyway. If enough instances of turn:lanes:conditional are added, maybe routers will be motivated to learn to parse it.

Concerns:
- In several cases, I entered turn:lanes with a number of lanes that does not match the "lanes" tag because additional lanes for turns begin shortly before the intersection, but I didn't know the exact place where they begin in order to split the way and update the "lanes" tag. I hope this is OK: I think most consumers of the data will do something reasonable.
- Northbound Connecticut Avenue at Jones Bridge Road: I think it only makes sense for the rightmost lane to be "through;slight_right;right", but I couldn't confirm this by signage.

Information about the construction project is at https://www.montgomerycountymd.gov/whiteflint/ . I used the vehicle detour map there to plan where to survey, but I didn't copy any information directly from that map because I was unsure of the licensing. I used GPS traces to locate the closures and tried to get the connectivity right, at least for motor vehicles.

Review requested!!! I've probably done some things not according to convention, but I hope this is at least much better than the status quo. And someone who cares about pedestrian and bicycle access is invited to update that part. Discussion of the complete update to this area beyond this initial changeset can take place at osm.org/note/2590993 .

Signs I saw:
- Entering the changed segment from the traffic circle: "One way" with a forward arrow.
- Attempting to turn east onto the segment from its west end or from the way between Kenamond Hall and Dining Hall: "Do not enter".
I'm not certain the entire segment is intended to be one-way, but I thought it was likely enough that marking it one-way was better than adding many turn restrictions given the lack of support for "no_entry" in routers (https://help.openstreetmap.org/questions/49513/should-i-use-the-no_entry-turning-restriction).

- The time-based restriction at westbound Blackthorn St is "do not enter" from any direction (surveyed 2021-02-25).
- AFAICT, there isn't an unconditional "no U turn" restriction from southbound Connecticut Ave at Dunlop St (surveyed 2021-02-24). The time-based "no left or U turn" at this intersection is correctly coded in relation #12252810. There is an unconditional "no U turn" at the fire station entrance just north, but that cross street isn't on OpenStreetMap yet at all.

I don't think this change is particularly important: most of the minor roads don't have turn:lanes tags. I'm just having fun because the local transportation department recently signed these turn lanes at my request.

I know by survey that a left turn from northbound Citadel Avenue to westbound Old Georgetown Road is blocked by the median on Old Georgetown Road. I don't know how far the median extends; I've taken a guess from the Bing imagery. I wasn't at all confident of how to make this edit, but I hope what I did will be better than the status quo until someone more experienced takes a look.

Oops, the changeset description is backwards: the segment was moved from Greenhill Road to Old Lancaster Road.