I have to second Pernas; that's a large bounding box to change a couple elements. 2 separate changesets would've been better.

Smaller changeset areas, please.

Much smaller changeset areas, please.

Also, what makes for good osm.wiki/Good_changeset_comments 🙂.

Much smaller changeset areas, please.

Also; what makes for osm.wiki/Good_changeset_comments 🙂.

Ah, this quest is unlocked for Jersey, now? Good, seems that my request on Github didn't go unheard.

Smaller changeset areas, please.

STRIVE?

Re post box closure;

Might be better to set collection_times=Closed, actually.

Thanks for resolving the several which I had added; that was (mostly) from back when I was using only StreetComplete.

For node #1867154881 (post box #48) having researched the matter, it seems that

disused:amenity=post_box

is the consensus way of marking something which still exists but is no longer in service (and then, later, removed:*).

Since collection_times expects opening_hours syntax, I'd suggest simply “off”.

What makes for osm.wiki/Good_changeset_comments 🙂.

Since you also deleted Pierson Place (instead of simply modifying it), you could've at least imported the many relevant tags from the original.

Without area=yes the outline of Royal Square is treated as a path which runs the perimeter, rather than all the space within the boundary.

Compare Charing Cross: way/206640338
Or West Centre: way/175868058

Where one would want area=no would be for a path around a réservoir, since pedestrians can't cross the water on foot. Yet, they can walk anywhere within the square.

“crazy details”
Gosh, I'd forgotten about this one.

This was one of the cooperative places. A bunch of answers were apparent just from looking carefully, which helped, so I thought it more worthwhile to try 20 questions to go for completeness, while I was there anyway (and they had barely opened, still prepping, without any customers yet, so was perfect timing for the opportunity; that's sometimes why I only add a few things to others, because they're clearly busy selling and it's not a time when they'll be receptive to questions).

“the list of not-supported payment modes excessive (except maybe the more common ones like american express)”
Ah, yeah, I had to think back to why. Unless it was simply because I didn't tick those boxes in the UI widget, I think it may have been because they made clear that none but payment:apple_pay is accepted, so since I had the info it seemed better to mark them explicitly instead of leaving them remain ambiguous (as if undetermined).

Notice that when entire categories aren't accepted (like cryptocurrencies) I only set the generic key, rather than each individual sub-type. In this case, it was only because one (crApple) was accepted, but definitely no others, that I (probably) decided to do it that way.

One use case would be for tourists bringing foreign cards or whatever, since Jersey is still something of a tourist spot.

To my understanding tags aren't intended to be for (direct) human-reading. So, I was probably also thinking of machine-readability and the context of running some query to find places that accept one's favourite payment:*. American Express might be the convenient example; some places are all ‘oh, yes, of course, we accept everything’ while others are adamantly ‘no, AE charges too high fees, …’ while gladly accepting the likes of Visa & MC. So, for AE card-holders, the tag not being set would be ambiguous.
Another might be payment:delta which I've seen at a few places, but (so far) not many.

“I wouldn't add microbrewery=no”
I did debate myself over that one, especially for this type of establishment. A brewery (micro or otherwise) would obviously be far more of a pub type thing.

I'll probably not bother in future, unless there's a reasonable chance that they might actually have one.

“The detailed infos for wheelchair users are very useful. Great that you remember to look for this!”
Well, Vespucci & presets help a lot. Once I'm sure the thing is tagged to match the right preset, I then have it add keys (including optional ones), along with common sets like payment:*, and start going through them.

I avoided wheelchair* for a while, since I didn't feel qualified to make that determination. But, then realised that some info is better than none, and people on wheels aren't gonna go somewhere which could dmdwtp being a waste of time, nor are many gonna survey unknown places. There's just too much involved for them (I know some people who're affected one way or another, which is part of my motivation).

The one I do keep forgetting, is disability:* (or disabled:*, whichever it is). Or I only remember after submitting & closing the changeset.
Obvious ones would be the blind and/or deaf, which have a bunch of different difficulties. Others are not obvious but just as life-altering.

I'm a fan of buyers making the most of their market influence, as a means to persuade sellers to adapt in order to remain in the market. So, in this context, if those on wheels know that one place is more accessible than another, and more / enough decide to favour that place either for convenience or principle, then less accessible competitors will soon have strong incentive to adapt in order to survive.
Thus, by giving the wheel-enhanced the info to make such decisions, I'm helping that process.
If not, and it's ignored, then no harm done.

Correction:

“would it be better to add ways (using the same nodes as the building outline, for now) spanning the area”
Meant to include: with each having an explicit level=[N] set.

👍

I am curious about interior mapping. But, one step at a time.

Since the main retailers (i.e. excluding the cafe) cover the entirety of their respective floor, would it be better to add ways (using the same nodes as the building outline, for now) spanning the area, rather than merely a single-node PoI?

I might as well (and would prefer to) learn how things should be done properly, in order to know when I'm compromising. Must learn the rules before ignoring them.

I suppose so.

Perhaps I've become a bit overzealous since discovering some things tagged with addr:country as GB or UK.

I take it that, instead of explicit tagging, context (country, city, district, etc.) is derived from relative positions (like when running a query, it knows which elements enclose the location).

If so, then when are addr tags sensible? Published portal addresses, rather than geographical ones?

Thanks. These aren't the only places, but need to actually survey the others.

Even these ones need further refinement based on where the actual road-signs are. Some are only hazardous for certain directions.

“Osmand may actually give a warning”
It seems to have that capability, but not had chance to test it. It certainly can't warn about that which isn't mapped.

Besides, I was thinking more of helping routing algorithms know that maybe it should be avoided and a less-efficient but safer route be determined.

Though, between data & algorithms, I imagine it's a classic chicken & egg problem. So, one's gotta come first (and I can tag the junction more easily than implement hazard-avoidance in the libre algorithms).

It's these sorts of fine details which I feel will be part of what makes OSM the superior map.
Just as surface & smoothness will inform routing for the likes of wheelchairs, scooters, skates, racing bikes, and whatever else (it's well past 2015, I want my hoverboard Doc Brown!).

“If possible”
I'm not yet familiar with barrier types, and the type or intent of the carrier wasn't clear (and it was dark & cold (late evening) by that point, too).

I thought it best to mark its existence anyway, since refinement being needed would be obvious, and I knew that it would either show up in SC as a quest (which it did) and/or would be marked as problematic (possibly even invalid) by QA.
Seemed better than leaving a note, since I could at least get the geometry right while stood there briefly.

“You could map who / what can still pass the barrier with access tags like "foot/bicycle=yes".”
That's good to know.

The rules for the parks (probably because they're small) are somewhat non-trivial, especially for cyclists. According to signage, cycling across the centre is fine (which seems to be part of a cycle-route, now), but elsewhere must dismount.
Definitely foot=yes, though.

Millennium Park has been on my hit-list for a while, so eventually I'll do an extensive survey. Much needs to be fixed & added.

My concern at the time was adding the long-missing access path (e.g. for routing purposes), since I happened to be there anyway.

Under better (surveying) conditions I would've been more through (including reading the wiki, and finding a park keeper to question).

Perhaps I shouldn't have tagged this changeset as review_requested since it's more a case of ‘this needs further attention’.

Ah (face-palm moment), I didn't even think of routing.

Quite right.