Taggen van scholen in NL naar aanleiding van nieuwe tag

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.

De managers van Carto hebben al aangegeven dat Carto hun project is en niet een renderer van, voor en door de community. Daar kunnen we onszelf niet van afhankelijk laten zijn.

Naar mijn idee kunnen we net als de meeste andere andere POIs de scholen op de adresnodes zetten, onafhankelijk van het aantal scholen op een terrein, aangezien we nu een goed alternatief hebben voor het taggen van schoolterreinen.

Met welk doel? De meeste scholen hoef je helemaal niet expliciet met landuse=education te taggen, omdat die al in amenity=school zit ingebakken. Gewoon op de outline van het vlak en klaar.

Massaal omtaggen moet wel een duidelijk voordeel hebben. Dat zie ik hier niet. Er blijven immers altijd features die je doorgaans op een vlak tagt (hoger onderwijs, ziekenhuizen, zorginstellingen, pretparken), net als dat er features zijn die je meestal op een adresnode houdt (winkels bijvoorbeeld). Streven naar een kaart van Nederland waar elke POI op een node staat lijkt me geen haalbaar of wenselijk doel. Daarnaast blijft het taggen van amenity=school op vlak gewoon toegestaan in OSM (het maakt ook deel uit van hoe landuse=education is bedacht). Waarom zou je dan in Nederland daar een uitzondering voor maken? Welk probleem los je op?

Een nadeel is er wel: je ontkoppelt terrein van feature. Bij een terrein met meerdere scholen is dat al jammer, maar vaak krijgt het terrein dan ook een eigen identiteit (zoals bij MFC De Akkers hierboven). Bij een school op een eigen terrein is die splitsing er niet.

Je kunt het ook omdraaien. In NL is de afspaak een POI zoveel mogelijk op de adresnode te taggen. Waarom zou je daar hier van afwijken bij scholen? Zo heb je 1 adres in de database staan met daarop de info van de school. Bij rivieren taggen we de naam ook op de lijn en niet op het vlak. Mocht je bijbehorende vlakken willen hebben dan selecteer je alle lijnen van een rivier en voer je een geografische intersect uit. Zelfde kan ook bij scholen en hun schoolterreinen. Een schoolterrein is dus altijd geografisch aan een adres gekoppeld.

Bij grote universiteitsterreinen bijvoorbeeld kun je een name op het vlak zetten, net als bij bepaalde industrieterreinen van bedrijven word gedaan.

Niet alleen scholen. Naast een aantal die hierboven genoemd zijn ook campings, viskwekerijen en bijvoorbeeld een vestiging van Intratuin met een groot buitenterrein.

Ik was al een poos aan het worstelen met zoveel mogelijk op POI taggen versus “one feature, one element”.

Deze hele discussie heeft ervoor gezorgd dat ik in het vervolg een stuk pragmatischer met een aantal zaken om kan gaan.