When I used taginfo to view various common payments, I was very curious about what it would look like from the list back to the front, so I found that a lot of key that contain non-ASCII characters existed in the payment: namespace, which seemed to need to be modified, and scattered around the world, I have no knowledge of the whole world, so would appreciate some advice (preferably a direct correction) from a community with knowledge of the language and region in question
Thanks
BTW, similar checklists may be updated from time to time
Including not only the picture above, but also more appearing in other pages
Today is the first time, so I checked it manually. After that, if I want to do data quality checks regularly, like running nsi-collector regularly, I will also write it as a script. Hope it can be like matkoniecz/OSM-wikipedia-tag-validator-reports
I’ve reordered the list below so they are now grouped by language - this helps the culturally appropriate community focus on issues。
Note that this classification is not exact and is based on my first impressions
In addition, although there are some tags that appear to conform to ASCII but are still strange enough to be listed together, hopefully they will be fixed:
At a glance, I see some values that are words for generic payment types in other languages, such as 現金 and 현금 (Chinese/Japanese and Korean for “cash”, respectively). I assume most of these occurrences were contributed by users of iD (or another editor powered by id-tagging-schema) who didn’t know the raw subkeys. The Payment Types field has always accepted freeform text entry since it was added in May 2016. It did list some suggested subkeys, but this was just a raw list of the most popular subkeys from taginfo.
Since October 2022, the most popular subkeys can be translated, so that a Japanese speaker who enters “現金” will end up setting payment:cash=yes. However, so far none of these strings have been translated into Chinese, Korean, or Thai. If anyone speaks one of these languages, please help translate the relevant strings.
Compounding the matter, there were bugs that caused these translated strings to be added directly to the feature in OSM. These bugs have since been fixed.
As for the more specific brand names of payment cards and such, non-ASCII characters might be appropriate. The “Any tags you like” documentation does say that ASCII is preferred in keys and values. However, it distinguishes between machine-readable keywords, which follow snake_case and stick to ASCII, and freeform, human-readable values for keys like name or operator, which can contain any Unicode character.
Some namespaces like payment:* and ref:* seem to be in a gray area: we expect underscores like in snake case, but as these are proper names, we haven’t applied all the rules that govern keywords, such as British English spelling. If we romanize these payment methods’ names, would software be more likely to support these keys, or would it introduce unnecessary confusion among mappers?
I hope to monitor these keys regularly because I think it may be recreated by other mappers in the future
For example, the most common cash I can tell it is cash, this words also appear in Chinese and Japanese, Minh_Nguyen also mentioned 현금 in Korean just now, but for others and more languages, I think at least this part should be unified as “cash”, because cash exists in all countries.
Another interesting subkey is University_of_Kentucky_Plus_Account and 校园卡(It literally means “campus card”, and we already have the key of payment:campus_card), the first is a kind of campus card but only can be used in specific area, should it be tagged as “campus_card”?
杭州通(Only in Hangzhou and other T-union city)、长安通(Only in Xi’an and other T-union city) are both stored-value cards for public transport (I believe there are similar stored-value cards in other countries), but mainly used in specific cities. should they be tagged as a general payment:cards？ There are too many similar phenomena of “belonging to a class, but more precise, but more precise values are very uncommon”, I think we should perhaps discuss allowing the use of payment:cards=<card_name> to reduce isolated subkey
How does the Japanese community feel about doing an automatic edit to unify it to ASCII? (For example, I saw rakuten_pay and d_barai have ASCII forms of payment used more than 1000 times)
Indeed, the payment tagging scheme is a mix of generic and specific values. You can say payment:credit_cards=yes, but you can also say payment:visa=yespayment:mastercard=yespayment:discover=nopayment:unionpay=no. Similarly, electronic tolling accounts and transit fare cards can be specified in more detail. This is good because users don’t want to find out at the last minute that they just barely lack a compatible payment method. If a user has gone through the trouble of looking at the logos on the door and tagging the specific payment methods, we should try to preserve that work.
Iterative refinement might be a good idea, specifically to avoid freeform keys. But payment:cards=[freeform value] cannot coexist with the existing payment:cards=yes/no. It would have to be something like payment:cards:brand=*. At that point, we might as well add payment:cards:brand:wikidata=*, or just payment:wikidata=* (with multiple values separated by semicolons). This way, a data consumer can look up all the names and icons they need from Wikidata, instead of maintaining their own incomplete lookup tables.
The University of Kentucky’s Plus card is a student ID card (campus card) that doubles as a debit card. I see you’ve already raised this issue on the one business tagged as accepting this kind of card. Given that it’s an on-campus eatery, I think this tag most likely refers to the university’s student meal plan. The Plus card is accepted at some off-campus eateries, and there’s another university campus just a few minutes away, so maybe it makes sense to be specific to avoid user confusion.
Yes, if there may be confusion, we may also imitate the example just now, and specify which educational institution this applies to through payment:campus_card:campus:wikidata=QID - after all, campus cards are usually only It can only be used in a specific school, generally if it does not specify what school - it means the school where this element is located (obviously)
Japan community has discussed and documented some of the keys, and it appears that automatic edit was also plan, but it does not seem to be implemented at present.
that has own problems: relying on third party database with own rules and policies and unsolved copyright issues (database rights), lack of human readability
I meant this as a complement to a less cryptic tag that would be useful for accessing information that is simply out of scope for OSM and its affiliated projects, such as logo icons, translated names, and network interoperability. Or would you advocate instead for recording logos as payment:cards:brand:osmc:symbol and names in, say, Japanese as payment:cards:brand:JA?
Frankly I don’t see why supposed issues around Wikidata’s database rights should be our problem regarding topics that aren’t geodata by any stretch of the imagination. Avoiding these external identifiers would naturally force data consumers to build their own lookup tables without local knowledge, which they could even do as closed source software and charge for.
“supposed” - has Wikidata even decided on how they go with database rights? They can entirely ignore it, what would cause problems for data reusers in areas where such stuff exists, or exclude edits in violation of it. But as far as I know they did first, without noting it anywhere and warning reusers of data.
“should be our problem” - it would become our problem if we would delete some data from OSM database or replace it with wikidata references. Then it would become necessary for people using/mapping it to start using Wikidata.
How does this have anything to do with pairing a business’ payment:* tags with one other piece of metadata? As far as I know, no one has ever raised similar objections about tagging field-surveyed VATINs, ISILs, addresses and postcodes, or other identifiers from external numbering authorities, despite probably clearer database rights issues around using the corresponding databases. Millions of features are tagged with GNIS feature IDs even though most of that database’s POI coverage was legally copied out of phone books, a practice that would be unlawful in some other countries.
No one even needs to “start using Wikidata”. It would be just as feasible for the OSM Wiki to list the QID associated with each of the payment methods it documents, and mappers and data consumers can crib from that list if they want. And if it’s something as obscure as the Plus cards mentioned above, try explaining your concern to the University of Kentucky, one of the early adopters of OSM in higher education, and getting their permission to essentially mention a webpage that mentions them.
As a general note, it should be possible to brainstorm about mechanisms for linking OSM to Wikidata, especially in areas that are clearly out of OSM’s core competencies, without getting shut down by the boogeyman of database rights and the strawman of deleting data from OSM.
