when adding disused: SC deletes tags

[JLZIMMERMANN]

How to Reproduce
SC let edit POI about vacancy shop=vacant office=vacant disused:shop=yes
Unfortunatly in my professional experiment in localities it is better to use shop=vacant and office=vacant than disused:shop=yes.
This case disused:* means than the shop is not used but not implying vacancy.

StreetComplete application seems to erase all other tags. Unfortunatly I need these because I keep was:shop and was:name=* to help prospect to see what kind of retail would have been used before.

Example here : https://www.openstreetmap.org/node/302852529/history

Expected Behavior
If a shop becomes vacant, it would be welcome to change tags putting was:prefix before name and shop or office tags.
If there is already such prefix it could simply adding tags with the one already existing.

Versions affected
Android : 10QKQ1 StreetComplete 51

[matkoniecz]

This case disused:* means than the shop is not used but not implying vacancy.

in which case shop is disused and not vacant?

erase all other tags

not all

see https://github.com/streetcomplete/StreetComplete/blob/master/CONTRIBUTING.md#created-for-streetcomplete or more specifically https://github.com/mnalis/StreetComplete-taginfo-categorize

lets take cuisine or name - and these tags are intentionally being removed, see https://github.com/mnalis/StreetComplete-taginfo-categorize/blob/master/sc_to_remove.txt

Unfortunatly I need these because I keep was:shop and was:name=* to help prospect to see what kind of retail would have been used before.

you can still see object history, OSM stores what is currently in the world

[matkoniecz]

to help prospect to see what kind of retail would have been used before.

Can you clarify what you mean here? Are you using OSM data to map/check/visualise properties of no longer existing objects?

[westnordost]

I keep was:shop and was:name=* to help prospect to see what kind of retail would have been used before.

To be honest, I do not think the was:* lifecycle prefix is made for this use case. Hence, not retaining data that is not there anymore is not to be counted as a bug. If you need historic information (on shops), better dig through the history of such POIs or record such data separately from OpenStreetMap.
In OpenStreetMap, you will never find a guarantee that data on things that are not there any more will not be deleted.

[westnordost]

in which case shop is disused and not vacant?

When a shop closed "until further notice". Around the corner, I know such a shop. The shop is still there, but it hasn't been open for the last months and noone knows it will ever open again. To be honest, currently I simply do not re-tag this shop as being vacant (because it is not) and hold off on updating the opening hours (because I don't know how to tag "this is closed, always").

[JLZIMMERMANN]

Are you using OSM data to map/check/visualise properties of no longer existing objects?

Indeed, I push old names of shop like others may push old names of streets.
Why ? Because for elder people such way of mapping is helpfull when they say I remermber the shop named "Mamouth" in this town. The data cannot be found in the history of the OSM object it's added afterward by investigations.

[JLZIMMERMANN]

you will never find a guarantee that data on things that are not there any more will not be deleted

This explaination could be used for anykind of contribution.
In my case I wish to give more quality in my professional uses for localities in economical development and especialy to help prospect to find a good place to create their business using OpenStreetMap.

[JLZIMMERMANN]

cuisine or name - and these tags are intentionally being removed
https://www.openstreetmap.org/node/1384324676
You may see in this example that many tags are usefull :

[matkoniecz]

Why ? Because for elder people such way of mapping is helpfull when they say I remermber the shop named "Mamouth" in this town. The data cannot be found in the history of the OSM object it's added afterward by investigations.

This information cannot be assumed to be mappable and verifiable. In fact, shops so notable to be remembered after their disappearance are really rare.

It can be mapped with say place=locality in rare cases where defunct and gone shop is still used as an orientation point, but vast majority of shops do not fall in this category and it is safe to assume that say cuisine of no longer existing shop can be removed.

Are you using OSM data to map/check/visualise properties of no longer existing objects?

Indeed, I push old names of shop like others may push old names of streets.
Why ? Because for elder people such way of mapping is helpfull when they say I remermber the shop named "Mamouth" in this town. The data cannot be found in the history of the OSM object it's added afterward by investigations.

Note that keeping fully gone and no longer verifiable things like cuisine of past shops should be not mapped in OSM.

Names of streets are in general remembered for long time, this is very unusual for shop names.

If you want to map history - then OHM may be of interest, though I am not sure are they having notability requirements and is it OK to map say shops there.

[JLZIMMERMANN]

Why ? Because for elder people such way of mapping is helpfull when they say I remember the shop named "Mamouth" in this town. The data cannot be found in the history of the OSM object it's added afterward by investigations.

This information cannot be assumed to be mappable and verifiable.

Saying such thing would mean that we may not push any ref:= because thare are a lot that are experts datas. I think when something is needed it's good to let it grow. My contributions are to let find the previous occupation. This information is very welcome for prospects and professionnals.

[matkoniecz]

let find the previous occupation

OSM is for mapping currently existing features

It is fine to map ref* of currently existing features

[JLZIMMERMANN]

let find the previous occupation

OSM is for mapping currently existing features

When a church becomes a cultural building, the building changes. It becomes a new amenity=theatre and was:amenity=place_of_worship ...

[JLZIMMERMANN]

This prefix was:= is growing and worldwid used.

[matkoniecz]

When a church becomes a cultural building, the building changes.

We record in building=church tag that it has architectonic form of church building (say, church building housing now bookstore/apartments/skatepark).

This prefix was:= is growing and worldwid used.

This is not making using it mandatory, and using rather disused:shop is also fine. was:shop is worse as it suggests that mapping fully gone shops that left no traces is fine.

[mnalis]

I do agree that sometimes old name is useful, especially if old sign still remains displayed, but in some other cases too (see my argument at #3045 (comment) for details) - whether as old_name, disused:name or was:name...

However, it seems the consensus was not to keep it, and I get it. If you care about history of the object, there is API history call that retrieves it, so that at least will work relatively simply with StreetComplete removal method.

But note that as often as not, people will just delete old POI (and same or other people later create new POI), so all history and relationship will be lost, and you'd be forced to use much cruder and slower methods like Overpass Attic data to try to find what was there before if you really care about it.

Why ? Because for elder people such way of mapping is helpfull when they say I remermber the shop named "Mamouth" in this town. The data cannot be found in the history of the OSM object it's added afterward by investigations.

That particular use case is however not related to this SC issue (StreetComplete deletion of the existing tags does not matter if the tag never existed in the first place - in that case, you can always add was:name or whatever in your favourite editor which allows adding custom tags [which SC is obviously not - although SCEE fork does allow that]).

[mnalis]

When a shop closed "until further notice". Around the corner, I know such a shop. The shop is still there, but it hasn't been open for the last months and noone knows it will ever open again. To be honest, currently I simply do not re-tag this shop as being vacant (because it is not) and hold off on updating the opening hours (because I don't know how to tag "this is closed, always").

BTW, the tagging for that is opening_hours=off in simplest case. (check in the the evaluation tool). Although you can of course use opening_hours=Mo-Su off or even opening_hours=Mo-Su 00:00-24:00 off if you're feeling like it, but it's just wasting space...

[JLZIMMERMANN]

However, it seems the consensus was not to keep it, and I get it.

It is not a consensus. If you look in taginfo more and more objects have an historical information when some significal changes have occured.

[matkoniecz]

was:shop that you linked can be validly used for cases where - for some reason - risk of accidental remapping is high or where visible remains of shop are still present, so its usage is not any strong indicator of your claims

in case where shop is gone and not operating, deleting shop entirely is a valid method of handling it

mapping historical information (say, mapping was:shop where no trace of former shop remains and accidental remapping as an active shop is not very likely) remains invalid and such objects should be deleted

and yes, there is way too high invalidly mapped historic objects - which in no way indicates any consensus as these objects are eliminated and deleted once revealed to be gone without any traces

[mnalis]

However, it seems the consensus was not to keep it, and I get it.
It is not a consensus.

I meant StreetComplete consensus in that thread.

Anyway, to cite was:* wiki documentation (without complaints on its talk page so far):

The was: lifecycle prefix can be added to tags that relate to features that don't exist but have an high probability to be re-added by a non surveyed edit, as they were present there before (so can for example still be seen on commonly used imagery or import sources. In most cases, in OSM, if you find a object in the database that don't exist on the ground, whether it existed or not, is an error or not, you should just delete it. But in some rare circumstances, when those features still appear in outdated sources still used to enter data in osm (old imagery, import sources, etc.) you can use this tag to warn other mappers not to re-add those features.
Adding a note=* to explain why you just didn't delete the geometry is highly recommended, else, someone might just delete everything again.

So, no, was: should not be used to keep historic data unless there is high probability that someone will re-introduce stale data. Otherwise, it should be removed in majority of the cases.

If you look in taginfo more and more objects have an historical information when some significal changes have occured.

I am looking at taginfo. Here is even taghistory for more perspective how insignificant was: usage increase is in comparison (if it were relevant, one would expect that was:shop would be growing almost at the same rate as shop - as one shop closes and new one gets in its place). That is clearly not happening, however.

I've linked above why I think OpenStreetMap is not historic database, but a database representing current state of the world. If you need the historic editing data, I think you should learn how to pull that data yourself.

Anyway @JLZIMMERMANN, if you disagree with that statement, and think that all historic data should be always available in main OSM database (because it is useful for your use cases), you should argue for that direction at Tagging mailing list or OSM community forum to change to rules.

There is not much point on complaining on this StreetComplete bug tracker - as it is not a bug in StreetComplete app, and there is nothing StreetComplete can really do (as intentionally going against documented tagging procedures and against community consensus in not really an option - for hopefully obvious reasons).

[JLZIMMERMANN]

There is not much point on complaining on this StreetComplete bug tracker - as it is not a bug in StreetComplete app, and there is nothing StreetComplete can really do (as intentionally going against documented tagging procedures and against community consensus in not really an option - for hopefully obvious reasons).

There is a big problem : tags that are erased !
This point is not fair. When contributors spend time to improve quality, SC should at least let such quality remain.

[matkoniecz]

This tag removal was OK edit, when editing manually I would do the same edit.

Removing info about no longer existing features is normal.

For example removing cuisine info, opening hours info and name of no longer existing shop is a normal edit in OSM.

[mnalis]

There is a big problem : tags that are erased !

Well, the user has chosen option named "It does not exist". Perhaps some translation is bad?

To me, after choosing that something does not exist, it sounds perfectly clear and reasonable and expected that this will result in non-existent feature being deleted. In fact, I would be quite annoyed if I selected I want to delete something which does not exist anymore, and it did not get deleted.

This point is not fair. When contributors spend time to improve quality, SC should at least let such quality remain.

I'm puzzled about what "lost quality" are we talking about, can you be more precise, or give better example than one at the top of this issue?

To me it sounds perfectly reasonable that if restaurant does not exist anymore, that its cuisine does not exist anymore either (nor do its payment methods etc.). Surely, retaining obsolete data in current state database would not be an example of "letting quality remain"? Or am I misunderstanding?

Other tags on that node which are likely to remain current (like addr:housenumber etc.) are preserved in current state OSM database. (if you find some tags are not correctly detected, please report the bug at https://github.com/mnalis/StreetComplete-taginfo-categorize/issues with example which tag still remains current after amenity is vacated)

But obsolete historical (non-current) data (like cuisine of vacated restaurant) is not deleted either. Instead, it is moved to correct place (from current state database to historical database - which you can query in your example by visiting https://www.openstreetmap.org/node/302852529/history or pressing ctrl-H in JOSM or ctrl-shift-H in iD etc).

[JLZIMMERMANN]

To me, after choosing that something does not exist, it sounds perfectly clear and reasonable and expected that this will result in non-existent feature being deleted. In fact, I would be quite annoyed if I selected I want to delete something which does not exist anymore, and it did not get deleted.

It would be better to change the previous tags with disused: prefix.
I prefer was: because semantically this word is more explicit and using the letter 'w' let these tags go at the end of all the tags : more readable.

[JLZIMMERMANN]

Instead, it is moved to correct place (from current state database to historical database

Sometimes such objects do not have previous tags. In my area un south of France, students are mapping vacancy in several cities, they may add at the same time shop=vacan was: shop=* was:name=* to help municipalities to manage and get a dashboard.

[matkoniecz]

Iff there are traces of such shop, then adding this is fine.

Note that StreetComplete will not remove tags for such objects, as long as it is in derelict state. Only if new shop open in its place then such tags may be removed as result of StreetComplete activity (not checked are they removed reliably).

---

I will also unwatch this issue: if community consensus changes or there is something truly new - and not discussed already - then it would make sense to make a new issue.

Please do not make a new issue if things were discussed here, even if you disagree with WONTFIXing this.

[flacombe]

Hi

I bring a few points here as I don't understand the views against was:* keys, particularly about shops.

you can still see object history, OSM stores what is currently in the world

It's not recommended to do so: OSM version aren't reliable to distinguish an actual past usage and a mistake.
You can't get the status of a given place at a given date depending on versions designed to revert changes.

This information cannot be assumed to be mappable and verifiable.

Risk of accidental remapping is high or where visible remains of shop are still present, so its usage is not any strong indicator of your claims

Discussion on this particular changeset shows that even unexpected information can show up and confuse mappers.
https://www.openstreetmap.org/changeset/129618831
It should have raised a warning if the editor had enough logic to prevent mixing disused:power and power. Same for was:* or any other lifecycle step.

We use many data sources, even outdated ones without having this in mind. Finding data that could trigger warnings and hints about possible mistake is better than nothing.
It's not unusual to rely on only outdated Mapillary imagery or aerial views and add to the map disappeared things. Not simply erasing past status but organize it to help next person who will handle features is actual team work.

[mnalis]

I bring a few points here as I don't understand the views against was:* keys, particularly about shops.

Did you read was:* wiki page? Especially part that says "In most cases, in OSM, if you find a object in the database that don't exist on the ground, whether it existed or not, is an error or not, you should just delete it" ?

you can still see object history, OSM stores what is currently in the world
It's not recommended to do so:

umm, "it is not recommended to do what"? Check OSM object history?

OSM version aren't reliable to distinguish an actual past usage and a mistake.

Well, yeah, no OSM tag (or other feature) is going to protect you against people making mistakes.

You can't get the status of a given place at a given date depending on versions designed to revert changes.

no? Ctrl+h in JOSM seems to work just fine to give me a status of a given object at at given date. Can you give an example where it doesn't work for you? As I don't seem to understand where it fails for you?

Discussion on this particular changeset shows that even unexpected information can show up and confuse mappers.
https://www.openstreetmap.org/changeset/129618831
It should have raised a warning if the editor had enough logic to prevent mixing disused:power and power. Same for was:* or any other lifecycle step.

I agree with you that iD can improve its checks. But this StreetComplete issue tracker is totally wrong place to request that. iD issue tracker is here for you to report that feature request.

We use many data sources, even outdated ones without having this in mind. Finding data that could trigger warnings and hints about possible mistake is better than nothing.

Are we still talking about StreetComplete here? If so, what exact quests would you suggest that would check for such warnings, and that need on-site survey?

It's not unusual to rely on only outdated Mapillary imagery or aerial views and add to the map disappeared things.

It is not unusual for people to make mistakes, yes. If the Mapillary imagery is older than last change date of the objects, then people should obviously should not be using data from it in order to destroy correct newer information with obsolete one. But it is on people using Mapillary (and other imagery) to check. No amount of history or tags will help if they do not bother to check. Perhaps it could be made more clear to Mapillary users in some documentation? Probably best to suggest it there.

Not simply erasing past status but organize it to help next person who will handle features is actual team work.

They are not erased; they are moved to history (because that is historic i.e. "not current" information!). And that history one can easily access on osm.org site (click View History when looking at an object), in JOSM (press ctrl+h), in iD (ctrl+shift+H), etc. It also provides much more information - as data might have changed dozen times in the past (and not just once), and you can see all of it in history database, along with metadata who changed what, where, when and why. Is that not enough information? Or what is lacking?

[flacombe]

Well, was:* wiki page states that it can be used to disambiguate situations where data source is outdated and prevent mappers to restore past state of features (precisely what I'm arguing for upside).

Whatever @JLZIMMERMANN is doing with was:* is not the business of this StreetComplete quest.
Removing was:* keys disable any further warning to someone intending to restore the past state of shops, even inadvertently. Period.

Well, yeah, no OSM tag (or other feature) is going to protect you against people making mistakes.

Get me well: I'm not expecting OSM versions to protect me from mistakes. My point is you can't distinguish mistakes from real ground changes.
"This restaurant changed from French to Italian cuisine last year. Was it a mistake correction or a real change? Now I see it as scandivanian on the menu." => OSM History won't tell me if the French restaurant had ever existed in real world.
@JLZIMMERMANN use case with was:* interpretation is an another story.

Ctrl+h in JOSM seems to work just fine to give me a status of a given object at at given date.

You'll certainly get how the object was described in OSM, not how it was in real world.
It's a slight difference no one should be confused with.

By the way, mentioning iD and Mapillary there was only for illustration.
It wasn't a formal request about these two.

and you can see all of it in history database, along with metadata who changed what, where, when and why. Is that not enough information? Or what is lacking?

We miss automated checks. The user has to think about looking in the history. Editors won't send him a warning because he is intended to restore past state of a given object, that's why we put was:* keys on.
Changeset comment (took as reason for change) is free text and can be off topic in regard of the precise feature we are investigating. That's one of why an OSM version won't never ever be a hint on what was a given feature in the real world before.

[mnalis]

Get me well: I'm not expecting OSM versions to protect me from mistakes. My point is you can't distinguish mistakes from real ground changes.

Absolutely -- that is truism. Nothing in OSM can be guaranteed to represent real state on the ground. Ever.
I don't see how us agreeing on that helps with anything, though.

"This restaurant changed from French to Italian cuisine last year. Was it a mistake correction or a real change? Now I see it as scandivanian on the menu." => OSM History won't tell me if the French restaurant had ever existed in real world.

True, but nothing would tell you that if the French restaurant had ever existed in the real world. Even if you put note=This restaurant really exists!!! it might still be a mistake, or tagged on a wrong object, or incorrect for any number of other reasons, and not representing real situation on the ground.

Also, even if SC were to automatically rename old cuisine to was:cuisine when user indicated that amenity changed, that would be no guarantee that previous state of cuisine was correct. New mapper have no idea what it really was before, only what it is (or at least what it claims it is, which could be wrong too) at the moment they answered the SC quest. So it could've been an mistake -- was:cuisine would help you no more than history cuisine version would (in fact, without additional manually crafted note=*, it would likely tell you much less, as it misses changeset comments, and all previous history changes)

We miss automated checks

Where do you miss them? In StreetComplete or elsewhere (in some other editors? in QA tools?)

And if you miss automated checks in StreetComplete, how exactly do you envision that checks should work? Please describe an example and workflow what SC should check for, and what it should do it check indicates something is wrong?

I.e. if you are suggesting a change in StreetComplete (as opposed to just expressing your general unhappiness about current state of software and OSM map data model generally), what actionable change exactly do you propose for SC, and what problems exactly do you think such solution will fix?

[flacombe]

I think StreetComplete shouldn't remove keys when it can't be always sure this removal will be relevant, particularly about was:* keys.

Whatever the real usage can be, it should be discussed in every community concerned.
This discussion had gone far beyond it should had actually. The point is to not remove keys unilaterally.

[mnalis]

I think StreetComplete shouldn't remove keys when it can't be always sure this removal will be relevant,

I agree, that is why it is only removing no-longer relevant keys. In fact, a lot of effort (see https://github.com/mnalis/StreetComplete-taginfo-categorize) has been invested to make sure SC only removes keys which are no longer relevant when shop is gone, and that it retains all still-relevant tags. Feel free to open an issue there is you have actionable suggestion what keys are still existing even after to shop is removed and thus should stay (like addr:housenumber for example.)

particularly about was:* keys.

was:* keys will always be irrelevant at this point. At best, when removing restaurant, was:cuisine should always be removed, and latest cuisine should be renamed to was:cuisine (as that is what is was previously. What it was prior to previous value is only visible in history database.)

Or do you propose prefix chaining, to preserve even older values that were there before previous value, like was:was:* ? So if it first was a convenience store, then French restaurant, then Italian restaurant, then Croatian restaurant, then (currently!) shoe store, do you want that node to be tagged with:

shop=shoes
was:amenity=restaurant
was:cuisine=croatian
was:was:amenity=restaurant
was:was:cuisine=italian
was:was:was:amenity=restaurant
was:was:was:cuisine=french
was:was:was:was:shop=convenience
was:was:was:was:opening_hours=24/7

that would be re-implementing history database in completely wasteful, unreadable and horrible way. And if you're not proposing that and only want last thing it was before it become shoe store thing to be remembered, then two-steps-removed historical was:cuisine=italian must be deleted (as well as three-steps-removed French, four-steps-removed convenience store etc.), do you agree?

Whatever the real usage can be, it should be discussed in every community concerned.

It was discussed and documented at was:* wiki page:

in OSM, if you find a object in the database that don't exist on the ground, whether it existed or not, is an error or not, you should just delete it

If you want OSM to do/be something else, you should propose that to wider OSM community, not to StreetComplete.

This discussion had gone far beyond it should had actually.

Absolutely agree, that is why most people have unsubscribed from this issue by now. I've stayed a little longer (until now) to try to explain why it was rightfully rejected, as some people seem to not have understood and missed key points, and I wanted to help them understand.

The point is to not remove keys unilaterally

As noted in wiki linked above and elsewhere, features that do not exist on the ground should be totally removed from the OSM main map. If you disagree with that OSM basic tenet that "OpenStreetMap represents physical features on the ground", and think it should include whole history of the world instead, I've linked above where and how you can propose it to be changed. I should warn you that you're likely to meet some resistance to that idea, though. Or, one should probably use OpenHistoricalMap instead if that is what they want.

[JLZIMMERMANN]

Or do you propose prefix chaining, to preserve even older values that were there before previous value, like was:was:* ? So if it first was a convenience store, then French restaurant, then Italian restaurant, then Croatian restaurant, then (currently!) shoe store, do you want that node to be tagged with:

There is a simplest way use ";" to separate here you have an example

[mnalis]

There is a simplest way use ";" to separate here you have an example

No, that is simply wrong. ; is used to separate, yes.

But was:cuisine=italian;croatian;greek would mean that the previous restaurant was offering those three (i.e. that just before last change it was cuisine=italian;croatian;greek). And not that any number of previous restaurants, fast_foods, food courts etc. was each offering some of those.

Also, this example is good only to show how was: is not to be used.

• *name* uses ; to separate parts of the name, for example in multi-lingual countries. Not to merge multiple random old names into some Frankenstein's monster constructed from various parts of different objects.
• if there was a pressing need to record multiple old names for important historical purposes (and there isn't here!), one should've used https://wiki.openstreetmap.org/wiki/Names#Historical_names. E.g. name:1990--1996=Bidules + name:1996--2022=Nolita. Or better yet, use wikidata=*
• was:* wiki clearly states that it should be used only if there is "high probability to be re-added by a non surveyed edit". Was there really such high probability that someone would re-add shop=fashion_accessories from non-survey, and if there was, from which sources exactly was such danger?
• When that danger has passed, was:* was supposed to be deleted.
• was:* wiki clearly states that it should only be used "in some rare circumstances, when those features still appear in outdated sources still used to enter data in osm". What are those rare circumstances in this example? And if you're doing it on many/most edits, then those clearly are not "rare circumstances", and you're abusing this prefix. Please don't do that.
• was:* wiki clearly states that if there is a need to use it, that you should use note=* to document why. That critical part is missing. Why? Please do add missing note=* explaining the circumstances (or remove those unneeded was:* keys).
• was:* wiki clearly states that "In most cases, in OSM, if you find a object in the database that don't exist on the ground, whether it existed or not, is an error or not, you should just delete it.". Do you delete old & obsolete/historical tags in "most cases", and if not, why?
• this specific example usage breaks history horribly - before it become fast food, was it "estate agent" or "fashion accessories"? No way to tell for those was:* tags.
• was:office / was:shop -- one of them them is wrong and must be deleted, as was: prefix is intended only to represent last thing it was before it become current one, in order so someone would not re-add it from non-current imagery later. e.g. use it as completion of sentence "just before it become fast foot; it was xxx" - that xxx can be either estate_agent or fashion_accessories; not both. As soon as that imagery/import source becomes current, all those was:* are supposed to be removed.
• also, what if there were many changes? tag value length is limited to 255 characters, so you would run out of space after dozen (or few) changes, so this idea of recording whole history of object in was:* tags will break anyway.
• BTW you left accessories=* which is no longer relevant. It should've been removed (or at least become was:accessories=* if you had your way)
• There exists history database. You favourite editor or viewer likely contains a nice shortcut to view it (like ctrl+h in JOSM). Please use that for historic node information, instead of abusing was:* prefix in current database in various ways which are clearly against its intended usage (nicely documented on its wiki).

Anyway, whoever wanted to learn reasons why some tags are deleted and some not in SC, and why it is bad idea to abuse was:* prefix as some kind of makeshift poor-man half-functional history database (instead of using integrated full-fledged history database that OSM has!) had plenty of opportunities to do so by now.

Those who don't/didn't -- well, I can't really help then, so better not to waste anyone's time any more.

[matkoniecz]

Note also that if wiki is wrong or should be less strict or recommend something else: then discuss it on OSM Wiki or on OSM forum (in general section, at https://community.openstreetmap.org/c/general/38 or its tagging subsection ) or tagging mailing list or maybe talk mailing list.

(Note: I do not agree 100% with comment directly above, but that is not a place to discuss it)

To repeat:

If you want to map history - then OHM may be of interest, though I am not sure are they having notability requirements and is it OK to map say shops there. OpenStreetMap is not a place to map fully gone features.

Edits done by StreetComplete linked in this thread match what human mapper would typically do and definitely could do and are OK to perform.

[mnalis]

Unfortunatly in my professional experiment in localities it is better to use shop=vacant and office=vacant than disused:shop=yes.

For reference, behaviour was later changed in different way in #5548

hold off on updating the opening hours (because I don't know how to tag "this is closed, always").

If people are still curious, syntax for that is opening_hours=off (shorthand for opening_hours=Mo-Su off).