Thanks for fixing my mistake from changeset/115794413. I probably pressed the wrong thing in the JOSM tag editor as I was trying to copy several tags from another Subway on OSM. I will try to be more careful.

Re the representation of the two areas: I thought the duplication of the node sequences of the two ways was a lesser evil than the complexity of multipolygons with a shared way, but I don't feel strongly about it. The new boundary between the areas is an estimate from imagery; feel free to improve it.

There's a plan to build another school on the Old Georgetown Road site (https://www.montgomeryschoolsmd.org/departments/facilities/construction/project/woodwardhs.aspx). I'm unsure how it is best to map the site in the interim. I saw today that the building was demolished; I couldn't easily tell whether the sports fields still existed or were accessible.

I'm trying to avoid any possible problems with osm.wiki/Copy_content_from_a_business_website. I'm treating the lookup of location-specific URLs on the business web site as "common knowledge", but all other data is only what I surveyed from publicly displayed signs at the location. survey:date is 2022-01-07 (I forgot to add it to the changeset).

Oops, somehow most of the tags I intended to add didn't get added. Fixed in changeset/115798909.

Source is survey. I guess I'll avoid submitting changesets with OsmAnd unless/until it gains support for specifying the "source" tag.

There are other businesses in the same building. I'm only adding Subway because it's the one I care about.

I wanted to make sure you're aware that at least some users feel that closures of less than a few months shouldn't be applied to the unconditional tags; see the previous discussion on https://help.openstreetmap.org/questions/81647 . If you got a wrong route because your router doesn't support "oneway:conditional", the best solution is to fix the router. But I don't have a strong opinion and won't object to the change to the unconditional tags here.

However, there is a more specific problem: this changeset reversed several ways in preparation for tagging them "oneway=yes" but left the existing "oneway:conditional=-1 ..." tag in place, so routers that honor "oneway:conditional" (and give it priority over "oneway" when the condition is satisfied) now think this part of Randolph Road is one way westbound, which is the opposite of reality. I've made the minimal fix to this problem in changeset/115451153 by replacing "-1" with "yes" in the "oneway:conditional" tag. An argument could be made that the "oneway:conditional" tags are currently redundant and should be removed completely, but I didn't do that for now.

Thanks for your quick and kind response. I submitted changeset/111820423. We appreciate your support for OSM!

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 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 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. :(