How does "One feature one element" apply to a installment hosting several administrative entities (schools)?

Help and support
1

I could use some help with the One featrue one element guideline, I read the page about the guideline but I couldn’t understand how to interpret it

According to the public education ministry web site this premise hosts 2 different schools

This is one of them

And this is the other one

One is classified as primary school and the other one is a “childhood” school

They share the land, the building, the classrooms, the bathrooms

I see no reason to believe there’s any compartimentalization between the 2 schools

Is the tagging I linked wrong ?

Someone argued that it’s wrong because it violates the One feature one element guideline

According to such argument, the 2 schools are 2 features and they should be mapped with 2 distinct elements

As I see it, the 2 schools are administrative entities, not geographical entities

The geografical entities here are the land with the building on top

I could use some help, here

Thanks

1 Like
2

It could be expressed as a single school building (building=school); with two points for the two constituent schools. The whole site should then be tagged landuse=education. Like the Riverside Campus example below. (EDITED from earlier, less correct tagging - amenity=school & school=shared_site)

Examples to look at (and/or to critique):-

1 Like
3

I never heard of this tagging before. Taginfo shows only 215 uses so far, and with no documentation or any other references about it.

Sounds something that should be documented, because I’m sure there are quite many cases with many schools in the same site, and also sharing it (meaning it’s not adjacent schools that appear to be sharing the site, but in reality there’s fence between them).

1 Like
4

Good point. I’ve done lots of schools mapping, based on the check against the office UK schools lists provided here: UK Schools | Robert Whittaker's OpenStreetMap Stuff . That site recommends shared_site to avoid problems with double counting.

1 Like
5

This seems outdated with landuse=education
A shared campus in itself is not a =school
I would agree with having a new education= feature for it, but not =school

2 Likes
6

I’m not sure I understand this remark

Would you mind to elaborate, please ?

Thanks

7

If there’s a need, you could suggest inventing eg education=shared_campus , not using school=
Several situations can further be distinguished

  1. Related schools fully sharing and mixed in the same area
  2. Related schools having their own areas, but sharing some connected and co-owned facilities
  3. Unrelated schools having their own areas, and sharing some independent third-party facilities

1 and 2 might be education=shared_campus + shared_campus= defined as the same feature with different attributes. 3 could be another education= feature, as they are different campuses.

8

I’ve updated the Barking Riverside example in my email above to use that landuse=education tag instead.

1 Like
9

It’s a pity landuse=education doesn’t render on Carto. I’ve contributed to the ticket here:Add rendering for landuse=education · Issue #774 · openstreetmap-carto/openstreetmap-carto · GitHub

1 Like
10

Clarifying how landuse=education is being used would definitely be useful.

The principal problem with rendering landuse=education is that the Wiki presents competing uses - firstly for a shared campus and secondly as a rival/replacement for amenity=school. Carto, on principle, will not render competing tags (well not unless it completely replaces the old tagging).

11

They aren’t “competing”. Can use for both. Compare eg =industrial
It’s not a “rival”, let alone “replacement”. It’s a generic classification of the land. It can be used independent of how the amenity= / education= is working or drawn.
It would take much more time and effort to formulate a single or multiple amenity= / education= for the former. And yet more to convince Carto rendering that.
Carto seeing this as a problem is their problem. Tracestrack renders it. That’s good enough for me.
I’m not hating, or not seeing any good reason in Carto. They can have their own concerns and standard, while I’m not convinced by quite a few decisions or inactions. It simply doesn’t need to be the solution to everything. Indeed, Carto wants to be a feedback or reference. That’s fine.

12

Perhaps “competing” is a but strong. But the suggestion that “[or] they can only tag the area as landuse=education and place a node with amenity=school” is giving a different significance to amenity=school which would imply a change in rendering.

Absolutely! Carto is always going to be rather conservative, and other renderers are free to be more “avant garde” in their choice of tags to render.

13

It’s clearly an accepted proposal with a transition plan to move all amenity=school areas to landuse=education gradually as they are retouched.

1 Like
14

If you, @Kovoschiz and others are willing to chip in to the Carto ‘issue’ ticket - it’s here. It couldn’t hurt. (Though I accept no-one gets to tell volunteers what to do, this one feels like a ‘no-brainer’).

15

How to render landuse=education is an open ticket. What has been declined is simply to render landuse=education in the same way as amenity=school (see rejected PR). There’s no point in trying to relitigate that discussion.

A more viable route to rendering landuse=education is to develop POI-based rendering for amenity=school and amenity=kindergarten. Think of the current rendering of amenity=hospital (POIs appearing at zoom 15). Tracestack Topo has taken the POI route. If this were in place, there would be a clearer route to rendering landuse=education as a simple colour fill. This is a really old open issue. It is still open because nobody has done the work on a PR, but also because some voices were attached to the current “landuse style” rendering and didn’t like the “hospital-like” approach.