Eduroam is a “mechanism” that allows for almost any uni student or professor to use wifi at almost any other university in thr world.
The problem is that this means eduroam networks are not really “public” in the sense that almost anyone can use them but they aren’t private or internal either.
The best option I can think of right now is to create a internet_access:for tag with the following possible values:
anonymous_public — no registration of any kind is necessary but logs may still be kept and ot may require some sort of ToS approval.
registered_public — the user needs to do some sort of registration before using the network.
customers — the user needs to actually be a costumer of the place to use the network.
members — the user needs to be already a member of the place and the application process is “non-trivial” (e.g. becoming a uni student)
Thus, eduroam would be tagged as internet_access=wlan, internet_access:for=members, and internet_access:ssid=eduroam.
Note that this is not the same as internet_access:fee as that is about how much money it costs meanwhile internet_access:for is about who can even hope to use/pay for internet access at the place.
For me it’s a private network. Similar like all employees have usually access to the internet at all the locations of that company. Do you see any difference?
Yes, the difference is that eduroam is huge and multi-institution.
Also, the eduroam ssids may also offer local logins for temporary guests. Think like an academic event in which the participants recieve a username and password valid for a single day.
*:for= is usually for user groups. =students is a possible example.
1,2. There is no such difference in access= . Anonymity and registration are separate aspects, which would still have =yes .
4. “members” is not clear. A membership can be open to public.
There are already some solutions that can be considered.
internet_access:ssid=eduroam is a coincidence of Eduroam requirements. This can’t always be expected for other wifi services. It should use eg internet_access:network=eduroam . Similar to internet_access:operator= perhaps for the university, or should that be internet_access:owner= ? (It is uncertain what ISP vals in internet_access:operator= is used for. Maybe this is what internet_access:provider= is meant for. Another example of dubious advice from wiki.)
Another issue is internet_access:ssid= is unreliable at handling multival. As space and semicolon are allowed chars for SSID, there needs to be a reminder to avoid them, and escape when part of the SSID. If the SSID is the same, it may not be necessary to add it. There are some untidy examples already. Search results | OpenStreetMap Taginfo
All the temporary guest logins I’ve seen (as an eduroam user) came “from” another SSID. The nice thing about eduroam is that the eduroam SSID usually just works, once properly set up.
But where is the difference (except scale = number of users). If you look from a distance, there is a closed user group, where not everyone can be part of.b Talking in OSM-access categories, eduroam is not permissive, but private. I can become part of if I’m employed by a university (exactly the same as any other company) or being a student (which in a generalized perspective is similar to being employed).
Being part of an university is definitely something different than a membership. Membership would be something like I’m member of some restaurant loyalty program and therefor that restaurant grants me access to a wifi. Another difference would be that a membership is typically open to everyone, where getting accepted as a student at an university is not open for all.
In summary, I think it might be better not to tag the eduroam-wifi, but adding the information, a university is part of the eduroam-Network might be better. For example add eduroam=yes to the university object.