US Mailbox Check

[openbrian]

See https://github.com/russbiggs/spot-the-box/issues/26

General

Affected tag(s) to be modified/added: amenity=post_box Question asked: Is there an example tag on item XY?

Checklist

Checklist for quest suggestions (see guidelines):

• [x] 🚧 To be added tag is established and has a useful purpose
• [x] 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
• [x] 🐿️ Easily answerable by everyone from the outside but a survey is necessary
• [x] 💤 Not an overwhelming percentage of elements have the same answer (No spam)
• [x] 🕓 Applies to a reasonable number of elements (Worth the effort)

Ideas for implementation

Element selection:

Metadata needed:

Proposed GUI:

[matkoniecz]

Question asked: Is there an example tag on item XY?

It seems not fully filled out

[westnordost]

I looked at https://github.com/russbiggs/spot-the-box/issues/26, it looks like this is about checking if certain US mailboxes are still there. Unfortunately, this is not possible currently in StreetComplete, because StreetComplete lacks the ability to remove elements.

[westnordost]

Also, I am a fan of your microcosms PR on the openstreetmap website, I hope it will be merged soon 👍

[tordans]

…it looks like this is about checking if certain US mailboxes are still there. Unfortunately, this is not possible currently in StreetComplete, because StreetComplete lacks the ability to remove elements.

This might have been discussed before: Would it be an option to edit the from amenity to removed:amenity? IMO livecycle-prefixes are the better solution to removing such an object anyway since they allow to do data analysis later. We use it in Berlin to allow comparison with eg. official data "this tree from the city data was in OSM but was marked as »rased:*« in OSM."

[westnordost]

I don't think this is the approved way to do it. No objections if your local community does it like that, but an editor that imposes its tagging globally cannot do that as long as this method isn't officialy sanctioned.

[tordans]

I don't think this is the approved way to do it. (…), but an editor that imposes its tagging globally cannot do that as long as this method isn't officialy sanctioned.

I see your point. Unfortunatelly we don't have a good way to make this official, IMO. @openbrian could ask for opinions on the tagging mailing list but this will not result in an official statement.

One possible way to feel the water on this would be to implement it for one quest in one region and evaluate the reaction. A few arguments for this are IMO

• removing data is more destructive than disabling it; so disabling should be preferred as a first step. Its basically a trash can-concept that can be emptied later if needed.
• (especially) for situations where data should be compared with other sources, disabling data is preferred so one can more easily compare the data.
• the Livecycletagging for a prefix like "removed:" is IMO well established. In contrast: This is not true for other prefixes or other usage areas, like train tracks or the road-livecycle (for reference this discussion on iD last year))
  • The wiki shows only little controversy https://wiki.openstreetmap.org/wiki/Lifecycle_prefix (and Discussion-Page)
  • The comparison of livecycle methods shows nothing else that would fit this https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts
  • The removed:* wiki page fits the usecase pretty good IMO https://wiki.openstreetmap.org/wiki/DE:Key:removed:
  • 25.000+ usages does not sound to be well established IMO https://taginfo.openstreetmap.org/search?q=removed

In general, however, I would very much understand if the whole check_date-System is enough "excitement" for the moment :-). I just wanted to collect my thoughts on this for the future and for reference.

[matkoniecz]

@tordans Main problem is that strays into keeping historic data in OSM what is at best controversial.

[tordans]

Main problem is that strays into keeping historic data in OSM what is at best controversial.

@matkoniecz in such generic terms, I fully agree. However, I tried to be a lot more specific in terms of which data is touched but also what the context is (limited region, limited scope, still allow validation with external data). And in this specific situation, I personally think the road is more open than closed.

[Cj-Malone]

Potentially you could work around this with a related quest, like "What's the operator of this post box?", "What type of post box is this?" or "What is the ref of this post box?". Then users could do "Can't say" and leave a note for it to be removed via another editor.

[matkoniecz]

@Cj-Malone See implemented and released #85