Quest about defibrillator location appears even if local location already filled

[Wouter-M]

I got asked to describe the location of a defibrillator (location Netherlands), even though defibrillator:location:nl was already filled in.

How to Reproduce
Example of the node where this happened: https://www.openstreetmap.org/node/11597869445#map=19/53.211012/6.565124

Expected Behavior
If the local language is already filled in, do not ask for filling in location.

Versions affected

V60.1
Android 14

[mcliquid]

Why is defibrillator:location:nl set when defibrillator:location is not set? And shouldn't the main tag represent the local language in the respective country? Osmose would throw an error as far as I know. Osmose would also throw an error if defibrillator:location:nl and defibrillator:location are set simultaneously in the Netherlands because it would be duplicated and redundant information.

[mnalis]

I got asked to describe the location of a defibrillator (location Netherlands), even though defibrillator:location:nl was already filled in.

Yes, it checks only location and defibrilator:location tags:

StreetComplete/app/src/main/java/de/westnordost/streetcomplete/quests/defibrillator/AddDefibrillatorLocation.kt

Line 17 in bdda17f

and !location and !defibrillator:location

Why is defibrillator:location:nl set when defibrillator:location is not set? And shouldn't the main tag represent the local language in the respective country?

I would expect that too, but there are different tagging practices. Netherlands itself is perhaps¹ somewhat easy case where nl is known language default, but for other countries (and especially smaller regions!) which have multiple official languages, it is not that easy.

Osmose would throw an error as far as I know. Osmose would also throw an error if defibrillator:location:nl and defibrillator:location are set simultaneously in the Netherlands because it would be duplicated and redundant information.

I'd need to recheck, but I seem to recall the opposite - that Osmose was actually complaining when name and name:en were set in Croatia, but name:hr was not set (i.e. it expected duplicate information - that name:hr was set to the same value as name).

But then, I would always take Osmose warnings with grain of salt.

---

That being said, I do not see an easy solution for skipping the quest. While SC could skip asking the defibrilator location if any of the languages is provided; that is (to say the least) not optimal.

Given the importance of the AEDs, I'd say current situation of having user entering (possibly duplicate) location in case defibrilator:location tag is missing is preferred, even if it results in some duplication of information. Some data consumers might not have support for language-specific *:location tags, and you'd probably want this information to be quickly and readily available in any case.

As an alternative, Netherlands community could decide to do automated edit setting defibrilator:location on all object that have defibrilator:location:nl but miss defibrilator:location if they prefer that.

Footnotes

1. or is it ? Wikipedia says Frisian language is also official in northern parts, in addition to Dutch? So I can envision situation where defibrilator:location is in Frisian, but defibrilator:location:nl is in Dutch, or there is defibrilator:location:fy but not defibrilator:location (in Dutch(, or defibrilator:location:fy and defibrilator:location:nl but no defibrilator:location etc. ↩

[mcliquid]

I'd need to recheck, but I seem to recall the opposite - that Osmose was actually complaining when name and name:en were set in Croatia, but name:hr was not set (i.e. it expected duplicate information - that name:hr was set to the same value as name).

Just checked, it's Item 5060.

Classes:

1. Default and local language name not the same
2. Local language name without default name
3. Language name without default name
4. Multilingual not matching
5. Multilingual missing detailed name
6. Multilingual missing main name

In these examples (Class 3 above), the name:en and name:hr subkeys are set, but not the main name tag:
https://osmose.openstreetmap.fr/en/issues/open?source=6569&item=5060&class=50602
https://www.openstreetmap.org/node/10025852460
https://www.openstreetmap.org/node/10025869872

But then, I would always take Osmose warnings with grain of salt.

I would always assume that reports from QA tools are about potential concerns, not bugs.

[westnordost]

See @mnalis