What makes for osm.wiki/Good_changeset_comments 🙂.

Re node #8815664209 (hence one reason why separate changesets are useful):

The key opening_hours:covid19 takes as value the same (machine-readable) syntax as opening_hours (see opening_hours=* ).
If there's no difference from what's normal, then *:covid19 is redundant.

payment:coins is implied by payment:cash (see payment:cash=* ). Only where payment:coins and payment:notes are different (think of telephone boxes) is it necessary to distinguish. For retailers, if they accept one (coins or notes) then they inevitably accept the other too.

phone (and other similar contact:* keys) take a standardised format as value. See phone=*
Though, this fix is simple; just add some spaces: +44 1534 610934

Your changeset didn't specify a source (see source=* ), so I must wonder where payment:* and addr:* came from?

I'd also suggest scoping your changes, so that the bounding box doesn't end up covering large areas with no relevant changes.

What makes for osm.wiki/Good_changeset_comments 🙂.

What makes for osm.wiki/Good_changeset_comments 🙂.

Also: what makes for osm.wiki/Good_changeset_comments 🙂

Also: what makes for osm.wiki/Good_changeset_comments

It sounds like you gathered this info from a survey (which is great). If so, please tag such changesets with source=survey .

Note; when the source is not an actual survey, there are other values to use instead. See: source=*#How_to_use_on_changesets

It sounds like you gathered this info from a survey (which is great). If so, please tag such changesets with source=survey .

Note; when the source is not an actual survey, there are other values to use instead. See: source=*#How_to_use_on_changesets

“was:”
First saw this, yesterday. Seems like a good idea. I can think of a few places where it would make great sense; something was there for a long time for which the place became known, but has been recently replaced or changed.

“old_name”
As opposed to was:name ?

I thought old_name was for when the same place is renamed (e.g. a retailer rebrands, or the historic name of a road (since it's still the same physical road).

Is this another ‘how data users will interpret’ case?

“if someone still remembers the name and searches for it”
Very likely; it's a well-known (and long-established) name / brand.

I would wish to preserve it anyway, just for completeness, easy-finding, and because a couple extra tags are hardly gonna bloat the DB much. I suppose it would help out the OSM History project, too.

Seems that the presets (Vespucci uses those from JOSM) could do with being updated. Not all optional keys are included.
Can presets automate the adding of prefixes (like was:*) for when the PoI fundamentally changes?

“we want to make sure data consumers understand the tagging (at least roughly)”
This is a good point. Though, one hardly ‘consumes’ data; it still exists after use. In fact, more copies exist by using it. The term is a very narrow economic one.
http://www.gnu.org/philosophy/words-to-avoid.html#Consumer
http://www.gnu.org/philosophy/words-to-avoid.html#Consume

Data user, data parser(, data processor?), are more generic & not loaded.

However, it's a double-edged sword. I speak from experience of other contexts (I'll just mention (X)HTML {shudders}).

The risk is one of (basically) tagging according to (current) implementations (all of which will be non-identical, with their own quirks), rather than to soundly designed schemes (and expecting software implementers (implementors?) to keep up). Especially if one is concerned about the long-term, and quality & utility (without the pain of forever preserving backward compatibility). Eventually, innovation stagnates with a chicken-and-egg (who'll be the first-mover) problem.

I imagine that the design decision to use textual tagging was to permit unforeseen / unanticipated scenarios.

Like you say, “Conveying all details as precisely as possible is always a bit tricky”.

“This makes it likely for software to understand it based on a generic scheme.”
In terms of full comprehension; yes. That's also true for any newly-approved proposal, though.

However, it needn't be completely ignorant, either.
Off the top of my head, as a type this, an implementation could treat any significant key (shop, amenity, craft, etc.) which has a(ny) prefix (*:(shop|…osm.wiki/Key:)) differently to unprefixed “shop=whatever”. Such as, simply (until it has the logic by which to handle each specific case) that the prefix is some kind of modifier, and that it's something other than a running shop. I can imagine using some RegEx for pattern-matching the notation, too.

Whereas, special values (shop=disused) require keyword-matching to avoid a very literal handling.

In fact, this is one of the reasons given for avoiding the likes of shop=vacant, and preferring a prefix.

Prefixes are a generic scheme (which enable & allow for new uses, just as I did).

“An undocumented prefix”
Except that it's not undocumented, only uncommon (but then so are survey reference points). Defacto schemes (by definition) all started out undocumented; the data was the documentation, from which a human-readable form was derived.

“to make any sense out of it”
Having seen such rationale elsewhere, one of the reasons for textual tagging is likely that any which are unfamiliar to a parser (optional or new ones) can be ignored while still being able to read the remaining data.

“human reader has an intuitive understanding”
While I agree with your meaning, having studied usability a fair amount, the term is risky (especially when one means something else). So, interpretative understanding, perhaps?

For context; in usability, intuitive!=usable. Intuition differs across cultures.

“software has not.”
Commonly, yes. However, it can be given the ability to make not-unreasonable decisions. That's down to the care of the developers, though.

The other side of that coin (or sword, to use the earlier metaphor) is that lack of distinction between semantically-different cases prevents diligent implementations from doing clever or innovative things.

I recall (for a different changeset, yesterday) that this is why diet:* came into existence; to avoid several cases of ambiguity when (previously) using cuisine=* for both (e.g. which of the following does cuisine=indian;vegetarian mean; vegetarian-only Indian dishes (Indian AND vegetarian), or (Indian OR (non-Indian-)vegetarian), or Indian dishes which can be made vegetarian-compliant (Indian OR (vegetarian AND Indian)) (or something else I can't think of 🙂)?)

However, perhaps this is why the proposal mechanism came to be. Maybe I'm simply retreading old (and well-discussed) ground.

Your point about using editing software, though; since that definitely affects me, it would certainly be simpler to use presets (which would tag as disused:*) rather than entirely manually (especially as you already caught one goof I made (with internet:access); I can only imagine it being because by that point (after a day of surveying) I was tired, cold, or both).

Separately;

“Btw, there was never a tag on this POI saying it was a retailer - it was only tagged as a workshop. A pottery shop should be tagged shop = pottery.”

I wondered about this.
This is another way in which the wiki is either unclear or misleading.

From what I read, it suggests that all instances for which an applicable craft:* is available, it should be used.

However, selling!=making. Furniture & food come to mind.

In this instance, for this location, it's only retail, not manufacture (the latter happens elsewhere; at least I think Jersey Pottery still make the wares they sell).

I guess whoever marked it as craft simply followed what was common, rather than correct. 😋

I suspect that one of the problems, for this region, is that there are few local contributors (and even fewer who contribute regularly, and then only a couple who do (recent) surveying).
Many real-world PoIs are simply not mapped at all, else it's the bare minimum (perhaps just the type of place, but without even the name tagged).

This is why, for now, I stick to (mostly) tagging. I'm unsure of the correct procedure for adding a new PoI to an existing area, let alone spitting ways or adding new features. Documentation is lacking, I find, especially for newbies who care about quality (getting it right the first time).

I appreciate the tip.

Then the wiki is misleading, especially for newbies. Though it's not the first instance of inconsistency I've found. Another is craft=pottery versus shop=pottery, but I'll address that one separately.
Might I suggest that an experienced contributor, such as yourself, correct the misleading info in the wiki.

My thinking was around (semantic) correctness (while avoiding ambiguity), rather than doing (sheep-like) whatever's popular. I recall reading the documentation advocating for correctness in data, rather than working around renderer glitches and the like (I would imagine that what editors recognise would be included). I notice that a number of proposals relating to tagging schema, which have since been adopted, were lodged in order to escape & avoid problems of ambiguity.

I also have to wonder how any new proposal comes into effect (or simply defacto usage), if only already-popular tags are acceptable. Nevermind ad-hoc pre-proposal improvisation for unforeseen scenarios (shop=virtual perhaps?).

Thus, this is an argument-from-popularity fallacy.

Disused:* doesn't convey what I observed during survey. Vacant:* does.
I read the wiki article you cited, and others (as I said; before making my change), and based on what they said it seemed that the intended use-case for disused:* would be something like a decommissioned phone or post-box. Though, yes, it's easy to allow scope-creep.
Compare a house which is currently unoccupied. It remains a house, it hasn't been marked for demolition or repurposing (i.e. a use other than residential). It's simply vacant, but likely to be occupied once more.

Same with the PoI here; it's still a retail space, it's not being converted for another use (i.e. disused as retail space), but simply between occupiers. Though, appears that it's awaiting another to move in.

There's no construction work, to alter it, either. Nor is any planned (else a notice would be posted, as legislation / regulation requires).
Nor is it boarded-up or such.

Unless you noticed something which I missed, during your survey?

“shop = vacant and vacant = yes”
The wiki specifically said to avoid this (and gave reasons), just like with shop=disused, and even if it hadn't recommended vacant;* instead, that would be logical considering the other prefixes, and there appearing to be a consensus of preferring to add prefixes rather than replacing either key or value.

“"vacant:shop" is used 60 times world-wide (likely due to the one line in the Wiki you found on the "shop" page).”
From http://taginfo.openstreetmap.org/keys/vacant%3Ashop I presume?

While http://taginfo.openstreetmap.org/keys/disused:craft occurs only 264 times globally. Also ‘unpopular’ (hardly common).

Meanwhile, http://taginfo.openstreetmap.org/keys/vacant occurs 3134 times. This is comparable to some of the lifecycle prefixes regarded as common (such as ruins:*).

I could also cite http://taginfo.openstreetmap.org/reports/frequently_used_keys_without_wiki_page

“There are no other use cases of "vacant:*" with other tags to be found.”
Yet, http://taginfo.openstreetmap.org/search?q=vacant%3A clearly shows that there are.
Unless you meant prescribed or intended cases described by the wiki?

See osm.wiki/Shops
---

Published using OSMCha: https://osmcha.org/changesets/105880162

Why?

I read the wiki, before making this change, which makes clear that vacant:* is not only perfectly valid, but preferable to disused;* since it'll likely remain a retailer of some sort, even if it's merely changing hands or otherwise between occupants.

Disused:* implies that it'll no longer be a retailer, which isn't the case.

D'oh, dunno how I managed to bungle that one. Thanks for spotting & correcting. Will be more careful in future.

Care to explain what was done, here? It's not clear from the set's data.
---

Published using OSMCha: https://osmcha.org/changesets/105612607

I have to second Jakka's remarks.

What makes for osm.wiki/Good_changeset_comments 🙂.

It would also be better to separate your clusters of changes into several separate changesets.

Re note #2687882

What makes for osm.wiki/Good_changeset_comments 🙂.

Thanks, but it was only the north-west corner which needed an extra node to blunt the point.

Since removing nodes is easier than adding, I'll have a go at tweaking this, next time I'm passing.