Taggen van scholen in NL naar aanleiding van nieuwe tag

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.

Het lijkt er op dat OSM steeds meer geacht wordt om zich aan allerlei OSM vreemde digitale externe databases aan te passen. Laten we het zo duidelijk mogelijk maken door de database aanhangers dan maar te vertellen om zich aan de reeds in OSM aanwezige data aan te passen. Daar wordt tenslotte al enige tijd aan een database, waar Carto een kaart van bouwt, gewerkt.
Om van allerlei vlugge gedigitaliseerde initiatieven maar niet te spreken. De kracht van OSM is tenslotte de lokale mapper die middels surveys in zijn eigen omgeving werkt.

Het lijkt me ook helemaal prima om er pragmatisch mee om te gaan. In een winkelstraat vol winkels is het niet handig om op vlak te taggen, dus pak je adresnodes (als die er zijn), en laat je grondgebruik over aan landuse=retail. Waar een vlak wel duidelijk is kan dat prima. Een adresnode is ook maar een virtueel ding.

Ik zie dat meer als een conventie om op adresnode te taggen waar vlakken weinig toegevoegde waarde hebben. Het is geen doel op zich (gezien de vele voorbeelden van tags waar juist het vlak de voorkeur geniet). Daarnaast blijft wereldwijd amenity=school gewoon op vlak gebruikt worden tenzij dit niet kan en een expliciete landuse=education handiger is, dus tools houden er toch rekening mee. Voor wie is het taggen van scholen met een eigen terrein op adresnode met een losse landuse=education dan een voordeel?

Maar waarom zou je een itnratuine als deze op een vlak taggen? Dan krijg je onnodig dubbeke adresnformatie.

Waarom zou je de adresinformatie dupliceren? Het terrein is altijd geografisch aan het vlak gelinkt. Kijk hier snap ik het nog. DIt terrein is zo groot.

Omdat de winkel naast een pand een buitenterrein met schuttingen en planten omvat

Staat gewoon in de wiki:
"Note: the shop outline can either be defined as just the main shop building (combined with building=) or the entire garden centre, including outdoor areas such as where plants are displayed for sale, car parks, and outdoor seating areas (combine with landuse=retail)."*

https://wiki.openstreetmap.org/wiki/Tag:shop%3Dgarden_centre

Persoonlijk vind ik de POI info op een node netter

Dan kunnen we net zo goed percelen importeren en alle POIs daarop taggen, maar ik ben het hier met Geim eens.