Tagging of University

By looking at https://wiki.openstreetmap.org/wiki/Tag:amenity%3Duniversity and https://wiki.openstreetmap.org/wiki/Key:campus  for each university there should be exactly one object with amenity=university which is not a case currently on OSM. On OSM there is a variety of ways the Universities are tagged. Usually anything connected with University (building, campuses, etc.) have amenity=university tag which should not be the case by the Wiki.  

For example, https://www.openstreetmap.org/relation/15782282 is tagged per wiki instructions. Would there be any objections to do so in GB? Why? To unify the data and create a valid relation to represent real state on the ground. If you search for example for University of Cambridge you will get a lot of results, but neither will show you the whole University. The issue that I saw, and this might be the case why someone tags campuses with the university tag is just for the rendering of the name. This campus (West Cambridge Site) has proper tags, but it does not render on the map https://www.openstreetmap.org/way/689397200 I would like to hear from the community is this approach suggested OK or not, and if not what do you suggest?

Best regards,

Aleksandar Matejevic

Firstly the wiki should always be taken with a large pinch of NaCl, it should not be seen as instructions of how to map but should document how things are mapped.

In the case of Cambridge University I believe this question is asked periodically, and there are good reasons why it is mapped the way it is. Changes as you propose are likely to break the data used by consumers.

See https://wiki.openstreetmap.org/wiki/University_of_Cambridge and in particular the section https://wiki.openstreetmap.org/wiki/University_of_Cambridge#University_sites which explains that it is not a 'Campus' university.

Hi,

I maintain the University of Cambridge map at https://map.cam.ac.uk which is driven off OSM (on a freelance basis, and along with a small number of University employees in University Information Systems).

Wholesale changes to the way the data is represented cause large cost implications for the University. There are frequent mutterings of why they are paying to maintain a custom map when they could just use Google maps. One of the reasons why OSM has such a rich (and consistent) dataset for the University of Cambridge is that they, and the colleges, have given us permission to access their sites for detailed mapping. Lack of stability is a constant worry.

Having said that, there is no particular reason why a relation that collects together all the University properties could not exist. But if you create one, we would really appreciate not removing tags on the subordinate objects.

On the other hand, I don't see why a relation should be needed just in order to draw an area representing a campus already tagged amenity=university (indeed, as demonstrated by map.cam.ac.uk), and in that case, it is the renderer's problem. not the tagging. A relation would simply create an abstract link between them, which may be useful in some circumstances, but not necessary for rendering a campus. It's a long-standing convention that we don't change things just to make them appear on some particular rendering. To take a different example, Anglia Ruskin university has two quite distinct campuses in different locations. While something (whether operator= or a relation) is useful to tie them to that institution, it's not terribly useful geographically. Doesn't Nottingham University have a campus in China? There's a much larger analogous issue with schools where many individual schools are run by an overall Academy Trust.

The University of Cambridge is a complex institution, more so than many Universities. While it does have a (fairly large) number of sites which might be called campuses, it also has many separate buildings which aren't in any of those. It operates offices inside other blocks which aren't themselves university buildings. The thirty-one colleges, while affiliated with the University and are what most people think of when you say "University of Cambridge" are in fact independent teaching institutions, and some of them would object strongly to being classed as owned by the University. I think this is the case at Oxford as well, but not at other collegiate Universities like York and Durham (which is the rather specious reason Oxbridge are allowed separate teams on University Challenge I believe). But you graduate with a degree from "University of Cambridge", not the individual college. Then there are some institutions which are jointly run by the University and others (such as MRC or NHS), many of them on the Cambridge Biomedical Campus, which has its own management and includes Addenbrooke's Hospital, which is NHS, but has many University departments embedded within it or in their own buildings.

The University and the Colleges are also major landowners across East Anglia and beyond. They operate farms, mostly tenanted, but also things like Cambridge Science Park is owned by Trinity College, I believe, but is not "part of" the college, for academic purposes, even though strictly speaking, and maybe at one remove, they are the operator.

All of the University academic and administrative properties are easy to identify as they all have "operator=University of Cambridge" and all the sites, buildings and entrances have ref=... which is a reference derived from the codes the University Estates Department classify their buildings (see the Wiki page referenced above). Overpass will find all of them. The same is true of the colleges, which are tagged of the form "operator=Wolfson College (University of Cambridge)".

Originally all the buildings were tagged "amenity=university", which was, with hindsight, not the right decision, but I think those have now been replaced with building=university, so amenity=university allows sites (campuses and colleges) to be identified by amenity=university. But as I say, many buildings are stand-alone components of the University (the Hamilton Kerr Institute, to name just one of many examples).

Oh, one other thing: it might be useful if sites like e.g. "West Cambridge Site" were labelled "West Cambridge Ste (University of Cambridge)" to give some context when presented independently. Whether that is best done by the renderer taking note of the operator tag, or done explicitly, I'm not sure. (From a navigation point of view, labelling it just "University of Cambridge" would be singularly unhelpful.)

for each university there should be exactly one object with amenity=university

I'm afraid the wiki is incorrect in this instance.

Besides Cambridge there are numerous universities with both complex geographical and organisational structures for which this notion does not work.

For instance the University of California consists of a number of very well-known universities (Berkeley, UCLA, US Davis, UCSF Medical School, etc.), and some of these may have more than one campus. This federated structure also applies, but less so than formerly, to the University of London and the University of Wales, and a number of state universities elsewhere in the US. The Eastern Switzerland University of Applied Sciences has campuses in St Gallen, Rapperswil, Chur and in Vaduz, and also has a federated structure.

Many universities maintain outstations for particular types of scientific research which may be located tens to hundreds of miles from the main location. Also many university medical schools have small teaching centres at the main hospitals where their students train. Agricultural faculties are also often located some distance from the typical main sites.

Also these days universities are getting so large that locating on a single campus with a few nearby scattered buildings is infeasible. Most universities now expand by building entirely new campuses in new locations. Additionally, mergers between smaller universities also tend to towards widely dispersed centres.

Finally, some universities have campuses across the world. My local one, not only has 4 large campuses and a medical school in Nottingham and at least 2 postgraduate teaching centres at hospitals (in Nottingham and Derby), but it also has a separate campus located in Sutton Bonington about 20-25 kilometres from the city. AND it has a campus in Ningbo, China and one near Kuala Lumpur in Malaysia. Mapping all these as a single relation (of any time, but multipolygon is particularly inappropriate) does not make sense for nearly every purpose other than counting numbers of universities. Note that both Ningbo and the Malaysia campus are branded "University of Nottingham, but are actually joint ventures with bodies from their home countries, so just lumping them together without understanding the underlying legal structure again does not make sense.

The approach which has been in existence for many years in the UK is to mainly map individual campuses and ensure that all have a suitable operator tag. The alternative usage of multipolygons leads to odd and infelicitous use of place=locality, as here in Tuebingen.

OpenStreetMap does not lend itself particularly well to enforcement of some kind of data normalisation, and indeed the tagging approach adopted at the outset deliberately eschews it. One of the reasons to avoid trying to normalise data is often the relationships involved are much more complex than the simple cases.

I see that there are a lot of things that can impact the current situation if some tags are changed, but I was not talking about removing anything from the map, just putting entities that are under one University under one relation. In that way, you can easily find all campuses, buildings, and libraries of the same University. Another thing is that you can put name variants to only one relation and search will find the University no matter which language is used. For example, if you search for example the University of Bath, then you will get the result, but if you try on Spanish, Universidad de Bath, you will find nothing. And it is way easier to add these to one relation than to go one by one entity and add tags. Also, this will mean that you will need an operator tag in variant names, which really makes things more complicated. So the question is are there any objections to creating unique relations for each University without removing anything from the current state of the OSM?

It's better to use the operator tag, and then you can also ensure consistency by also using the relevant wikidata tag. This enables you to solve your problem (and multiple languages) without adversely changing how universities are mapped.

Note also there is no expectation that all factories owned by a single multinational, or all shops owned by a retail chain should be mapped using relations. In fact this is generally disapproved of under the "relations are not categories" rubric. This is another reason why the notion that universities should be one relation is just inconsistent with how things are generally mapped on OSM.

Can you help me understand few things?

1) How do I group by operator tag that is slightly different e.g.:https://www.openstreetmap.org/way/164365655 has "University of Cambridge" as operator and https://www.openstreetmap.org/way/3997908 has "Robinson College (University of Cambridge)" as operator. Relations give much more reliability and are much easier to process than grouping entities by string tags...

2) How do I differentiate between Heidelberg University and Heidelberg University (Ohio) - Wikipedia if they have same operator tag? There are more samples at university - Can two universities have the same name? - Academia Stack Exchange.

3) How am I supposed to look up University of Cambridge if it simply does not exist? Harvard University on the other hand is nicely searchable, displays all colleges that are part of it, and has Wikipedia link and names in different languages...

4) Are we supposed to maintain offline private mapping list of operator tag value mapping into wiki and different languages? Because that is basically what you are asking us to do... And we will if we can't add relations to OSM... And we really don't want to do that...

Thank you,

David