De BAGeraars verzetten bergen voor OSM NL. Vergelijk eens met de situatie in Duitsland, waar gebouwen meestal van luchtfoto’s nagetekend worden…
Maar toch ben ik een probleempje tegengekomen, toevallig. Meer dan duizend gebouwen, over heel Nederland verspreid, hebben nog een overtollig construction-tag staan alhoewel ze als gereed gemarkeerd zijn (building != construction). Hier twee willekeurige voorbeelden: https://www.openstreetmap.org/way/680114869 https://www.openstreetmap.org/way/548954842
Ik ben nog wat meer gevallen nagelopen, natuurlijk niet alle 1.673. Iedere keer gebeurde het in twee stappen:
Gebouw wordt correct geïmporteerd tijdens de bouwwerkzaamheden: building=construction, construction=house, yes, whatever…
Later is het gebouw gereed. Misschien met gewijzigde geometrie, misschien niet, in ieder geval wordt het building-tag correct omgezet naar house, yes, whatever. Soms gebeurt dit handmatig, soms via het BAG-import-plugin (?). Op dit moment hoort ook het construction-tag verwijdert te worden. Dat gebeurt wel eens, soms niet. En als het niet gebeurt, gaat het dus mis.
Op dit moment zijn er 1.673 gebouwen over heel Nederland verspreid met een overtollig geworden construction-tag (way[building][construction][building!=construction]): http://overpass-turbo.eu/s/YtR
Ik stel voor dat wij dit met een mechanische edit gaan repareren: construction-tag weghalen. Natuurlijk vergt dit de nodige zorgvuldigheid en discussie. Laten wij het later daarover hebben. Zouden jullie me eerst laten weten of dat überhaupt een goed idee is? Ik vind van wel: die tags waren correct tijdens de werkzaamheden, dus nu niet meer. Ik weet niet of zij ooit voor een verkeerde interpretatie van de data zorgen. In ieder geval zijn ze nu verkeerd. Weg ermee.
Mijn tweede voorstel is dat wij toekomstige gevallen voorkomen, misschien door een update van het BAG-import-plugin. Ik heb geen idee hoe dat plugin in elkaar zit. Ik kan me niet voorstellen dat dit heel ingewikkeld zou zijn. Pseudo-code:
building_new_value = getFromBag();
if (building == construction) & (building_new_value != construction):
construction = ""; # delete tag;
building = building_new_value;
Bij de update van de geometrie import je het pand of teken je deze over.
De update voer je uit door de oude en nieuwe geometrie te vervangen door deze beide te selecteren en het commando “Replace geometry” (Ctrl+Shift+G) uit te voeren.
Hierbij worden tags van biede polygonen gecombineerd. Je krijgt de keuze welke je wilt houden, maar je vergeet al snel de de tag construction op none gezet moet worden.
Dat soort gevallen moet handmatig opgepakt worden. Passende Overpass query: http://overpass-turbo.eu/s/YvU
Over heel Nederland zijn dit 675 van de 1673 gevallen…
JOSM waarschuwt sinds kort (had het tenminste nog niet eerder gezien) ook als een als een building niet meer op consruction staat en er ook nog een construction tag aanwezig is, dus het zou door de BAG importeurs niet meer voor moeten komen in de toekomst (bij enkele steekproeven zie ik onze namen erbij staan).
Geen idee of de iD editor er ook op let, want andere mappers veroorzaken dit ook regelmatig. Ook dat iemand een building tag op een adresnode erbij zet komt voor. Dit wordt door JOSM hier al veel langer op gevalideerd.
Kom er af en toe zo een tegen en die pas je dan aan.
Dacht ik ook. Met die gevallen ga ik handmatig aan de slag, zeker in mijn buurt (Groningen). Zou iemand mee willen doen? 600+ huizen handmatig nalopen is geen klein klusje.
Ik heb nog niks gehoord over de voorgestelde automated edit. Wat denken jullie hierover? Daar gaat het dus over de 1.000 “makkelijke gevallen” waar construction duidelijk overbodig is.
Gelderland is alvast bijgewerkt, met uitzondering van ‘verdachte gevallen’ en panden die pas in 2020 zijn opgeleverd. Ik denk overigens wel dat het zin heeft om alle gevallen afzonderlijk te bekijken.
Voor de BAG plugins hebben we een verschillen WMS die ook aangeeft of de status constructie er inmiddels af kan. Wanneer we die zien nemen we die ook mee en kunnen we, indien ingemeten, gelijk de actuele contouren meenemen.
Nog 36.000 te gaan waar de status niet meer op constructie hoort te staan
1 van mijn foute tikken is dat ik de construction gebouwen in ‘mijn’ buurt in de gaten hou en op ‘gereed’ zet in OSM als het zover is.
Hier laat ik zien hoe ik construction overduidelijk kan zien op phone: https://forum.openstreetmap.org/viewtopic.php?id=62191
Wat er nu nog staat (107 waarvan een in de overzeese gebieden) moet wachten totdat iemand over meer informatie beschikt: https://overpass-turbo.eu/s/YN0
p.s.: het script is een vereenvoudigde versie van het script dat smootheFiets had gebruikt.
Sinds ik hierop let kom ik wel vaak gebouwen tegen die met verouderde gegevens op OSM staan. Ze zijn
gesloopt of nooit gerealiseerd
van geometrie gewijzigd
opgeleverd maar staan nog op construction.
Vooral bijgebouwtjes van boerderijen en industrie hebben een heel korte gebruiksduur, blijkbaar.
De eerste twee herken ik met het blote oog (BGT-layer aan, verschillen tussen Carto en BGT vallen dan wel op. Als er een verschil is, OSM-data downloaden, BAG-link openen ter bevestiging). De derde is lastiger.
Flink wat panden heb ik zelf gewijzigd of her-import van de BAG aangevraagd.
Maaaarrrr… dat is toch allemaal bot-werk. Computer’s zijn heel goed in dat soort dingen, beter dan mensen. Hebben wij dat ooit overwogen, een soort BAG-onderhouds-bot? Wij moeten natuurlijk niet zo snel willen dat zo’n bot echte edit’s uitvoert. Maar als hij verdachte gevallen opspoort die wij dan handmatig kunnen nalopen, dat zou echt handig zijn.
Ik dacht erom om elke BAG-import elke maand (willekeurig gekozen; dagelijks lijdt tot server-overlast, jaarlijks vind ik te grof) in de BAG op te zoeken. En gevallen flaggen waar
BAG meldt “pand gesloopt” of “pand niet gerealiseerd” - die kunnen worden verwijdert, inclusief eventuele adres-node’s, behalve als ze op luchtfoto’s nog lijken te bestaan.
building=proposed/construction, maar opgeleverd volgens de BAG: tags building/construction/proposed/source:date wijzigen.
geometrieverschil tussen BAG en OSM: opnieuw importeren.
Misschien ben ik iets vergeten.
Ik weet niet of ik dat zelf zou kunnen programmeren. Maar het lijkt me geen heel ingewikkelde klus.
Verschillen kunnen de BAG importeurs vrij gemakkelijk zien met de BAG WMS layers die doorgaans een paar minuten achter lopen op OSM en en het verschil laat zien met een maandelijkse BAG dump.
Wat zien we dan zoal? Een algemeen overzicht die per plaats aangeeft of er veel of weinig achter loopt:
En als je wat verder inzoomed wordt op object niveau aangegeven wat de issues zijn:
Hier als voorbeeld een stukje uit Amsterdam waar de meeste statussen wel in te zien zijn. Alleen bouw gestart en sloopvergunning ontbreekt in dit plaatje.
Wat mij betreft stellen we deze layers aan meer personen beschikbaar dan alleen binnen het BAG team. Maar het risico daarin bestaat dat het BAG verzoeken topic vol stroomt met duizenden verzoeken van iedereen die deze plaatjes zit over te kloppen. Als je dat van plan bent kun je je beter aanmelden bij het BAG team, dan kun je met de BAG plugin deze mutaties zelf uitvoeren
En nee, het maken van deze layers was nog best een hoop werk, maar draait nu al een aantal jaar stabiel.
Een beetje uit mijn ervaring, aangezien ik eerst ook dacht dat onderhoud geautomatiseerd kon worden:
Het grootste deel van de gebouwen stamt waarschijnlijk uit 2014, de eerste import.
Na die tijd zijn de gebouwen ingemeten en de geometrie aangepast.
Het aanpassen in OSM is een flink stuk handwerk. Losse gebouwen is gemakkelijk, maar vaak delen ze nodes met andere gebouwen die dus samengevoegd moeten worden. Ook is er slordig tekenwerk waarbij je kleine overlappingen moet wegwerken.
Een gesloopt gebouw kan ook een samenvoeging zijn van een gebouw met een ander gebouw. Er blijft een gebouw bestaan op die plek, alleen als onderdeel van een ander gebouw.
Een ontbrekend gebouw met een oude bouwdatum is waarschijnlijk een splitsing van een gebouw in 2 gebouwen. Bv. omdat het niet een huis is met een aangebouwde garage, maar een huis met een losse garage en een stoep ertussen.
De bijgebouwen zag je ooit massaal verdwijnen, maar zijn nu in een flink aantal gemeentes weer terug aan het komen.
Een ontbrekend adres lijkt gemakkelijk toe te voegen met en bot, maar soms staat het adres al in osm met een ontbrekende of foute postcode. Dat moet dan aangepast worden.
Daarnaast bevat de BAG ook fouten. In een provincie zijn er al snel honderden gebouwen dubbel ingevoerd door menselijke/procedure/software fouten. Het goede nieuws is dat gemelde fouten (via een BAG terugmelding) bij veel gemeentes snel opgelost worden.
Helaas is het dus geen ‘bot-onderhoudwerk’ op dit moment en lijken mij extra handjes welkom.
Daarbij komt nog iets belangrijks.
Zoals JanWandelaar al zei, is de discussie binnen de gemeentes nog steeds gaande over de bijgebouwen.
Voorbeeld:
Een schuur/garage kan afgelosten worden, en hoort daarom volgens de BAG regels in de BAG.
Een tuinhuisje kan een open gebouwtje zijn die niet is af te sluiten en daarom mag deze volgens de regels niet in de BAG bij de gemeentes.
Je ziet regelmatig dat ineens heel veel bijgebouwtjes worden opgevoerd door gemeentes, welke worden aangeleverd naar het Kadaster, deze zien we dan als “nieuwe” gebouwen in de layers van SanderH verschijnen.
Maar andersom is veel vervelender, een gemeente besluit (om welke reden dan ook) gebouwen uit de BAG te verwijderen.
Deze gebouwen poppen dan in de Layer van SanderH als rood, als zijnde gesloopt.
Maar wat als er geen sloopvergunning is, en het gebouwtje er nog gewoon staat, dan dient deze in OMS te blijven staan!
Meestal staan de bijgebouwtjes welkde niet in de BAG zijn opgenomen, WEL in de BGT, maar de BGT werkt met bovenaanzicht en BAG met maaiveld contouren.
De regels voor gemeenten zijn misschien wel duidelijk, maar hoe houden we OSM op de juiste manier actueel? Dit is dan de vraag.
Voor mij persoonlijk is visuele controle het belangrijkst! Ook de recente satellietbeelden kunnen uitkomst bieden.
Daarnaast BAG + BGT controle een MUST.
Kortom, een bot, botweg zijn gang laten gaan is geen verbetering voor OSM.
Er is ook een website. (https://imbag.github.io/praktijkhandleiding/) Deze is doorzoekbaar en wordt ook bijgewerkt en aangevuld. Is iets beter door te komen als de pdf. Maar blijft een taai geheel.
Klopt helemaal. En het is in sommige gevallen ook niet eenduidig beschreven.
Bij de nieuwe wet BAG is er onderscheid tussen gesloopt (=weg in terrein) en ten onrechte opgevoerd (= had eigenlijk bij een ander pand gehoord óf is een overkapping óf is een BGT object óf is er nooit geweest). Dat zal het op termijn makkelijker maken binnen OSM. Maar: dat onderscheidt zit nog niet in de BAG Viewer en de bestanden die het Kadaster levert. Het komt er wel aan. De gemeentes werken er als het goed is al wel mee.
Misschien is het wel een goed idee om dat ‘gesloopte’ BAG pand, dat nog wel in het terrein aanwezig is en in BGT aanwezig is, verder te laten gaan als BGT overige bebouwing. Past goed bij wat je buiten ook ziet in het terrein. Zorgt er ook voor de open kapschuren bij boerderijen zichtbaar blijven in OSM. Dat zijn namelijk geen BAG panden, maar wel BGT objecten.
Was ik een keer bezig geweest om bij alle adressen Woonplaatsen toe te voegen, spaties uit postcodes te halen. En missende postcodes aan te vullen. Was wel wat werk, maar maakt wel weer andere dingen mogelijk. Zoals ge-automatiseerder op zoek naar missende adressen. Stukje voor stukje opzoeken en in kleinere en grotere gehelen aanpassen.
Naar foute postcodes ben ik (nog) niet naar op zoek gegaan trouwens.
