Mir ist aufgefallen, dass payment:cash=only sowohl von OSMand+ als auch StreetComplete nicht ausgewertet wird. In OSMand+ werden gar keine Infos zu den Bezahlmöglichkeiten angezeigt, und StreetComplete zeigt am selben POI die “Kann man hier mit Karte Zahlen?”-Quest an.
Natürlich könnte ich einfach pament:cash=yes + payment:debit_cards=no + payment:credt_cards=no ergänzen um die beiden ruhig zu stellen, aber das wäre dann tagging für die Endanwendung.
An dem POI an dem mir das aufgefallen ist hatte ich das payment:cash=only selbst ergänzt. Deshalb kann es auch sein, dass ich einfach nur die Formatierung vermasselt habe. Oder wird der Tag nicht mehr unterstützt und das Wiki wurde dahingehend noch nicht angepasst?
Tatsächlich fehlt hier payment:cash im Element-Filter des Quests hier.
@Mateusz_Konieczny Since it is your initial quest: Should I open an PR to add and payment:cash != only to line 20 (git)?
This could be used to prevent this case or what do you think?
Über 300.000 payment:cash=* von denen nichtmal 2000 =only haben. Es sieht also nach einem typischen Henne-Ei Problem aus. Warum sollte ein Datennutzer etwas so seltenes unterstützen, und warum sollte ich als Mapper einen Tag benutzen, der ohnehin nicht unterstützt wird.
Ich werde es jedenfalls weiterhin nutzen und hoffen, dass es von OSMand+ und anderen Apps irgendwann mal unterstützt wird.
Value “only” is also documented and from the documentation it is not clear that “others” is better supported
only: Only the defined payment method in the key is accepted. For example: payment:via_verde:lanes=only|no|no. Note that there is also payment:others=no that can be used to mark payment option list as complete.
True. I’ll mention that on the wiki, unless others object?
Not only it seems payment:others=no is more popular in usage, but (admittedly small, but quite popular) sample of editors/apps that I’ve checked (iD, StreetComplete, OsmAnd) all seem to support payment:others=no but not payment:cash=only.
It is hard to compare because payment:others is more flexible. “only” is only usable when one single payment method. And you also not concerned possible other payment:xxx=only
Agreed, it is another of payment:others=no advantages (in addition to usage counts, and data consumers support). Another not yet mentioned advantage is impossibility of conflicting tag meaning (which can happen with alternative, e.g. payment:cards=yes + payment:cash=only like this)
If you remove the rise in 2024 I guess under the influence of a editor (SC?)
Why would you remove significant numbers from statistics ?
Anyway, number advantage is not due to StreetComplete; SC only takes payment:others=no in consideration to skip asking a quest; it will only tagpayment:cash=yes|no.
Especially when numbers are in the same range (i.e. if we ignore that payment:others=no is somewhat more popular) I’d strongly consider which actual data consumers support the tagging.
So far I’ve seen that (going by the number of users) most popular OSM desktop editor (iD), most popular mobile editor (StreetComplete) and probably the most popular FOSS mobile navigation app (OsmAnd) all support payment:others=no explicitly, and none of them seems to support payment:cash=only. That seems to weigh quite a lot to me.
How does that compare with explicit payment:cash=only support (IOW which editors has that tag as a separate preset value, which data consumers treat it in its full meaning i.e. differently than payment:cash=yes etc.)?
Anyway from your original comment I’ve understood that you would like the wiki to be clarified with current situation about support/usage; which is why I offered editing it; but perhaps I’ve misread? (I’m asking because in your followup post it seems to me like you disagree with my assessment of payment:others=no being preferred? But again, maybe I’m misreading , I guess English is not native language to either of us)
I just wanted to point out that I don’t think the numbers are that different for being a good argument, especially if they are distorted by the recently implemented editor support for one of the tags. All other arguments (flexibility, better support) are fine and I have no problem with payment:other=no. We may even deprecate the value “only” in this context.
If you select payment:cash as a key in iD, then it’ll show yes | no | only as possible values.
If you select payment:others as a key in iD, then it’ll show no possible values.
I don’t know if other editors have presets that support one variant over the other.
AFAICT, not in the regular presets (i.e. expanded-by-default “Fields”).
Try adding a new cafe for example. When you type “pay” in “Add field”, it will add “Payment types”, in which when you search for “cash” you will only get an option for “yes” and “no”, but not for “only”.
For “payment:others” (or any other payment value), you can also select between “yes” (blue checkmark) and “no” (no checkmark and overstricken).
Of course, in raw tag editor (i.e. collapsed-by-default “Tags” section), you can always add anything, and I believe that basically any popularly used tag/value there will be offered for that autocomplete dropdown list (e.g. if you add “species” key there in the raw tag editor, it will allow you to select for example “Acer rubrum” value, even if it is never even mentioned in the wiki, but has 15k uses in the database)
I don’t know if other editors have presets that support one variant over the other.
Out of the big ones, JOSM doesn’t (it also allows “yes” / “no” / unset for payment types, but does not show “others” subkey either, so does not support either schema out of the box – of course, its raw tag editor “kind-of-supports” both schemas, by offering to autocomplete any value present in currently downloaded dataset and/or recently used tags/values AFAICT, but while convenient, that doesn’t really count as “support”)
That is exactly what I was talking about in the previous post. I asumed these are presets, and not just a list of commonly used values. That dropdown list has yes | no | only for payment:cash and its empty for payment:others
?
, I guess English is not native language to either of us)