Ik analyseer de verschillen voor buildings in OSM en BAG. Daartoe neem ik bij inlezen in PostGIS met osm2pgsql de BAG id’s op met de style-import, regel:
node,way ref:bag text polygon
Dan komt in de tabel planet_osm_polygon een kolom ref:bag waarin soms BAG id’s staan. Samen met de NLExtract VIEW pandactueelbestaand kortweg pand, kan ik verschillen quantificeren (woonboten ‘houseboat’ even overslaan):
-- Wel in OSM, niet in BAG
SELECT osm."ref:bag"
FROM osmnl.planet_osm_polygon osm
WHERE osm."ref:bag" is not null AND osm.building != 'houseboat' AND NOT EXISTS (
SELECT
FROM bag.pand bag
WHERE bag.identificatie::bigint = osm."ref:bag"::bigint
);
-- Niet in OSM, wel in BAG
SELECT bag.identificatie
FROM bag.pand bag
WHERE NOT EXISTS (
SELECT
FROM osmnl.planet_osm_polygon osm
WHERE bag.identificatie::bigint = osm."ref:bag"::bigint
);
Dit levert interessante resultaten op: bijv Panden wel in OSM, niet in BAG zijn vaak afgebroken. Er kan op die plek een nieuw Pand staan met nieuw BAG id. Of Panden die weer uit BAG gehaald zijn als Stacaravans en Bunkers.
Omdat in OSM meestal de voorloopnullen van de BAG Id’s niet zijn opgenomen (eerdere versies NLExtract helaas) moet ik casten naar bigint. Helaas zijn er 120 records waar meerdere BAG id’s in ref:bag staan. Soms omdat een twee-onder-1-kap een enkele naam heeft als bijv Tesselschade Badlaan 4, Muiderberg. Soms met building=apartments en afzonderlijke BAG id’s in building:part: 396100000068044;396100000069422Diepenbrockstraat resp 2-16 en 18-32, Heemskerk.
Ik zou zeggen: laten we de BAG volgen, slechts 1 BAG id in ref:bag, liefst ook met voorloopnullen.
Als een building bestaande uit meerdere BAG Panden een enkele naam heeft, zie Tesselschade boven, is m.i. wel iets op te verzinnen. Maar vooral ook building:part maakt zaken gecompliceerd. Ik kan even niet terugvinden bijv in Wiki, of daar ooit besluiten over genomen zijn.
Deze meerde BAG-ids komen voor waar een pand in werkelijkheid maar één gebouw is, maar waar deze als meerdere panden in de BAG staat. Dat kan, soms verschillen de BAG en OSM van interpretatie, en OSM is immers geen kopie van de BAG. Omdat de gecombineerde outline wel uit de combinatie van geïmporteerde BAG-objecten bestaat, kan het wenselijk zijn om deze te behouden. In OSM doe je dat met de puntkomma ; als scheidingsteken.
Hetzelfde geldt voor building:part: soms zijn de BAG-objecten inderdaad een building:part en niet een building. Ik zie daar geen bezwaar in.
Je kan het beste je software daar op aanpassen. De notatie lijkt me verder gewoon valide. Hetzelfde geldt voor de voorloopnullen: daar moet je als data consumer mee om kunnen gaan. Een extra voorbewerkingsslag in jouw methodiek lost dat gewoon op.
Meestal zijn die wel oplosbaar zou ik denken.
Indien een garage onder een gebouw, gewoon als een apart object met layer=-1 en anders helpt een BAG terugmelding meestal wel, want de kans dat een gemeente vergeten is iets op te schonen is ook niet ondenkbaar.
Tot slot, als de gemeente met een verklaring komt of je lokaal weet hoe het in elkaar steekt kan ook een building:part nog uitkomst bieden.
De naam zou ook aan een relatie gehangen kunnen worden ipv op het gecombineerde pand.
Die way lijkt een copy/paste issue en die pumpputten zouden beter ref kunnen zijn ipv ref:bag.
Voorloopnullen komen er sinds enige tijd automatisch bij voor bestaande panden: een aanvullende plugin naast die van de BAG import herkent id’s zonder voorloopnullen en als een pand toch gemuteerd wordt vult ie ze vlak voor het uploaden automatisch aan tot 16 posities.
Maar dus alleen als een pand gemuteerd wordt, dus gaat langzaam eer heel Nederland is voorzien.
Heb een functie in postgres gemaakt die id’s die uit 13-15 nummers bestaat aanvult met nullen om gemakkelijker te kunnen vergelijken.
Blijven over plm 120 objecten met 2 of meer BAGid’s in ref:bag. Uiteraard kan ik daaromheen programmeren, alleen bevreemd het mij dat we gezamenlijk afspreken om de BAG stapsgewijs te importeren, en vooral ook te kunnen onderhouden, maar dan tegelijk BAG-conventies loslaten. Dat meerdere Panden zouden kunnen worden samengevoegd naar 1 gebouw is m.i. meer regel dan uitzondering: alle 2-onder-1-kap, zelfs rijtjes-woningen etc. Dat wordt ook in Top10NL en BGT gedaan. Mappers zouden nog veel meer kunnen gaan samenvoegen. Maar willen we dat? Ik heb altijd begrepen dat we de BAG imports onderhoudbaar willen houden. Niet als 3DShapes, eenmalig. In de BAG is nu eenmaal een model van Verblijfsobjecten en Panden meestal 1:1 soms meer-naar-een, soms zelfs 1 naar meer (bijv doorgebroken muren).
De (ontbrekende) voorloopnullen, mea culpa, ben ik zelf debet aan: in een vlaag van optimalisatie heb ik in een van de eerste versies van NLExtract de strings naar bigints omgezet om zo opslag te besparen en performance te bevorderen. Later tot inzicht gekomen, alleen toen (plm 2014) waren de eerste BAG imports al gedaan…
Als je je echt stoort aan de BAG-nummers in lijsten kun je die ook weghalen, maar dan verwijder je wel de informatie over de herkomst van het object. Er zijn soms gewoon valide redenen om BAG-objecten in OpenStreetMap samen te voegen. Soms is het dan logisch om de BAG-delen te laten bestaan als building:part en soms horen ze gewoon niet in OpenStreetMap. In dat laatste geval kan de lijst van BAG-codes op het gecombineerde object je aangeven dat ze wel geïmporteerd zijn, maar samengevoegd.
Programeertechnisch hoeft dit helemaal geen probleem te zijn trouwens: behandel ref:bag altijd als lijst (waar dan meestal maar één code in staat).
Bij BAG-objecten gaat het in 99.9% van de gevallen om outlines die overeen komen met wat we in OpenStreetMap willen hebben. Prima! De rest zijn uitzonderingen; maar vaak juist markante panden waar de BAG zich teveel beperkt tot de voetafdruk of andere BAG-beperkingen (denk ook aan mappers die bij hoogbouw de verschillende delen een height geven), of om panden die in OpenStreetMap-definities gewoon één pand zijn, en één identiteit hebben (een naam bijvoorbeeld). Voor die uitzonderingen moet ruimte zijn (nog los van het feit dat building objecten ook wel eens niet in de BAG staan, maar wel op OpenStreetMap).
Voor rijtjeshuizen en twee-onder-een-kap-woningen gaat dit meestal niet op (hoewel er vast interessante uitzonderingen zijn), want die hebben doorgaans een eigen identiteit en, niet onbelangrijk, worden apart onderhouden. Bij flats is dat al snel niet het geval (er is op zijn minst een VVE), en daar is het ook niet raar dat ze (ook in de BAG) als één object er in staan.
De keuze om de voorloopnullen weg te laten was destijds een bewuste. De gedacht was dat je toch nooit kunt garanderen dat iedereen de juiste voorloopnullen toe voegt. Door de voorloopnullen weg te laten stimuleer je een applicatie om hier rekening mee te houden en er niet klakkeloos vanuit te gaan dat er altijd de juiste voorloopnullen staan. Nu blijk dat bijvoorbeeld de BAG Viewer altijd de voorloop nullen verwacht was die keuze misschien minder handig, maar we gaan ook niet overal een spatie in de postcode zetten omdat er systemen zij die dat verwachten. Dit staat los van NLExtract, want dat is nooit gebruikt voor de BAG import.
Een voorbeeld van de ‘noodzaak’ van building:part zijn de panden met werfkelders in Utrecht. Het BAG pand loopt onder de weg door en is getand met layer=-1. Het bovengrondse deel is getagd met ‘building:part’. Hierdoor blijft de geometrie aansluiten bij het object met de ref:bag tag en geven de controle tools geen foutmeldingen over afwijkende geometrieen.
Omgekeerd kan ook voorkomen, als een deel van het pand de BAG geometrie heeft. Vaak heeft dat te maken met 3D tagging. Kijk maar eens naar het pand van de Rabobank, of de Domtoren in Utrecht. Vlak naast de Domtoren heb ik building:part gebruikt op het ondergrondse museum om te voorkomen dat het als bovengronds gebouw word gerenderd. Dat is inderdaad taggen voor de renderer maar voorkomt ook een mapping strijd tussen de ene mapper die de building tag verwijderd omdat er geen bovengronds gebouw is en de ander die hem weer toe voegt omdat er een BAG pand ontbreekt.
De pompputten kan je volgens mij gewoon corrigeren. Daar wordt ref:bag gebruikt voor iets waar deze niet voor bedoeld is. Dat zou ref of alt_name kunnen worden. Waterdicht krijg je het nooit, hoe veel afspraken je ook maakt of vast legt.
