In JOSM the parking space preset has no default set for "capacity".

But I see you used ID to edit the spaces. That may be ID "doing its own thing". If you follow the tagging email list you'll find many threads cropping up detailing complaints about ID "doing their own thing" with presets, even when the wiki defines a different way.

So it is drift between the wiki and what the ID developers decide to do with their presets.

According to amenity=parking_space the default value for "capacity" is 1:

Quoting from the URL: "If an area represents more than one parking space (of equal kind), use capacity=* to define the number of parking spaces it represents. The default value for capacity=* is "1" if not mapped otherwise."

As these are single parking spaces, for one vehicle each, the wiki is clear that "capacity=1" is not required. Which is why I did not add "capacity=1" to the spaces.

Your spam node that was placed in an incorrect geographic location has been removed.

OpenStreetMap is a map, therefore the accuracy of the geographic location of items in the map is very important.

Yes, that is what the wiki says, but you *deleted* the subtag service=parking aisle from *more* than just the "main paths and entrance/exit" ways.

You also removed the subtag service=parking_aisle from "these (often multiple) subordinated ways that allow access to the rows of parking spots" which are exactly the ways the wiki page you quote state should also be mapped with service=parking_aisle.

I.e., you removed service=parking_aisle from ways where it should not have been removed according to that wiki page.

Hello and welcome to OSM. Please note that your edit to Clarenford Station park here modified the park boundaries to link several of the edges of the park boundary to coincide with the way defining 13th street. However, remember that in OSM, streets are defined by a single line running down the center of the street. Yet in the real world, all streets have a real width. Moving the park boundary polygon to coincide with the street way would mean that the area of the park would extend across half of the width of the street all the way to the very center of the pavement.

In the real world, no one would consider the "edge" of a park to coincide with the center-line of the adjacent street. The edge of the park would coincide with the outer edge of the street. So moving the boundary of the park to coincide with the way defining the street would incorrectly denote the real world boundary of the area of the park itself.

I have disconnected the park boundary from the street center line and aligned it with the true edge of the park (as seen in the Esri imagery).

Also, note this sentence on this page here in the OSM wiki: osm.wiki/Unconnected_ways under the section titled "Crossing ways": "Note that navigable ways should not be connected with other ways like landuse etc." Connecting the park boundary to the street way would be connecting a navigable way (the street) with a non-navigable area (the park area).

For whatever reason the alexanddria URL isn't working for me at the moment.

In any case, no matter how much folks might want the name changed all the way to DC, the legal fact is that Arlington's hands are tied by the VA Legislature and the old name will still exist, in Arlington, until the Legislature unties Arlington's hands.

With Alexandria now renaming its portion, it is possible the VA legislature will allow Arlington to make the corresponding change. It is anyone's guess now as to when that might occur.

There's only one problem. The portion you renamed is in Arlington County, and the portion in Arlington has not been renamed because the VA State Legislature has not given Arlington county the authority to change the name.

The Jan 1 change was only to the portion in Alexandria City.

See https://www.washingtonpost.com/local/virginia-politics/alexandria-renames-jefferson-davis-highway-to-richmond-highway/2018/06/23/a1af93c0-76fe-11e8-b4b7-308400242c2e_story.html?noredirect=on (specifically the last paragraph) and https://www.arlnow.com/2018/11/16/county-readies-renewed-legislative-push-to-change-name-of-jefferson-davis-highway/.

The name within Arlington is still legally Jefferson Davis Highway. Everything north of Four Mile Run is in Arlington, and still legally has the old name.

See the image here: https://postimg.cc/FdTFYSR0

Note, I checked in ID, and ID does not show this, it seems to show that everything connects.

The changes in 65826920 are very close. The building:levels and building:min-level tags are missing from the parts, and two of the parts don't fully connect (this is likely a symptom of using ID to make this complicated of an edit).

I can fix up the remainder if you like, since I can obtain the prior tag's values on the parts via. JOSM's reverter plugin.

I can do that, or I can do some experimenting with trying a partial reversion (the JOSM reverter plugin has a checkbox for 'partial reversion', I've just not yet attempted to do a partial).

The reason I suggest trying reversion is that adding in the 3D lines was tedious, but straightforward, with the buildings plugin for JOSM. But I used ID for about a year before switching to JOSM, and so I can say with confidence that using ID to add the 3D lines back in will be a gigantic pain. If the partial revert works, then the deleted lines come back, but your other edits should remain in place.

The outer baseball diamond way in your changeset that is closest to the intersection of Washington Blvd. and N. Quincy St. has no tags, and appears to not be part of a relation. So it seems to be completely untagged.

Ah, but looking at it more closely, there is more in the change set than just The Doctors Building edits. So a simple revert would leave your other edits in limbo.

Reverting the change set would be the easiest way to restore the 3D elements.

Was there a reason why you deleted all of my 3D building (osm.wiki/Simple_3D_buildings) data for The Doctors building here? It is now back to a simple rectangle and has lost all of the 3D elements that I added back in September.

The tag tourism=apartment is *NOT* the correct tag to use for this node. See tourism=apartment.

For an actual apartment, the proper tag would be building=apartments (see building=apartments).

You have been informed of both of the above issues with your edits multiple times in the past, and yet you continue to create the identical errors. Why do you not correct your methods so that you stop making these errors?

If what you wish to add to OSM is a missing address value, you should simply add a node tagged with addr:street and addr:housenumber. You should leave off the wholly incorrect tourism=apartment tag and just add the two address tags that hold address values.

The tag tourism=apartment is *NOT* the correct tag to use for this node. See tourism=apartment.

For an office building, the proper tag would be building=office (see building=office).

You have been informed of the tourism=apartment issue with your edits multiple times in the past, and yet you continue to create the identical errors. Why do you not correct your methods so that you stop making these errors?

Further, if what you wish to add to OSM is a missing address value, you should simply add a node tagged with addr:street and addr:housenumber. You should leave off the wholly incorrect tourism=apartment tag and just add the two address tags that hold address values.

The tag tourism=apartment is *NOT* the correct tag to use for this node. See tourism=apartment.

For an actual apartment, the proper tag would be building=apartments (see building=apartments).

You have been informed of both of the above issues with your edits multiple times in the past, and yet you continue to create the identical errors. Why do you not correct your methods so that you stop making these errors?

If what you wish to add to OSM is a missing address value, you should simply add a node tagged with addr:street and addr:housenumber. You should leave off the wholly incorrect tourism=apartment tag and just add the two address tags that hold address values.

The tag tourism=apartment is *NOT* the correct tag to use for this node. See tourism=apartment.

For an actual apartment, the proper tag would be building=apartments (see building=apartments).

You have been informed of both of the above issues with your edits multiple times in the past, and yet you continue to create the identical errors. Why do you not correct your methods so that you stop making these errors?

If what you wish to add to OSM is a missing address value, you should simply add a node tagged with addr:street and addr:housenumber. You should leave off the wholly incorrect tourism=apartment tag and just add the two address tags that hold address values.

The tag tourism=apartment is *NOT* the correct tag to use for this node. See tourism=apartment.

For an actual apartment, the proper tag would be building=apartments (see building=apartments).

Also, the house number does *NOT* belong in the "name" tag, the house number belongs in the addr:housenumber tag instead.

You have been informed of both of the above issues with your edits multiple times in the past, and yet you continue to create the identical errors. Why do you not correct your methods so that you stop making these errors?

Additionally, placing this node in the middle of the street is also not correct. It should be placed near where the building that is referenced by this address is located. Which is clearly not in the middle of a travel lane of South Court House Road.

Further, if what you wish to add to OSM is a missing address value, you should simply add a node tagged with addr:street and addr:housenumber. You should leave off the wholly incorrect tourism=apartment tag and just add the two address tags that hold address values.

Your incorrect tag name and contents for opening hours has been deleted.

Feel free to add back a correct opening hours tag, see opening_hours=* for details on the correct tag name and the proper value syntax.