Say a school (primary and secondary education, not a university) has many sites in the same city. How do I tag them? Are they site=* or campus=* or branch=*? Or do I add the site directly in the name?
1 Like
campus=* and branch=* are completely duplicative. branch=* is much more common and better supported among data consumers. However, you’re free to use campus=* too if you’re concerned that branch=* isn’t descriptive enough.
Either way, you can also include the name of the campus in the name=* if that’s how people actually refer to the campus. For example, in the U.S., the satellite campuses of a “University of X” are variously called “University of X at Y”, “University of X, Y Campus”, “University of X – Y”, or simply “X Y”. Since the fully qualified name is unpredictable, we need to tag it explicitly.
By the way, the documentation for campus=* suggests that a university should be represented by a single element tagged amenity=university no matter how disparate its campuses. This is an opinion held by some mappers, but it’s actually unworkable in general when considering institutions that have campuses spread across a whole country or even internationally. Instead of trying to adhere to a firm rule like that, consider whether laypeople treat the locations as a single unit or multiple units in reality.
2 Likes
Thank you @Minh_Nguyen, very clear answer. In this case I prefer using campus instead of branch, because it’s more precise, and branch sounds too much like a company.
Regarding having a single relation for all campuses of a university… what a pointless idea. Why have a single relation for EDHEC Business School spanning Paris, Lille, Nice, London and Singapore, when you can have one element for each campus.
1 Like
Quoting from the wiki:
That’s how I’d do it. A branch=* however, I would rather use for a “chain” of schools all operated by the same group of people. We don’t have these in Germany, so I cannot comment if that fits your needs. I understood your situation to being a single school with scattered sites in the same city.
For example, this school occupies multiple classrooms scattered about a campus shared with other schools. Each classroom is mapped as a point because the exact indoor layout of each building is unknown. Since a valid multipolygon cannot include a point as a member, a site relation is the next best representation of this school. A
label point allows the school to be represented as a simple point, since few if any data consumers understand site relations. ↩︎
Well - it depends. If all of the tags apply to all of the sites, (perhaps a school has two areas, either side of a main road) then that will work. However, if all tags do not apply to all parts then the wiki is wrong and a multipolygon is not the correct answer, and the other answers above (including the accepted solution) better explain the options.
Here’s an example of the problem. One school has two (in this case fairly close) buildings. It’s been mapped as a multipolygon so that both have the addr:housenumber of the main building. An attempt to find the address of the smaller building will find the address of the larger one. In this case, it might be reasonable since they are so close together, but there are examples where people have mapped schools as multipolygons with address information in different cities, which probably isn’t.
The address of the school is on the MP, because that’s the official address of the school, not the building. The buildings each have separate addresses, which is to be expected, and are tagged as such. Since both buildings are a single school, there should only be one amenity=school.
What you were doing was querying the address of the property, not of the building. If I do this for the building, then the correct address is returned. The problem would also happen if you had multiple buildings with different house numbers on the same ground (which is very, very common for schools or public institutions over here).
How else would you suggest to tag it, given that we don’t have something like school:part=yes?
It all depends on whether the first part of this sentence holds true. We can’t generalize beyond that. It’s entirely possible that what counts as a “school” depends on the local educational system. It can also differ between a mapmaking context and a more holistic context, such as on Wikipedia. For us, a school is a subclass of a point of interest, not a subclass of an organization. There’s an inherently physical, on-the-ground-verifiable aspect to it.
The same thing can happen with libraries: a great many libraries (as organizations) consist of multiple branches (as individual facilities), which are understood to be libraries in their own right in a map context. And yes, branch=* is very common among these libraries, so that key isn’t limited to businesses.
It would be quite pedantic for this tiny example, but there is a solution for much larger campuses:
1 Like
I completely agree: if something is run independently, then each is a separate unit/POI, maybe with a different branch=*. And the wiki is applying the same logic for schools: one entity, one POI. And that, to me, makes perfect sense.
That solution is mentioned in the wiki of amenity=school to be used in case your schools are node, not ways. And so does the site-relation wiki:
A site relation is appropriate when a single real-world feature, with a common name and other common characteristics, cannot be accurately represented by a single or multiple areas forming a multipolygon, since it incorporates one or more point or linear features.
So because I haven’t got a mixture of linear, and point features, the MP seems the simpler approach, and valid as well.
1 Like
Neither of the examples I gave would be appropriate uses of a multipolygon relation. A building on a campus, included for the sake of indicating the location of the address, would be neither an inner member nor an outer member, even if it is mapped as an area. In some other situations, a multipolygon might suffice, but it isn’t performing quite the same function as a site relation would.
To illustrate what I was trying to say:
Lycée Français International Louis-Massignon in Casablanca has:
A school in Val d’Anfa
A school in Mers Sultan
A school in Bouskoura
Each with different staff, different directors, different students. A student would study in only one of them.
I just tagged all 3 of them yesterday. My question was about where to put the “Val d’Anfa”, “Mers Sultan” and “Bouskoura”. In the name directly or in campus=* or branch=*?. Note that these schools are commonly called “Lycée Français International Louis-Massignon Val d’Anfa”, “Lycée Français International Louis-Massignon Mers Sultan” and “Lycée Français International Louis-Massignon Bouskoura”, so I would guess I should name each of them as such; but I still wanted to be sure of the good practice.
2 Likes
No, I was referring to that school I mapped which has 2 locations, but is a single entity.
Then what exactly is the difference? The wiki isn’t being very clear, just that you should avoid site relations, unless they cannot be expressed in any other way (like an MP).
That is absolutely correct and a good example where branch=* is the right way to describe them 
1 Like
I’m not arguing with you, just clarifying why the schools I gave as examples aren’t mapped as multipolygons. (This has been the subject of some back and forth over the years locally.)
2 Likes