We laten de overheid voor het grootste deel het moeilijke werk voor ons doen: het landmeten en karteren gebaseerd op luchtfoto’s van veel hogere kwaliteit dan de 25cm/pixel foto’s die ons ter beschikking staan. Dat is waar de hele BAG import eigenlijk op neer komt. Tegelijkertijd leveren wij ook weer terug aan de overheid in de vorm van terugmeldingen, en zo is het eigenlijk gunstig voor beide partijen.
Uiteindelijk is OSM leidend, en er zijn best gevallen waar we ook bewust van de BAG afwijken. Een goed voorbeeld daar van is dat we niet lukraak alle panden in de BAG met de status ‘Bouw gestart’ importeren, maar wachten tot een mapper heeft gecontroleerd dat er ook daadwerkelijk is gestart met bouwen, wat lang niet altijd het geval is. Andere voorbeelden zijn bijvoorbeeld bijzondere gevallen van rare administratieve deadlocks in de BAG die voor de BAG technisch wel correct zijn maar de realiteit niet weerspiegelen, of complexe gebouwen waar de BAG definitie van een ‘pand’ afwijkt van wat wenselijk is om als building=* geometrie in OSM te hebben.
De werkwijze die ik mijn vorige post beschreef - dat is: fout constateren, terugmelden, importeren - is gebruikelijk omdat dit normaliter een relatief snelle en vooral nauwkeurige manier is van zulke fouten corrigeren, die als bijkomend voordeel het risico op perongeluk weer de fout terug-importeren minimaliseert.
Echter als het verwerken van zo’n terugmelding veels te lang duurt zou je ook best OSM alvast aan kunnen passen met een nieuwe geometrie, die later evt. weer gecorrigeerd kan worden met de nieuwe BAG geometrie als die BAG geometrie nauwkeuriger is (wat vrijwel altijd het geval is, tenzij je als mapper zelf bent wezen landmeten natuurlijk ;))
Een schoolgebouw dat onderling geheel verbonden is, is één enkel pand, en dat krijgt inderdaad één BAG pand id. De BAG kent natuurlijk alleen panden, geen ‘school’ of ‘gymlokaal’, en ook geen verdiepingen. Zulke extra informatie hangen we dus in OSM er zelf bij aan.
Een schoolgebouw dat onderling geheel is verbonden is in OSM gebruikelijk ook één enkel building=school, dus daar ligt geen conflict naar mijn inzien.
Verdiepingen en sub-delen van panden kan je taggen d.m.v. o.a. het Simple 3D Buildings tagging scheme (https://wiki.openstreetmap.org/wiki/Simple_3D_buildings).
Voor verdiepingen staat dit uitgebreid beschreven in https://wiki.openstreetmap.org/wiki/Simple_3D_buildings#Height_and_levels.
Een gymlokaal zou je dan kunnen taggen door een nieuwe closed way (polygon) te tekenen die aansluit op de building=school, en die te taggen als:
building:part=yes
leisure=sports_hall
Zoals ook beschreven staat op de wiki pagina van leisure=sports_hall (https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dsports_hall)
Wat ook belangrijk is om te benoemen denk ik is dat er veel objecten zijn in Nederland die wel in de definitie OSM ‘building’ passen, maar volgens de BAG geen echt ‘pand’ zijn, en dus niet in de BAG staan. Dan moet je vooral denken aan schuurtjes die niet stevig verankerd zijn in de grond, voorheen mega grote kapschuren (definities aangepast in BAG 2.0), overkappingen, carports, gebouwen die niet afsluitbaar zijn, enz.
Deze objecten worden meestal zelfstandig ingetekend in OSM, of er wordt gebruik gemaakt van de BGT (al dan niet als rasterkaart om over te tekenen) als ad-hoc bron voor de geometrie. Veel van de objecten uit deze klasse staan wel in de BGT maar niet in de BAG.
