Taggen van scholen in NL naar aanleiding van nieuwe tag

Interessante uitwisseling. Ik ben in mijn cartografenbestaan al aardig wat scholen tegengekomen, waar ik meestal maar voort heb geborduurd op ‘wat er was’.

Waar ligt de grens van het landgebruik? Ik heb mijzelf er nog niet echt op toegelegd dit tot in details uit te zoeken. Is dat aan de rand van de weg? Is een plantsoen ‘woongebied’? Ongetwijfeld vragen die ik op de wiki zal terugvinden.

Gisteren trof ik dit schoolterrein, dat nu nog in ‘woongebied’ ligt. Twee basisscholen in één. Waar trek je de grens? Mijn gedachte zou zijn: bij de hekken die meestal het schoolterrein omsluiten, en anders de kadastrale grens.
https://www.openstreetmap.org/?mlat=52.70010&mlon=5.24060#map=19/52.70010/5.24060

Ik heb er zelf een keer voor gekozen om er twee vlakken van te maken. Dus elke school zijn eigen landgebruikvlak. Dat zou dus nu 2x educatief landgebruik zijn.
https://www.openstreetmap.org/?mlat=52.68943&mlon=5.23768#map=18/52.68943/5.23768

In hoeverre zou dat een mogelijkheid kunnen zijn?

Dit is een lastige. Waar trek je de grens. In dit voorbeeld is er geen fysieke afscheiding op het terrein zoals een hek waar je de grens van je landgebruik op kunt baseren. Zo ken ik er nog wel een paar die een gedeeld schoolplein hebben. Die zou ik persoonlijk als 1 groot vlak landuse=education tekenen met de scholen op de nodes. Dus zoals het voorbeeld van Jeroen van MFC de Akkers.

Je kan naast landuse=education ook even een fixme toevoegen:


fixme=Remove amenity=school when landuse=education is rendered.

En voor bijna alle schoolterreinen in Nederland geldt:


smoking=no

Dat hangt van je gekozen detailniveau af. Als het heel fijnmazig doet kun je het per huizenblok intekenen en de wegen/straten vrijlaten. Als je iets grover werkt, dan splits je enkel tussen de highway=secondary (of tertiary) en hoger, en andere grote barrières zoals spoor en kanalen. Een groot park of een hogeschoolcampus leg je al snel vrij van landuse=residential, maar amenity=school niet altijd; dat volgt uit het gekozen detailniveau.

Op luchtfoto’s is niet direct een grens tussen de twee scholen te zien. Is die er effectief wel? Delen ze die speelplaats in het midden? Anders zou daar inderdaad ook één terrein met landuse=education van gemaakt kunnen worden, met de schoolamenities op de eigen gebouwen, maar deze twee scholen lijken wel enigszins ‘tegen elkaar aan’ te liggen, dus de huidige tagging is ook niet verkeerd denk ik. Anders is het als die twee scholen samen onder één naam dat terrein gebruiken.

Hier in Leeuwarden is ook een situatie met drie scholen waarvan de terreinen tegen elkaar aan liggen (en die je dus elk zijn eigen terrein kan geven met amenity=school), maar daar zit wel een duidelijke barrière tussen.

Persoonlijk vind ik scholen wel een dergelijke wijkfunctie hebben dat ze een grotere vermelding op de kaart verdienen, vergelijkbaar met winkelcentra. Maar ik zie inderdaad het bezwaar m.b.t. scheiding binnen een gebouw en gedeelde schoolpleinen.

Ik heb het nu in Bovenkarspel als volgt opgelost: schoolterrein als ‘landuse=education’ en ‘amenity=school’ (i.c.m. fixme=*), zonder naam op het gebied en de schoolinformatie (naam, webstek, telefoon e.d.) op de adrespunten. Bij het schoolterrein heb ik gerekend de fietsenrekken en een deel van het groen dat als scheiding met de openbare ruimte dient.

Dat is ook mijn oplossing in Rijswijk waar twee scholen een schoolterrein delen maar waar de grens niet duidelijk is.

Vraagje: is toevoeging van landuse=education voor Nederland te automatiseren?

Het is heel makkelijk om alle vlakken met amenity=school/university/… in Nederland op te zoeken met Overpass Turbo, dan in JOSM te openen en er landuse=education aan toe te voegen. Leuk idee voor de transitieperiode. Een actie als deze moet wel voldoen aan de “automated edits code of conduct” (zie wiki), waar nogal wat haken en ogen aan zitten, zoals de eis van een brede consensus.

Nee niet echt. Je kan wel zoeken op amenity=school-vlakken waarin meerdere educatieve amenities zitten (en waar de buiten-‘school’ dus bedoeld kan zijn als verzamelterrein), maar bij alle scholen die ik tot nu toe door de handen heb gehad waar dit het geval is, is er altijd wel maatwerk nodig. Soms ontbreken er scholen en vaak loopt de informatie achter.

Je kan wel makkelijk in JOSM op zoek naar lege ‘spookscholen’ met deze query in een gebied:

[out:xml][timeout:90][bbox:{{bbox}}];
(
  way["amenity"="school"][!name];
);
(._;>;);
out meta;

Het grootste deel daarvan zijn één-school-één-terrein gevallen waar het terrein ingetekend is zonder de data erop, en waarin een dubbele amenity=school als node of op de way van het gebouw zit, of helemaal geen amenity erin maar de naam wel op het gebouw. Die kun je makkelijk aanpakken door alle informatie naar het terreinvlak te verhuizen. Kijk dan ook even of website=* nog klopt, en of de school nog bestaat of nog zo heet. Bij deze gevallen is landuse=education overbodig.

De website-URL is heel fijn als een mapper in de toekomst de data naloopt. Vaak wijst een oude URL van een school nog een tijdlang door naar de nieuwe als deze van naam wijzigt of fuseert.

Tip: zet in JOSM de Zwart/wit-kaart als onderlaag aan op een doorzichtigheid van zo’n 30–40%:

Meestal bewerk ik de scholen dan in een nieuwe laag waarin ik alles vlak om de school heen download. Die laag kun je dan na het uploaden weer wegdoen; zo houdt je de ‘zoeklaag’ schoon en overzichtelijk.

Dat is zeker niet in overeenstemming met de richtlijnen. Door dat te doen voeg je een tag toe die al door die amenities geïmpliceerd wordt. Het is net alsof je foot=yes op alle highway=footway zet waar geen andere access-tags op zitten; je voegt effectief geen informatie toe. Dat kan ook nadelig uitpakken bij het pleiten voor renderondersteuning voor de tag, want de Carto-maintainers zien dan ook in een keer de hoeveelheid landuse=education stijgen op een verdachte manier.

Wat je wil is organische groei van de tag, dus begin bij de echte use-case van landuse=education: de IKC’s, MFC’s, en Brede Scholen waar meerdere scholen (en kinderopvang) een schoolterrein delen. Met bovenstaande query loop je die ook tegen het lijf:

Wat is de status op dit moment? De laatste post was van meer dan een jaar geleden en met overpass heb ik gezocht naar scholen op een way waarbij de landuse=education niet is gebruikt.
(amenity=school; op een node heeft dit voorstel geen zin omdat landuse op een node ook geen zin heeft)
Ik kom dan 4485 scholen tegen.

[out:json];
{{geocodeArea:Nederland}}->.searchArea;
(
  way["amenity"="school"][!landuse](area.searchArea);
);
out body;
>;
out skel qt;

Als ik zoek op scholen (als way) waarbij wél die landuse=education is gebruikt, kom ik er 273 tegen.

[out:json];
{{geocodeArea:Nederland}}->.searchArea;
(
  way["amenity"="school”][“landuse”=“education”](area.searchArea);
);
out body;
>;
out skel qt;

Overtuigend vind ik dat nog niet, terwijl ik de gedachte achter deze tagging zeker ondersteun.
Waar is het blijven liggen?

Het idee was om landuse=education toe te voegen aan ways met amenity=school om draagvlak te creëren voor het geel renderen van die landuse=education. Eenmaal geïmplementeerd zou dan de amenity=school verwijderd kunnen worden zodat die laatste alleen nog op de adresnode overblijft

Wijzigingsverzoeken bij Gravitystorms Carto Github werden een aantal malen afgeschoten door gebrek aan draagvlak voor die tag (het bekende kip-ei verhaal).

In maart dit jaar was er daadwerkelijk een codewijziging in een pull-request gezet om dit te realiseren maar door een niet nader te duiden bug (buiten de PR) ligt dit sindsdien stil.

Waar ikzelf amenity=school op een polygoon zie in combinatie met dezelfde tag op een adresnode vervang ik amenity=school door landuse=education maar dit werd door verschillende users vaak weer teruggezet.

Wat mij betreft gaan we het hele handeltje consistent omtaggen conform het oorspronkelijke voorstel voor landuse=education.

Dan neem ik Gelderland Noord (Gelderse Vallei en Veluwe) wel voor mijn rekening

Tot nu toe heb ik het alleen meegenomen als er toevallig een school in het bewerkgebied lag.
Heb het ook toegevoegd aan de validatorregeltjes, hoewel ik niet weet door hoeveel die gebruikt worden
https://github.com/Famlam/OsmMapcssValidationNL/commit/3c027044050f419b6d26905bdc1beb260d1a5514

Het ligt niet stil vanwege die renderbug; die is niet relevant voor die PR (zoals ik daar aangeef). Het ligt stil omdat de maintainers van Carto de tag niet wensen te ondersteunen (zie https://github.com/gravitystorm/openstreetmap-carto/pull/4524)), omdat ze zogenaamd bang zijn dat de tag verkeerd gebruikt gaat worden. Net als highway=busway trouwens. Je kan energie steken in het uitleggen waarom de vage tegenargumenten die daar opgevoerd worden niet kloppen, maar dat is doorgaans zonde van je tijd.

Ondertussen wordt zo’n beetje elke andere tag die Carto wel rendert net zo goed misbruikt natuurlijk (de reden dat landuse=education bestaat heeft ook te maken met het misbruik van amenity=school voor gedeelde schoolterreinen immers), maar wordt zoiets ook goed in de hand gehouden door de mapper-gemeenschap. Het is dus eigenlijk alleen een handig argument om tags die je zelf als Carto-maintainer niet leuk vindt te blokkeren in de renderaar van de standaardlaag.

Dan heb ik het net niet goed begrepen.

Anyway, gezien de conventies (in Nederland) ben ik van mening dat dit ons niet moet tegenhouden om alle ways met amenity=school om te taggen naar landuse=education(en de amenity=school en aanverwante tags op de adresnode te zetten).

Ik wilde dit eigenlijk al langere tijd grondig aanpakken

Geheel mee eens.

Maar dat klopt ook niet. De landuse=education tag is al geïmpliceerd door amenity=school, dat maakte expliciet deel uit van het voorstel. Je kan hem gerust er extra aan toevoegen, maar het is niet nodig. Als een school een eigen schoolterrein heeft en die niet deelt (of overduidelijk hoofdgebruiker is), dan hoort amenity=school gewoon op het vlak; net als bij een universiteit, hogeschool, ziekenhuis, of amenity=social_facility. Het doel van landuse=eductation is niet om amenity=school van vlakken te verdringen als de outlines overeenkomen, maar om een mogelijkheid te hebben om meerdere scholen op een enkel terrein te hebben. Bij zo’n situatie kunnen die scholen op de adresnodes, maar ook op de gebouwen als die gescheiden zijn, of anderzijds verdeeld met vlakken.

Als ik dat zo lees en begrijp, dan lijkt mij dat het hertaggen zoals dit:

voorlopig nog een brug te ver is!
De consenus over deze situatie is volgens mij nog niet bereikt (hoeveel mensen zijn daar trouwens voor nodig? Aan deze discussie doen 7 mensen mee die het nog niet helemaal met elkaar eens zijn).

Als ik de wiki goed lees zie ik staan:

en ook:

Daar staat dan weer:

Dat leg ik als volgt uit:

  • Het gebied waar de schoolgebouwen op staan (los van het feit dat er mogelijke meerdere instituten op het gebied van onderwijs staan, maar dat hoeft dus niet, het geldt ook voor één school), wordt getagd met landuse=education

  • Het gebouw wordt getagd met amenity=school (of een van de andere onderwijsgerelateerde waarden)

In landen waar de adresnode prominent is (zoals in ons land), kan die amenity=school op de adresnode worden gezet.

Daarmee in overeenstemming heb ik dit gedaan:
https://www.openstreetmap.org/way/294472686
https://www.openstreetmap.org/node/2772343475

Maar als ik Jeroen Hoek volg is dat dus eigenlijk helemaal niet nodig, want met amenity=school (zonder landuse=education) is ook alle informatie beschikbaar. Pas als er meerdere - verschillende - instituten op een terrein staan heeft dat nut, omdat je anders de foutmelding krijgt amenity binnen amenity.
Maar dan krijg je dus de situatie dat er twee manieren zijn om een schoolgebied te taggen en dat geeft al snel aanleiding tot heel veel verkeerde manieren. Vooral omdat de wiki over landuse=education het niet zo uitlegt.
(zoals ook de halve wereld met natural=wood is bedekt terwijl dat eigenlijk landuse=forest moet zijn)

Dat landuse=education (nog) niet wordt gerenderd moeten we ons niet aan storen, als je op Carto moet wachten ben je al gauw 10 jaar verder.

Volgens mij moeten we er nog eens goed over nadenken…

In plaats hiervan kunnen we een operator=* tag toevoegen aan de landuse=education, met de naam van de school erbij.

Ik zie er geen heil in om te kijken naar het aantal scholen bij elkaar om te bepalen of de landuse tag van toepassing is. We kunnen beter consistent blijven in de manier waarop we mappen.

Je hele post verwoordt precies waar ik dus ook tegen aanloop.

Punt is dat ik in de praktijk behoorlijk vaak zie dat alle tags met betrekking tot één enkele school op de adresnode zijn getagged en dat vervolgens enkel de tag “amenity=school” óók nog eens op het perceel waar de school zich bevindt gezet wordt wat bij mij de validatiewaarschuwing “amenity binnen amenity” oplevert.

Zo’n situatie is voor mij “tagging voor de renderer” én niet conform “one feature, one element” waardoor het voor mij volstrekt logisch is om dan op het perceel enkel "landuse=education te zetten.

Hieruit voortvloeiend is in mijn hoofd het woordje “meerdere” uit het oorspronkelijke voorstel en de wiki landuse=education weggevallen en die laatste pagina bevat niet duidelijk “meerdere scholen op één perceel” in de introductie

Feitelijk zal ik volgens Jeroen Hoek in een dergelijke situatie dus de (tags van de) adresnode moeten samenvoegen met het perceel.

Ik zal de wiki eens nalopen. Niet alles is even duidelijk omschreven inderdaad. Het voorstel zelf was iets duidelijker geloof ik. De infoboxes van de verschillende educatieve amenities zijn wel bij (kopje ‘implies’).

Omdat we in Nederland adressen importeren uit de BAG als nodes hebben we daar een pragmatische uitzondering op. Adressen kunnen gewoon als node blijven bestaan. Als je ze verwijdert omdat ze al op een vlak staan wordt die namelijk toch wel weer semi-automatisch geïmporteerd. Op het vlak zet je dan bij de amenity=school (of andere feature) ook het adres, maar zonder de BAG-tags. Dat levert dubbele adressen op, maar dat is niet heel erg, en hoe dan ook kan een adres al meer dan eens voorkomen wanneer je meerdere bedrijven/winkels/dingen op één adres hebt. Adressen zijn dus niet per se uniek in de OSM-database.

Bij grotere objecten is dat hoe dan ook handig, en soms wijkt het adres ook af van wat er in de BAG staat (met name bij gecombineerde adressen), zoals bij deze hogeschool. Bij zulke objecten voer ik altijd de contactgegevens in die ze zelf hanteren en waarmee iedereen werkt.

Het helpt als je amenity=school (en andere educatie-amenities) op een vlak gewoon ziet als een impliciete landuse=education. Dat is ook op de wiki gedocumenteerd in de infoboxes onder het kopjes ‘implies’. Een expliciete landuse=education is dus alleen nodig als je met de amenity niet uitkomt. Dat kan zijn omdat je niet weet wat voor educatieve instelling ergens zit (niet echt iets wat in Nederland voor komt), of omdat er meerdere bij elkaar een terrein delen.

Dit is een mooi voorbeeld: één terrein met een eigen naam en identiteit, en twee basisscholen en een kinderdagopvang die daar in zitten.

Het leeuwendeel van de basisscholen heeft één terrein met één school erop. Het idee achter landuse=education is juist dat je dan niets extra hoeft te doen; gewoon één amenity=school op het terrein. (Eventueel nog building=school op het pand.) Dat voorkomt dat er een noodzaak is tot massaal omtaggen voor dezelfde informatie.

Die waarschuwing is terecht. Één uitzondering is dat als deel van het landuse=education-voorstel is geopperd om tijdelijk amenity=school erbij te zetten om scholen niet gelijk van de standaardlaag te laten verdwijnen. Dat was bedoeld als migratiemaatregel om critici tegemoet te komen. Achteraf was dat misschien niet de beste oplossing. Rekening houden met Carto is wellicht niet meer reëel. (Ik heb ook geen idee wat dan wel een goede manier is.)

Bij normaal (één-school-één-terrein) gebruik hoort de info inderdaad niet op de adresnode te staan en juist enkel op het vlak. De meerscholen-op-een-terrein-situatie is heeft idealiter ook geen amenity=school op het buitenste vlak, maar heeft dat nu soms wel vanwege die tijdelijke bedoelde migratiemaatregel.