Lee Carré (2021-07-02 16:43:59+00:00): This site (geo-location, not website) definitely needs more work. I was mostly doing a bit of housekeeping amid adding the TripAdvisor ID.

The geometry tweak was ‘joining’ (merging?) a couple nodes (where the 2 buildings share a wall).

For more substantial changes I'd prefer to do a survey (both for being confident of accuracy, and because I'd add the likes of entrances etc.).

Having checked imagery, what seems to have happened is that the building outlines were based on where the roof appeared to be (despite the imagery being not quite top-down (that is, straight down, along the normal line (perpendicular to) the ground surface plane; a perfect plan-view; tricky to describe short of seeing for yourself), thus there's an offset from ground; the satellite must've been further West (and a bit North, it looks like)), whereas the landuse outline is done against ground level. Bizarre, but there we go. That's why I'll take my time to do things properly, rather than slap-dash / quick-and-dirty.

Because the source this changeset was non-survey, I thought it best to deliberately leave the intersecting driveway & building alone.

During a proper survey, I'd endeavour to sort all of this out (including, now that I've found the widget for doing it, squaring the building corners (🙂), after correcting alignment / geometry). I'd also add whatever other PoIs I could find, and quiz the (lucky) receptionist for all the metadata to populate tags (like with the Normandie). For a real example of what I have in mind, see changeset #106857347 (though, there's yet more to be done, like adding an outline for amenity=parking).

From memory (of when happening to be walking past), (part of) that driveway (I think) is, in OSM terms, a building_passage (for vehicles; I gather that there's parking in the centre, so it might need to be highway=service instead).
This is a clear example of the limits of one's comfy armchair, compared to how readily apparent the details would be during a survey (though, the survey does take rather more time (both in terms of logistics & data input given the nature of handheld devices (despite the admirable best efforts of some dedicated developers)), thus I appreciate the desk-warriors / keyboard-bashers doing the basics which then only need correction & adjustment (and often not even that for the geometry, normally just tagging). Though, saying that, I encountered quite the mishap the other day: changeset #107217607 especially compared to how it was tagged before, so maybe you actually want the history of way #959722227.

“I haven't tried Vespucci yet, it's definitely on my to-do list [😉]”
Ha! Interesting. I've never used iD (or any other micro-computer editor). That's almost ironic. Seems that my entry vector to OSM is not the conventional one.

Based on experience so far, I'd recommend Vespucci.
▪︎Highly capable (at this point I feel like something of a caveman using a katana as a mere club, for not knowing any better how to use a sophisticated implement)
▪︎highly customisable (including QA flags / alerts / sources)
▪︎given the limitations of Android devices the developers have clearly (to me at least, having studied usability) made quite an effort to minimise the effects (and resulting frustration & tedium) in the UI design (both layout & interaction ‘work-flow’)
▪︎while not perfect (is any software?) it's quite stable & reliable (though, so I read, the builds published to F-Droid (which I use) aren't always the most stable (developer-recommended) ones); I only recall it losing user-data once, possibly twice, and those instances may not have been the fault of Vespucci
▪︎the developers (github repo) are responsive (and once thanked me for reporting a weird (and somewhat elusive, short of considerable explanation) bug)
▪︎been developed over a decade so is refined & mature
▪︎takes OSM standards (from the little I know about them) & conventions seriously, while still remaining flexible (at least based on my usage as a newbie)
▪︎makes use of JOSM presets (you can customise the list of URLs it fetches presets from) and there's talk of migrating to use iD presets (I don't know enough to comment on which is better, or even how they're different, I'm guessing that iD is simply the more popular editor)
▪︎there are tools to make some of the more common repetitive tasks partly-automated such as (user-configurable) templates for opening_hours syntax (in the various fields that's accepted) which has very nice UI integration into the OH sub-editor (various UI widgets, rather than having to manually type raw syntax (but you can still do that if you want)). When saving a new template, you can specify the criteria for when it should be listed, based on the context the call comes from; as opposed to simply listing all templates including irrelevant noise. Thus, there's much less penalty in adding more than a few templates, since (if saved with the right parameters) they would only show up when relevant. If you wanna see all templates anyway (perhaps a conditional is wrong, and the one you want is being hidden), the UI lets you do that, too.
▪︎quite customisable system for layers of what's displayed (background (reference) imagery (defaults to the standard OSM tiles but there's plenty of others, including various aerial imagery sources; you can also choose to have none (less data usage)), QA overlays of various categories, locally-stored geo-tagged photos, GNSS traces, QA tasks (OSM notes, Osmose bugs, MapRoulette, and I think some others) which are interactive (can view, comment, and close (or re-open) tasks) with possibility to upload changes individually or in-batch), a ruler / grid (e.g. for scale & alignment, or whatever you see fit to use it for), custom-source layers such as GeoJSON / WMS / OAM which take whatever URL you give them, and of course OSM data that's been downloaded), in what order, and can toggle visibility of each, with no apparent arbitrary limit on the count of layers (including multiples of the same type)
▪︎there's filters (tagging and/or presets) with moderate sophistication (non-trivial, but there are some things it can't yet do).
▪︎good control over what OSM data is downloaded, including several auto-download mechanisms (e.g. based on your GNSS position)
▪︎uses the OS notification system for QA concerns (can also be disabled)
▪︎a reasonable UI for determining what's been changed, and (for the session) remembers what you input into the changeset comment & survey fields, with the possibility to leave the current changeset open (or close by default, if you prefer), sets the imagery tag based on which imagery is displayed at the time of submitting the changes
▪︎remembers your recently typed key names, for more easily tagging multiple similar items, perma-remembers (across sessions) what values you've input for a given key
▪︎presets are (where sensible) ordered by MRU
▪︎has a hierarchical preset navigator (populated with the presets from the URLs it's configured to fetch them from), grouped (from the root / top level) by related category / type (e.g. highways is one top-level category)
There's probably more that I'm forgetting while typing this.

Even if only using it for (read-only) reference, it's useful.

Though, if you're familiar & comfortable with a desktop, then you may prefer running Vespucci on a fondle-slab (‘tablet’), though that may be less practical for surveying (weight, power-consumption, always needing both hands, size when not in use (a phone fits in the pocket).

I would strongly recommend having external power, so that depletion is never a concern. I use a non-cheap 12Ah pack, which I simply leave connected to continually supply power, which I've only managed to drain (completely) once (an intensive day of extended (~12 hours) surveying, when sunny (so the display was bright, which uses considerably more juice), and a bunch of data-collectors (e.g. cell towers, 802.11, etc.) running in the background in addition to what I'm using for OSM surveying, with the GNSS receiver module / chip set to stay active, and some apps configured to be less conservative with power-use.
Of course, spec the capacity to your needs.
I'd recommend Anker products, else Hama. Quality cables would also be wise; metal connectors, nylon braided for durability or (something akin to) PVC for waterproof-ness (though, could always wrap a nylon-braided cable in something like electrical (which I think is PVC) tape.

“But for editing and QA of bigger areas, using a computer with keyboard may be more comfortable.”
I would imagine so. At the moment I only have my nano-computer available for use (and am not gonna attempt to use a public computer for something non-trivial like editing OSM). But, surveying is what I wanted to do, anyway.

Besides data-quality for OSM, it's like geocaching or geohashing; tech + exercise seems better than tech while parked in a comfy chair. Though sometimes my feet disagree by the end of a long survey. I'll let you think about why I add benches to the map 😏.

Anyway, it was discovering the many various apps for OSM in F-Droid's repo, after purchasing a capable (read: recent / contemporary) phone, that finally spurred me to start delving into OSM in a practical way (e.g. collecting data), rather than only reading about it.
Started with StreetComplete (before even opening an account), which is an excellent introduction even for the tech-savvy.
I did have Vespucci installed too, and sometimes tinkered around in it (to see the data behind the scenes, as it were), but wamtddwtm learn first. I knew I would get to Vespucci in time.
Though, especially once I had an account, when encountering something using StreetComplete which it wasn't capable of fixing (e.g. asking me for opening_hours of a shop which has since changed hands, I was reminded of Vespucci as the kind of more-capable editor which would be needed for such a task, and was prompted to figure out how to make the necessary changes using Vespucci instead. As opposed to trying to learn from documentation in the abstract or for a contrived hypothetical scenario (chosen for being easy to use as an example, rather than being realistic or representative).

It still surprises me that, according to HDYC's analysis of my changesets, I use Vespucci about 50% of the time. I do seem to use it more; one changeset for what would be several quests in SC seems much more efficient (including for humans perusing the changeset log). Maybe it'll approach ~100% in future.

Back to your original point; Vespucci seems entirely capable (even if I'm not, yet), it likely just takes longer to achieve the same result. But, that's more about the limitations of the device, than Vespucci.

Since my device has a USB-C port, on my shopping list is the accessories for using external USB keyboards (and whatever else) with it, to avoid such limitations, especially when data-inputting (wouldn't necessarily need to take a keyboard with me; could just borrow theirs).

“JOSM and ID also have a lot of validation / QA checks included. E.g., I opened this area in ID and it complained about the driveway crossing the building (which was not changed in your edit). So it helps in finding such errors.”
Vespucci has similar, via Osmose bugs if I recall.

Though, I have an entire app just for the various QA bug-finding sources, which is often helpful (and much more efficient when adding a series of notes).

I'm actually wary of each; iD being implemented in a browser (though, I understand the motivation of why, but I'm old-school), and the J in JOSM means (from past experience) a bloated memory-hog of a runtime environment for a single piece of software.

Anyway; that was a very long reply to a brief review.