Central campus vs. geographically scattered campuses: use relations to aggregate?
This should really be used for relations (assembly of buildings, sometimes scattered across town) too. Ipofanes 20:43, 12 February 2009 (UTC)
- How do you suggest we go about this? Representing the entire (fluid, externally changeable, non-physical) political hierarchy of a university isn't something we want to do in OSM, but as a first approximation it might be good to represent distinct university sites, campuses, colleges, halls of residence, and sports grounds in such a relation. Somehow. Each of the above could be a sprawling mess of buildings too, so it's very likely that any schema we come up with would be an (over-)complex affair. --achadwick 11:55, 6 January 2010 (UTC)
related to this I've written a bunch of 'how to map' information on the page here. I was mainly thinking about individual buildings, and stating that we should (probably) be following the One feature, one OSM element principle (so not putting the university tag on the buildings). But yes. "Scattered campuses" present a problem which might require relations or something. -- Harry Wood 14:41, 19 May 2011 (BST)
I'm in favor of using relations for scattered campuses or similar situations, such as in Italy, where universities are sometimes spread across buildings all around the city without having a proper campus. My proposal is that in such situation each campus should be tagged independently as amenity=campus, with the name=* tag used to indicate the campus name; a university relation should be used to gather all the campuses (or spread out buildings) together. We don't need to be able to represent the entire political hierarchy of a university, but we can have simple roles such as role campus, role department, role administrative (or offices or whatever), role dining_hall, etc. -- gbilotta 12:52, 25 Jul 2013 (CEST)
To stress why a relation would be appropriate, it's probably best to consider the example of the University of California: spatial query to find all related services would require the query to be run almost on the entire State (and let's not even talk about Teikyo University, that has campuses scattered all over the world). The other common objection to the use of a relation is that it shouldn't be used for categories, but in this case we're not talking of categories, but rather of an entity.
It should be stressed that there's a need for a relation **only** in the case of a scattered university. When all of it is located in a single campus, the amenity=university tagging scheme is sufficient. -- gbilotta 13:53, 25 Jul 2013 (CEST)
Should we promote the proposed site relation for universities? The use of the multipolygon relation for universities is not ideal (especially with the touching inner rings problem – not sure if this is a problem with the site relation too?), and there are already about 132,000 site relations in the database, which shows how widely accepted it is already. Chtfn (talk) 06:12, 12 September 2013 (UTC)
(Moved this topic here, since it may be related --achadwick (talk)) I'm not sure it really makes sense to use site, as such, except possibly for single campuses where things are in close geographical proximity. Such things are probably best served with an area using the existing amenity=university too. I see a "site" as being only useful for geographically close aggregations which don't necessarily have one single
One possible way forward
I want to keep it simple, using areas primarily because they're easier to draw. However, simple areas don't work in all cases, so we'll have to allow site relations and multipolygons as "areas" too.
- What to aggregate:
- Use plain old amenity=university on the enclosing area for any site or campus belonging to any institution providing higher education, where the site or campus is involved in teaching or study by students, or for university-only ceremonial purposes such as matriculation and congregation.
- Use appropriate commercial/leisure/place_of_worship/sports tagging on areas for sites belonging to the same institutions which have those purposes, and which support student life.
- Research stuff. Laboratories. Do we recommend commercial or industrial landuse for the usual? Depends on the lab, I guess.
- Site relations are OK here, but please consider whether a single enclosing area or multipolygon would suffice.
- Multipolygon relations are OK for sites, campuses, sports grounds etc.; consider these to be areas in the grouping below.
- Aggregate these areas and site-relations as members of a single relation with type=university. This represents the institution's physical stuff as a whole, and it's (for now) a flat relation.
- Tag the relation itself with the official name=* of the university.
- Specify a role for each element, if it has a distinct and predominant use. Suggested roles: department(s) (areas containing the buildings of one (or more) departments with its (their) own lecture theatres and/or libraries), campus (either a single wikipedia:Campus university, or a campus which is part of a multi-site university), college (a college which is part of a wikipedia:Collegiate university), library, ceremonial, research, teaching (shared lecture theatres and tutorial rooms), ..., <anything-you-like>. If a member doesn't really have a single focus, a role isn't needed.
- DO NOT include land holdings of a university which do not directly support teaching or study by students, or student life within the university. Remote forested or cultivated land which is the subject of study probably doesn't belong in the relation, for example.
Basically it's an aggregation of little blobs of land, and it doesn't matter how widely dispersed they are, or how compact. I may use the University of Oxford as an example, if people like this suggestion. It may be worth involving David.earl (on osm, edits, contrib, heatmap, chngset com.) too, since he's been doing a lot in Cambridge.
Halls of residence
Am I right in thinking halls of residence use this tag? --LeedsTracker 02:38, 17 September 2008 (UTC)
- For non-collegiate universities maybe landuse=residential combined with residential=university to distinguish it from other types of residential area would be appropriate. --achadwick 11:40, 6 January 2010 (UTC)
To clarify further and try and provide some useful criteria for making a distinction: landuse=* sometimes applies better than amenity=university, particularly when the housing provision is outsourced to a separate company and the blocks aren't really part of the university itself. Tag the enclosing area with amenity=university when there's teaching, research, student union activity, university sports or pastoral care going on as well as housing, and leave it to landuse=residential if it's just a residential block in part of a city, I suppose. Either way, individual halls within the area should get their own building=* in order to retain One feature, one OSM element. --achadwick 15:23, 19 May 2011 (BST)
Rendering on Mapnik
The amenity=university tag does not render as a shaded area on Mapnik as it does as a college. One example is Rowan University in Glassboro, New Jersey, which was rendered as a path rather than a closed polygon whose name was posted along the adjacent railway. CrystalWalrein 02:15, 3 December 2008 (UTC)
- I know this response is a bit late and the issue may be moot, but is the way closed? Are you sure? I had a similar issue a while ago, and it turned out that someone had broken the way and it was no longer closed. Yet, since the gap was so small, and streets overlapped most of the border, it was difficult to detect the problem. Vid the Kid 20:56, 30 October 2009 (UTC)
Conflict to landuse in some areas
amenity=university has been used for areas around buildings that belong to a university. But on the same area there are other buildings that do not belong to the university. Therefore I would tag the area as landuse=*, because the areas should be more a description of what kind of buildings and vegetation can be found there. What do you think?
The idea of my question is that university buildings can either be of an industrial kind, or integrated in the town, therefore there is no sense for areas around buildings (campusses) to be mapped as amenity=university, it might be useful to define a new campus tag or something if you want to tag a strict campus university which is not always the case.
Another feature I am currently trying is to integrate university buildings to campus relations, the question is: Can relations be member of other relations?
Would be great to hear your statements and ideas about this questions. TobiBS 13:23, 7 February 2010 (UTC)
- yes, relations can be part of another relation, but I really wouldn't do this. Site boundaries surround one-or-more university objects that then do not need to be included in any relation. To pull the entire university estate programmatically you would have to do a 'contains' query for the site boundaries, but the alternative would involve connecting every single object into a relation, which is fine if it is a couple of buildings but if micromapped this could include every tree, bin, or footpath. Jnicho02 (talk) 09:52, 4 June 2019 (UTC)
classification of universities
As proposed for schools (see: Talk:Tag:amenity=school) I would also recommend here the ISCED classification for classifying the highest level of education attainable from a tertiary establishment. What do you think? --ALE! 21:21, 10 May 2010 (UTC)
It make sense to me to represent collegiate universities like Oxford or Cambridge like this: represent any central or teaching/lab bits that don't belong to colleges as described on the main page, and name the colleges individually. The operator=* tag names the university the colleges belong to. Hopefully that's not too horrible a misuse of the operator tag.
A similar scheme could be applied to spread-out non-collegiate universities with multiple campuses or regional centres. Does OSM need to make a distinction? Should we go ahead and integrate it into the main page? --achadwick 13:24, 18 May 2011 (BST)
- Ah yes. colleges should get the name tag. Makes sense to me.
- It would be great if renderers would show the name of the university when you're quite zoomed out in these cases, but we wont be seeing this feature for some time. I can't think of a tagging scheme that would even hypothetically help that to happen. If a renderer really knew what was going on, it could pull out the operator from the scheme you suggest, so it's a good a scheme as any I suppose.
- -- Harry Wood 14:35, 19 May 2011 (BST)
Abuse of name tag / faculties
The name tag should not be abused to describe the usage of the building. If attached to a building it will describe the name of the building (usually university buildings do have names and refs, but if they don't please keep the tags clear). There is a suggestion to tag name=Chemistry;Physics but this only made sense if "Chemistry;Physics" was the name of the building. To tag the faculties inside a university it makes sense to invent another key and to develop a list of formalized standard values. --Dieterdreist (talk) 09:29, 1 May 2013 (UTC)
I agree. The name tag of the building itself should be the name of the building (if any). Also, the suggestion on the page to split up a building into several parts if there are more than one departments in it with each building part having a different name (different department) conflicts with how complex buildings (building complexes composed of different interconnected buildings of different heights) are mapped. I would suggest the following: Faculties or departments inside of the buildings are created as nodes or areas inside the building. In the common case where the department covers exactly the building, the area would be another polygon with the same shape on top of the building. This node/area then gets the name of the faculty or department and additionally faculty=yes or one of faculty=chemistry, faculty=sociology etc.
After thinking about this, I think amenity=faculty would be better here. faculty=xyz could be used in addition to the amenity=faculty tag.
university=faculty and university=department have a good tagfeel, for me at least. I'm quite a fan of drill-down notation ☺
My idea would be: If faculty is small, then just place node inside the building with amenity=faculty, name= Faculty of xyz, operator=University of ... If faculty is larger then one can even draw it as an area with the same tags. I would tag all buildings in the area with building=university,name=Hall of sth, faculty=Faculty of xyz, operator=University of ...
- After checking with taginfo it seems that faculty=* gets slowly established. I will put this suggestion on the university page now. --Dieterdreist (talk) 09:05, 11 October 2013 (UTC)
- I am still curious whether this is a main tag (i.e. faculty=* + name=* with no other tags needed) or a subtag (e.g. amenity=university + university=faculty + faculty=*, but then there will be multiple amenity=university objects although they all belong to one single university in the real world). This is even more of a problem for department=*, because all kinds of organisations, not only universities, have departments. In order to specify a universitarian context, we either need a parent tag or a subtag. --Fkv (talk) 19:41, 15 November 2018 (UTC)
How to map a... (university/school) area
How to map a area
- in front, behind or in the middle of the building,
- where students/pupils stay in the break/recess, waiting for the bus, or congregate in case of a fire alarm?
Naming of individual campuses
So the page says I should use a multipoligon for using an university with various scattered campuses. But the page does not at all explain how to name the indidual campuses. :-( I suppose it is not uncommon for the campuses to have names on their own. --Wuzzy (talk) 12:59, 10 July 2015 (UTC)
- I think that it may require inventing a new tag :( Mateusz Konieczny (talk) 16:05, 4 February 2020 (UTC)
- It depends on how the campus is operated. If you look above, the University of California is mentioned. According to the State of California, this is a "single" University with 9 campuses in Berkeley, Los Angeles, San Francisco, San Diego, etc - but UC Berkeley ("Cal") and UCLA have entirely seperate administrations, histories, sports teams, admissions standards, etc, and they are located in different Metropolitan areas - they are functionally separate Universities. In Arizona, "ASU West" and "Arizona State University" are officially connected, but they are quite far apart. For a few years ASU West had separate admissions and administration, but now they are again called one University, even though there are 5 separate campuses around the metro area, and the East (Polytechnic) and West campuses are 79 kilometers apart by car - too far even for Americans. In these situations I think it's best to map each "campus" as a separate amenity=university.
- I am aware there are other situations where part of a single university is located in several locations around a single city or town, and students may need to travel between campuses during a single day to take their classes for a particular degree. For example, the Universitas Cenderiwasih here in Papua, Indonesia has at least 2 campuses, with some departments and classes at each location. In that case, a new tag like amenity=university_campus might been helpful, if each campus has a different name.
- But it is questionable if mapppers will be able to verify this reliably, as the confusing example of ASU shows. Perhaps mapping each campus as a separate amenity=university is fine, since we cannot expect this sort of data to match both the "official" definitions and the popular understanding of how each campus is related? --Jeisenbe (talk) 02:57, 18 February 2020 (UTC)