At many universities (in the US at least), the campus cards issued to students double as a payment card. Students typically can deposit money into the card and then spend from their balance. Some schools’ cards are only for paying for university services, some are accepted at various on-campus businesses, and some are even accepted at many off-campus businesses. Some examples:
University of Cincinnati: Bearcat Card is accepted at businesses on and off campus.
High Point University: HPU Passport Card is accepted at “nearly 100 local businesses”.
Indiana University: CrimsonCard is accepted throughout IU’s nine campuses and at some businesses near them.
University of Alabama: Action Card can be used to spend Bama Cash at quite a few businesses.
It seems like it would be valuable to map which businesses accept these cards, but I’m not sure how to tag them. One option would be to invent a new tag for every university (e.g. payment:bearcat_card, payment:hpu_passport, payment:crimsoncard, etc). This fits well into the existing scheme for payment cards, but would result in potentially a TON of new tags. It would be difficult for renderers to catalog them all and make sense of them, particularly since some universities have very similar/identical card names (e.g. “One Card” or “OneCard” seems to be used by a ton of schools)
A perhaps better option would be to create a generic tag like payment:campus_card. Instead of setting the value to yes, you’d set the value to the name of the university (or semicolon-delimited list of universities). Ideally we’d then have a list of known university cards on the wiki to make sure everyone uses the same formatting (alternatively, we could use Wikidata IDs instead of names).
What do others think about this? And, has anyone previously attempted to add these cards to OSM?
It has been suggested to categorize with countries before https://wiki.openstreetmap.org/wiki/Proposal:Digital_wallet_payments_V2
This could need both country and even hyphenated state/subdivision payment:AA-BB:*= (would be unlucky if the same state has multiple systems named the same), with the campus. If it’s only usable by staff and students, university:payment:AA-BB:*= might be worth considering, when it has no public use and general interest.
Is there a need to specify the universities though? Naming the card would be less complicated, and more recognizable. Transit cards aren’t directly associated with the transit system or authority either, while that can be more important and exact.
+1, I would do it like this, payment:bearcat_card=yes etc., this is how payment methods are expected to be tagged, and it is natural that it would result in new tags because this is the result of having a specific key for every payment method, there is nothing wrong with it, these keys will only be locally relevant, hence reflect the actual situation on the ground, where the payment method is also only locally relevant.
I would not prefix this with “university” or something similar, it is not what we usually do with payment methods.
The question is about different universities having same named OneCard etc. It can happen in at least the same country. (Haven’t looked at their addresses)
Random 1st page search results of Canada. Have looked at those allowing off-campus purchase. university:payment:*= / payment:university:*= makes them clear they are limited-use and limited scope. As an added benefit, helps in avoiding collision. Regardless of this, the country proposal has been drafted, and previous version had RfC.
Upon checking, 5 of the 6 examples are already in the same Ontario (except the obviously named Alberta). Not to mention universities can have campuses across different states. So the hyphenated subdivision mostly doesn’t work.
One possible advantage of university:*= is shortening the namespace, and keeping the format (data type) organized (strict)
shop= / amenity=
university=affiliate (eg, optional): Attribute only, not a feature
I do like the idea of having the university in a separate property. How about we have payment:campus_card with possible values of yes/no/only/interval (just like all other payment:*), and then a supplementary property campus_card with a semicolon-delimited list of the campus cards they accept (e.g. campus_card=Bearcat Card;HPU Passport). I prefer campus_card to university for the property name, as it’s possible that this kind of card might exist somewhere that isn’t a university (i.e. perhaps a large employer or a high school).
This approach has the advantage of making it really easy for a client to support this property the same as any other payment:* property. Most of the time, it would probably be obvious to the user which campus card a place accepts; they’re usually only accepted at businesses on/near campus. Thus, if a client decided to just indicate “campus card accepted here” without doing the extra work of showing the campus_card value, it would still be providing useful information.
We could also have the subproperties that @Kovoschiz described. Perhaps something like:
payment:campus_card=yes
campus_card=Bearcat Card
campus_card:for=University of Cincinnati
campus_card:for:wikidata=Q153265
That’s a bit much though; perhaps it would make sense to have campus_card:for OR campus_card:for:wikidata, but not both. It’d be more ideal if the card itself had a Wikidata item, but we’d have to go create such Wikidata items.
If you include “large employer”, campus_card isn’t ideal either. Although “company campus card” seems to be used sometimes, it’s not intuitive and obvious, compared to school campuses. “Company card” / “Corporate card” has another meaning in cards for staff to pay on behalf of the company, not for themselves. They are very different. Would you be able to find example of such cards as an employee benefit?
When there are cards from multiple levels of education accepted, university etc at least allow them to be separated by the feature. Avoids being too long, unwieldy, and mixed up together. payment:campus_card= + campus_card= doesn’t seem very elegant, *:for= is usually used for user group and demographics, and not proper names.
I used to work in an office where they had a self-serve vending area and you paid with a reloadable card. Here’s an example of a company that makes such systems. Besides that possibility, I think it’s also important to have the name of the card somewhere for practical reasons. Businesses typically advertise what they accept by the card name, not the university name (e.g. “Bearcat Card accepted here”, not “UC campus card accepted here”). So I do think we still need a campus_card property or similar.
I do think it also makes sense to include the university name for sake of clarity, but I still think university is a bit odd because it might not be clear that university relates to the payment option and not something else. Looking at taginfo, I see there are many existing uses of university, most commonly as a supplement to building=university (well, and also to tag one specific university in Bolivia). It seems possible that there could be a case where university’s meaning is ambiguous.
Very good point that campus_card:for is inconsistent with other *:for properties. What about campus_card:of or campus_card:issuer? I think it’s important that it be clear that the business might not have any affiliation with the university beyond accepting their card, so I like it being explicitly linked to the campus card.
If it’s a card that is really usable at 100 shops throughout the city, then I agree that it is worth tagging with a unique payment:* tag.
On the other hand I don’t like the idea to have a separate payment tag for the private id card of every company and university. In most cases, the number of locations it can be used at is minimal and names are far from unique which makes the added value for OSM tiny for most of these cards.
I’m very much in favor of this. ‘Yes’ should be an allowed value if the POI is on-site of the campus of the respective organization.
In most cases, the number of locations it can be used at is minimal and names are far from unique which makes the added value for OSM tiny for most of these cards.
I don’t think card names not being unique is a big issue, either mappers become aware and use keys that are unique even when the card name is not, or you could very likely see which circuit is which by clustering the occurences.
I forgot to specify the case of being usable in publicly accessible spaces, and external businesses, for this topic. OSM won’t be adding the coffee machine in some room of a random office. At most, I would imagine maybe some health or government facilities have it for medical workers or civil servants. *:of= is very lacking in meaning and instruction. It’s not really the *:issuer= that’s used here, but the identity, unless this is only trying to distinguish different cards.
This reminds me of customers= in access=customers . That coincidentally already has the same problem of mixing up freeform proper names, and pre-defined public_transport= together, meaning it can’t show the features and names applicable at the same time. That shows why I want to avoid mixing =yes and proper names in payment:*= , to keep the data clean, tidy, and organized.
The university classification could be dropped, relying on naming it only. Or payment:campus_card=university can be acceptable. In any case, this still leaves the question of fitting the names and *:wikidata= in.
The University of Kentucky has a debit card program integrated with its student and employee IDs. Originally, it was called Plus, so a mapper coined payment:University_of_Kentucky_Plus_Account=yes (using iD’s Payment Types field, which does that when you type in something unrecognized) to avoid confusion with Visa Plus. Others noticed the new key and complained about its verbosity. Shortly after that discussion, the university rebranded it to a more unique name, CatCash. I’ve replaced payment:University_of_Kentucky_Plus_Account=yes with payment:catcash=yes and added a corresponding data item and Wikidata item. I think it should have a unique key, because it’s accepted at a number of off-campus businesses and also used by some students at another nearby community college.