Some of these are not building=house. See (for example) way #959722227 & changeset #107217607.

I didn't manage to survey the row on the northern side (Grosvenor Street), but while they do look residential, they're not necessarily a house (at least some appear to be closer to apartments or possibly semi-detached).

If tagged as simply building=yes then StreetComplete surveyors will see a quest prompting them to specify the building type.
If, like in this changeset, the building type is already set, then the SC quest is skipped without the possibility of changing the type (within SC; a more generic editor is required).

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.

Ah-ha; I was looking in the menu, when it's actually on the toolbar.

Right, will definitely be using that little gem in future (and, if I can recall them all, hopefully fixing my earlier attempts at adding buildings).

I had looked for such a function, but must be missing it.

Right-angles for rectangular buildings would be much better.

Still getting to grips with the less trivial features of such a capable editor. Took me a while (and several cycles of editing attempt & undo) to figure out that the incantation to simply add a node to an existing way; it was simpler than I was assuming.

Like any good tool, Vespucci seems to offer the components; it's up to the tap-and-grunt ape to figure out which components to use in which combination & order.

But, hey; makes the moments of revelation / discovery all the more memorable. Firmer steps toward mastery.

“Crazy detailed mapping! Very cool!”
Changeset #106178413 involved quite a survey (which was far from complete, given the facilities of the hotel, but I'd had enough by that point; cold (sun had set), hungry, weary from all the walking & standing). I was there for well over an hour.

Reception was most helpful, though, and once she learned that it was for OSM and what OSM is (as conceptually different to proprietary maps) she was at least somewhat interested in the process (and that they could update it themselves). She expressed concern over accuracy of the data she was supplying in order to avoid misleading would-be customers (a level of professionalism which is lacking in many competing establishments). Pointing out that management could regard it as gratis advertising seemed to add motivation to engage in the lengthy Q&A (some answers took a while to yield, but she seemed to like the challenge). She also seemed encouraged by the potential uses and possible benefits of such extensive data. The non-dumbed-down version would be something like: imagine being able to interrogate the OSM DB to find the hotels matching your exact requirements. It'd beat the pants off of any hotel-booking webs(h)ite I've ever heard of. Example: to my surprise, some hotels are dog-friendly; I can only imagine the trouble for pet-lovers to find somewhere suitable.
I should probably note that she wasn't local, which likely explains her non-shitty attitude. I say that as someone who's as local as it gets; the negativity starts to take its toll when your own mindset is more optimistic.

Some establishments are indifferent or regard it as a hassle (perhaps because, in this backward island, most haven't heard of OSM(! yes, I know, the shame of it!), some folks are outright hostile (note #2286368). So, with the ones which cooperate I like to reward them with a through job. Had a comparable (positive) experience with Just William in the Central Market (node #2229549937). Even had a chat about related topics, which was interesting. He actually called me over, because he was curious what I was doing (I clearly wasn't buying, despite speaking to several shop-keepers, and double-backing on myself several times). I didn't have any money on me, that day (I prefer to remain light for on-foot surveying, since I already have a lithium brick (external battery) in my pocket), but next time I'll crack out Vespucci to give the full treatment and then buy some of his fruit & veg.

If you like this buffet of tagging, then also see way #168413554, changeset #106927141, way #212439496, and changeset #105935524.

“the website says "Havre de Pas" as addr:street? That's a bit strange, for routing I would also guess "Greve d'Azette" should be the address.”
That was my thinking.

I suspect that they mean addr:suburb=Havre des Pas (if not suburb {rolls eyes at Yankland terminology} then something referring to an area or region), which would actually make sense. The hotel's location means that it ‘touches’ several different(ly named) roads.

Though, where's the front and parking entrance? Greve d'Azette (according to OSM, maybe I should've checked that while there; whoops).

The hotel could claim that they were on the moon. Doesn't make it true. I was thinking, too, of verifiability.

Plus, if it turns out to be wrong, then it can always be changed again.

Another factor is that it doesn't seem to be some historical relic. The road named Havre des Pas is on the West side of the hotel. Yet, the hotel expanded over time, and I'm pretty sure it started on the East side of the site and subsumed buildings to the West. There's an old disused entrance near the South end of Beach Road (on the East side of the building), for example.

If it was between Greve d'Azette and Beach Road, then sure. But, addr:street is clearly not Havre des Pas.

“a matter of taste (like much OSM tagging...)”
Yes, that's becoming more apparent from certain other sources. I recall an argument of sorts over (for the likes of bus stops) passenger_information_display versus departures_board.

Though, sometimes new ideas can be very constructive; I recall reading the history of why diet:* came about, due to the problems of ambiguity from trying to use cuisine=* for multiple types of data.

“Maybe for economy, you could just use one "source=survey", since all the facts come from your survey. Only if some tag has another source, that could be indicated with a separate source:x=y”
I have certainly considered that.

I'm thinking about when someone else edits it, though. Being unspecific would cause ambiguity.

Notice that for frequency, while I do add what is very likely to be the actual value, I never include source:frequency=survey (since it's just a guess).

I'm also hoping that by doing it this way, overly-keen newbies (throwing caution to the wind) will (might?) leave alone the ones marked as coming from a survey, even if they mess around with others (which aren't so marked).

I don't mind being verbose, for the sake of accuracy & precision. Hopefully it keeps things clear for other mappers, too.

I'm reminded of when, for the multi-storey carparks, I went to the Parking Control Office to ask what the capacities were (counting the spaces of a small surface carpark is one thing, but a multi-storey (with several hundred) is another).
Surprise, surprise, they didn't match the values in OSM. It wasn't even a predictable offset (e.g. excluding spaces for the disabled, in cases where I'd counted those (few) during survey).
Since there was no citation of where the OSM numbers had come from, and being less than keen to go through the history to find the changeset which added (or list changed) the capacity in order to check what the changeset's source tag stated, I replaced the valve in OSM and promptly added source:capacity(=Parking Control Office).
Thus, instead of being some arbitrary number, if someone wants to dispute the current value, they'll have to see & raise my source with an actual survey. But, short of doing the tedious walking along every floor in a grey concrete box, I'll take the number given by the folks who administer the place, over a number of dubious credibility.

“I think official_name is not needed since it's the same as the main "name".”
Similar to above, this came from witnessing disputes over exactly how roads should be named (seemingly regardless of what signage says). Some folks want OSM to match old (paper) maps. Thus, I started using official_name, short_name, and others; seemed best to avoid conflicting preferences, since the solution becomes making one's favourite tool use whichever tag one prefers instead of having an endless edit-war over the value of the name key.

If someone wants to mess about with name=* then so be it, but at least official_name might still be preserved.

Since there are cases for which the official_name and the colloquial name differ (Springfield Stadium comes to mind), setting both makes it clear & confirms that what's rendered is actually the proper name.

If official_name weren't set, then what is name exactly? My interpretation of what to call it?

Though, thinking about it, official_name should actually be exactly what appears on the sign (which is all-caps, for starters), while I would keep it Title Case for regular name (for readability).
So, they should be different by nature.

To me, this is another instance of accuracy, throughness, and completeness over convenience.

Compare, perhaps, someone setting opening_hours:covid19 to match opening_hours. One could argue redundancy, but it makes explicit that they're unchanged. Without *:covid19 it remains uncertain if they're the same, versus if someone simply hasn't yet added the differing hours.

“I'm not an expert on power mapping”
I'm certainly not, either.

I'm moderately familiar with electrics (besides general interest, for example I was an AV tech in the past which exposed me to memorable things such as 3-phase 125A cabling (notably how heavy it is, even in short runs) with enormous Ceeform connectors on the ends), but utility network level is beyond my experience. But, gotta start somewhere.

Anyway.

“might power=transformer fit even better for small installations?”
I also duly consulted the wiki, having the same question. I think it was on the page about transformers where I read an FAQ about this very matter.

The conclusion was that power=transformer is for an individual piece of equipment (compare an amenity PoI within a building). While power=substation is for the general location (area, building, whatever) which contains (perhaps multiple pieces of) equipment.

Aside from that, there's also changeset #105096082 in which another (experienced) mapper opted for power=substation from a note a had added earlier. So, I followed his example.

Some of the locations host multiple pieces of equipment (I assume transformers, from their appearance).

One of the recurring snags, is that while the signage might be obvious, the actual electron-plumbing is typically either inside a (small) building or behind a completely opaque (and tall) gate.
I would also be guessing that they're transformers (since I don't KNOW that they are). There's other varieties of network equipment, too. An obvious one would be switches (which I imagine the larger substations very likely have). Thus, substation is a safe somewhat-generic valve for the power key. That way, locations are being marked for easier re-surveying (of specific equipment, or when in a dedicated building then marking the outline as a way tagged with building=service and the various power=* related tags, instead of just a PoI node) when detail can be added. Basics first, essentially.

“maybe a "substation=*" tag could be added if you find out what kind of substation these are (minor_distribution?)”
That's been a nagging issue; I don't know what type they are, and suspect that one would either need the knowledge of a utility engineer or to ask the operator.

Thus, I very deliberately left that field blank. Same goes for voltage. Ironically some street_cabinets have rating plates on them, yet substations don't.

Besides, not all are the same. Just the other day I happened upon one (node #8880775659) which actually stated (on a separate (old-looking) sign to the ‘electrocution awaits behind this door for anyone determined to open it’ one) that it was 11kV (from memory (which isn't to be trusted in my case) JEC state that they offer 240V, (something like) 400V and (I gather for industrial customers who need it) 11,000V). So, was pleasantly surprised to find such an 11kV substation. Yet, I can't think of any industry near there (it's all retail (or comparable commerce) & residential around there). So, I suspect that it may be a more major substation (rather than, like you say, just a strategically-placed step-down transformer). There were suggestions from the location of the door and geometry of the building that it was a larger-than-average substation too.

I really would like to be able to add all the related (electrical properties) tags, but I would be blindly guessing. So leaving unspecified seems best (to avoid misleading).
Even if I were an expert, and could determine from a casual inspection, that won't be verifiable to other surveyors (unlike if it were printed on signage, as in the one case I mentioned re voltage).

To me, accuracy is more important than completeness.

However, in future, despite my doubts, maybe such info can be extracted from the operator (even if that means avoiding official channels, and finding a cooperative engineer who either knows or can find out).

A major part of why I mark them when I find them during a survey outing, is that based on experience of the cultural attitude here, I highly doubt that even a list of locations (let alone operational details) would simply be provided upon request (I can foresee the ‘security’ catch-all excuse being readily cited). So, I haven't even bothered asking. They can't stop discovery-by-survey, though. Survey also avoids any copyright problems (since, to my (non-lawyer, but well-read) comprehension of copyright, it counts as my own work).

It's considerable work (though, I'm capturing other data along the way, but thus I also appreciate your recognition of it), but seems more durable than copying from someone else's list.

I say that while also being of the opinion that such data should be public-by-default (including being actually published-by-default, too). But, it is my learning about copyright that makes me wary of the risks. Data from survey is most definitely the belonging of OSM (which I value, being anti-proprietary).

I suppose, also, as motivation; Jersey being small and finite (a very clear natural geographical boundary, rather than merely a line on a map running across the land), it's not unrealistic to actually achieve ‘fully complete’ mapping status.

Maybe, then, the JEC itself could be encouraged to maintain that aspect of OSM since they hold all the data internally.

“following up on your request for reviews”
👍
Much appreciated.

There's a few different categories, so I'll post a few separate comments in response.

“I'm impressed at the detailed tagging of those substations. Well done!”
Thanks. That feels flattering, as a novice.

I noticed the stark lack of most any infrastructure (mapped) on the island, and since it's an interest, decided to take it on. Most of the ones marked in Jersey are my additions. Though I'm sure you're already familiar, I'll mention Open Infrastructure Map, which is a helpful rendering (e.g. of their geographic distribution), and for re-finding them easily.

Town is easier; mostly a case of wandering around (doing other things) and taking notice when I happen upon another. Amusingly, surveying at night has yielded quite a few discoveries; when it's quiet just gotta listen for & follow the buzzing 😄.

This is why, if you're trawling through my changeset history, you'll notice that adding a substation is interspersed among unrelated changesets. I mostly discover them as I go. Some are well-hidden (or, at least, inconspicuous) or in odd locations. Often it's the standardised JEC hazard triangle notice which catches my eye and gives away their hiding spot.

My hope, eventually, is that with the nodes of the network well-surveyed, an experienced infrastructure mapper might be able to figure out how (in terms of cabling) they're inter-connected. There's another mapper, with a stated interest in infrastructure, who added the newest link from France (from where most of Jersey's electricity comes, La Collette is more of a backup) that may be promising for such a task.

The countryside parishes will be the troublesome areas; lesser density, and less easy to spot (more places to hide them).

To turn the tables, for a moment (and almost in jest); it would be helpful if citing (in source=*) the note ID(s) in question, so that they can easily be found in future once they become hidden on the map-overlay.

Though, I'm guilty of forgetting to do this, too.

When I'm on form, the note ID is cited in the changeset, and the changeset ID is cited in the note. Bi-directional pointers.

That was informative. Thankyou.
Especially knowing that notes are indeed useful; I've added quite a lot, lately. So much that I wondered if it was excessive.
Your remarks have given me ideas for improving the (future) notes that I add. In retrospect, I had commented on the tacit assumption that someone else (with more experience) would come along doing a survey, but that doesn't appear true in little Jersey. Thus, I now see that for those not in the field the context is either lost or not apparent. Probably resulting in lack of info to be confident in making any change.
Though, part of my (quasi-subconscious) thinking was that identifying that a problem exists (sometimes, when physically there, the disparity between the map and reality is stark & obvious) is the first step (almost like a reminder, for future-self if no-one else, but public so that others can jump in if they wish). Other contributors could then comment on the note with what's needed to fix said problem or some other kind of exchange in order to yield resolution.
Having recently started dabbling with using imagery as a reference (I assume that all the ones available in Vespucci have been checked for copyright licensing issues, since I notice that Google isn't among the list; that's part of why I prefer surveying, no BS from draconian copyright (and it's trolls)), it was quickly apparent that even those which include “Clarity” in their title lack resolution for non-large (that is, anything smaller than a typical building) objects (the kind which would only need a node, being too small to warrant a way) or the (clear) image is clearly (pun intended) out-of-date (even compared to other imagery, let alone survey), and so dropping a note to confirm that something is indeed there, and what it is (since missing tags trigger various QA (in which I'm including StreetComplete quests which prompt for disambiguation e.g. of type)). Though, one issue tripping me up is misalignment & offsets. Vespucci has the ability to query some (online?) DB but couldn't find published offsets even for (notorious, I gather) Bing. Different sources (even from the same supplier) don't match. The GNSS receiver in my nano-computer also isn't consistently accurate, either; typically (even with excellent reception) the uncertainty radius seems to be ~5m (I recently learned that the chipset is from 2016, despite purchasing (as new) the phone in 2019).

(Besides what just turned into an essay (all by itself, I swear(!) 😁)) I don't really have much to add; I concur with the points you make.

Thanks for your intent to give constructive feedback on my changesets seeking-review.

See changeset #78688059 discussion.

Would've been much better to move the original node.

At the minimum, the tags should've been transferred over; the deleted node has some (tags) which the new one doesn't.

🙂 👍

Ah, good.

I wondered if it might have been related to the new bus-lane road-layout change.

Kudos for hunting down duplicates.

Ah, I see. Fair enough, then; that's more of a technical glitch (or shortcoming) than human-error 🙂.

At least there's some kind of silver-lining to the giant mid-orange boxes.

One motivation to more harshly filter was that there's relatively little activity in my locale, so the jumbo-boxes were causing very low signal-to-noise. Around half the changeset list entries were simply irrelevant. Too much mental filtering.

But, also means missing out on interesting conversations like this one.

Indeed. I, for one, am all about quality. There's a dizzying amount to do for such a small band of regulars. Even in town there's quite a lot missing, nevermind out in the farming parishes.

Getting into OSM has been on my list for far too long. Hence my first changesets were quite large, since I'd been collecting data in StreetComplete for about 2 years before finally getting around to opening an account (and uploading ~2000 quest-answers took an impressive while). Probably why I shot up the local rankings table, so quickly.

Armchair mapping is fine; provides plenty of easy pickings for me to survey. I suspect that it's a good thing that the few regulars each have different styles & interests, rather than (as it were) treading on each other's toes.

Actually, a question from a surveyor to an armchair mapper; what helps most in terms of feedback on needed corrections? E.g. free-form notes, using tags like fixme, or something else?
I suppose, also, what information would be most useful for actually being able to fix the kind of things best done on a micro-computer than a nano-computer?
Do photos (e.g. via StreetComplete) actually help, or is a clear (textual) description better?
So far, I've been mostly thoughtful-guessing.

Any other tips, suggestions, requests? I'm still quite the newbie (hence mostly sticking to tagging, so far, but learning). Unfortunately, despite marking some changesets as review_requested, not many people seem to do changeset reviewing (if only so I know I'm doing things right).

I actually didn't know; assumed it was German in origin (many noteworthy projects come from there).

+1 for the UK, then.

Makes a change. With it being Wimbledon season, again, I'm reminded that Brits are good at inventing sports that we lose at (tennis, badminton, football, rugby, sailing, golf (I think), cricket, probably more(!)).

Odd, then, that Yankland terms (sidewalk) and some spellings (kerb instead of curb) are common, instead of the British (dare I say English; origin of the language) versions.
Perhaps it was decided that the likes of pavement and curb were somewhat ambiguous. {Shrug}