In the absence of separate sidewalk ways, however, it is necessary to connect them to maintain the pedestrian routing network.

Many of these businesses that you've added were already mapped as part of the buildings. Please check that you don't add duplicate data.

Just because it isn't typical doesn't mean it's wrong.

It is tagged surface=dirt, and it should not be tagged natural=sand. Neither should SF Giants stadium.

"This tag should not be used for the infields of baseball or softball fields (a form of tagging for the renderer) - use surface=dirt instead." - natural=sand

Thanks. I changed the outer part to a building outline and filled in the rest of the building parts: changeset/137765483

It should still have some sort of feature tag describing what it is though, a node with nothing but name=* isn't very useful. Maybe some other value for place=*, like "quarter" or "neighborhood"?

Thanks for contributing to OSM! Please use the changeset description field to describe the changes you made and why; for example, "Changed the website of a post office to be up-to-date." There's more guidance and examples at this link: osm.wiki/Good_changeset_comments

I don't understand what you mean by "self relation" or relating objects "to" others. Relations are objects themselves, with tags, that contain other objects. Each child of a relation has a role. A building relation is supposed to have all of the tags for the building, and have all of the building parts as children, with the role "part." A building relation is also supposed to have a building way with the role "outline," and that seems to have been the only error.

I would be very cautious of blindly fixing validator issues. They often aren't causing any harm, but removing data rather than fixing it definitely does.

See here for documentation on undoing changes: osm.wiki/Change_rollback There's a tool for it in JOSM, as well as two web apps.

See here for documentation on the building relation type: osm.wiki/Relation:building It may have been necessary for the 3D mapping to work, though it looks like it was missing an outline.

Please use descriptive changeset messages. For example, "Extended a residential area." This page has more guidance and examples: osm.wiki/Good_changeset_comments

It's still useful to keep address locations, even if there is no occupant at that address, so that geocoding still works.

Well, the "easy" fix is to move the descriptions into osm.wiki/Tag:description=. There's also sport=billiards, but that usually needs a primary feature tag. In general though, you can always ask the tagging mailing list, OSMUS Slack "tagging" channel, or the forum, for tag suggestions.

See the wiki page on name conventions: osm.wiki/Names The name= field should be for actual proper names, not descriptions.

Please see the guidelines here for naming objects: osm.wiki/Names Names in OSM should refer to the actual proper name to which the items are commonly referred, and should not include any plain descriptions or internal reference units.

Also, you can use level=* to indicate what story of the building something is on: level=*

In OSM, accuracy to the real world should always be prioritized over readability of the map. Mapping style over accuracy is called "mapping for the renderer," and there's more explanation here: osm.wiki/Tagging_for_the_renderer . OSM is a spatial database that can be used by lots of different software, so making it look good in one might break another. So as a standard, we make the map as accurate as possible to reality, and let the software figure out how to do things like place labels.

It's still useful to know, for example, whether unit E is towards the north end of the building or the south. There's no such thing as too much detail on OSM! These PoI were added through an import project we've been running, if you like you can try to contribute there as well! https://maproulette.org/browse/projects/42122