Dit onderwerp heb ik eerder aangekaart: BAG vs. realiteit.
Helaas lijkt dat niets concreet te hebben opgeleverd.
Er zijn mappers die systematische/regionale BAG-updates doen los van de aanvragen die in het topic Bag-import worden gedaan en (dus) zonder controle in de werkelijkheid. Ik begrijp dat dit nodig is om te zorgen dat OSM voldoende actueel blijft op het gebied van gebouwen. Daarom ben ik er ook wel voorstander van en blij mee.
Ik zou alleen graag zien dat er een vorm van handmatige controle is waarbij elk te importeren/wijzigen object minimaal één snelle beoordeling heeft gehad.
Ander voorbeeld: https://www.openstreetmap.org/#map=19/53.17017/5.85142&layers=N
Op 25-08-2017 is daar een ter plaatse niet-zichtbaar bouwsel geïmporteerd.
Iemand plaatste een note. Ik heb het bouwsel op 07-08-2018 niet verwijderd om latere herimport te voorkomen, maar op building=no gezet en de adresnode verwijderd.
Vervolgens zie ik daar nu weer een losse adresnode (nummertje 3) op 23-09-2018 door dezelfde importeur teruggeplaatst.
Het gaat er NIET om dat BAG-imports foutloos zouden moeten zijn.
Het gaat er WEL om systematische herhaling van fouten te voorkomen.
De situatie van een bouwsel bij een brug, reeds gesloopt of ondergronds en ontoegankelijk en daarom niet behorende in OSM, heb ik al vaker gezien dan de twee voorbeelden. Correcties van andere mappers kunnen daardoor telkens opnieuw worden overgeschreven en zo blijft het probleem zich herhalen.
Het zien van zo’n gebouwtje of node vlakbij een brug zou een BAGgeraar meteen alert moeten maken… maar dan moet hij er natuurlijk wel notie van hebben genomen.
Eerder is al eens note:BAG=* voorgesteld om het te markeren maar dit heb ik al eens genegeerd zien worden en is niet altijd de geschikte oplossing. Zo’n adresnode bijv. zou gewoon buiten OSM moeten blijven.
Iedere BAGgeraar zal net iets anders te werk gaan en de ene zal meer controles doen dan de andere. Mogelijk importeren de BAGgeraars die meer ‘fouten’ maken in verhouding veel data.
Nogmaals, het actualiseren van gebouwen wordt gewaardeerd. Ik vind echter niet dat de hoeveelheid goede data betekent dat fouten die niet-incidenteel zijn maar gewoon geaccepteerd moeten worden.
Het moet toch op zijn minst mogelijk zijn dat één melding van een (plaatselijke) mapper herimport van dezelfde ongewenste BAG-data voorgoed voorkomt?
Dan zouden we een eigen “BAG-OSM-database” moeten hebben waarin BAG-fouten gedocumenteerd worden. Niet-bestaande BAG-panden kunnen dan een aantekening krijgen in die database en de software kan daarmee rekening houden.
Of: afspreken dat “normale” mappers gesloopte panden nooit verwijderen maar altijd de tag building=no geven, of zoiets.
Als ik zelf BAG updates doe controleer ik o.b.v. satellietbeelden (veelal Superview) om te beoordelen of de geometrie correct is / of er gestart is met de bouw. Geen werkzaamheden / situatiewijziging is voor mij ook geen import.
Bij mij wordt iedere import met de hand gecontroleerd, helaas komt dit de snelheid niet ten goede maar dat neem ik voor lief.
(Voor het importeren van schuurtjes ben ik wel wat makkelijker.)
Ik zie in BAG dat het gebouw onder het aquaduct zit (en blijkbaar een adres heeft). Nu liggen zowel het adres als het gebouw op de verkeerde plek. Ik vermoed dat deze ruimte via het fietspad bereikbaar is.
Misschien building=* weghalen en man_made=pumping_station(?) toevoegen. Alleen het adres zal dan wel op het water zweven.
Wanneer er aanvullende gegevens op het gebouw zijn geplaatst door een mapper worden deze in BAG OSM zichtbaar met de tekst “Kijk uit: pand”, dit zou voldoende moeten zijn om de aandacht van de baggeraar te trekken. Misschien dat het helpt om de deze visuele melding prominenter aanwezig te maken, door het gebouw een aparte kleur te geven o.i.d?
Als gedachtenspinsel wellicht bij note:BAG=* een pop-up melding geven in JOSM dat er extra opgelet moet worden.
Bedankt voor je reactie en toelichting. Is er tussen de BAGgeraars wel eens overleg over de werkwijze?
Genoemde fouten in imports ben ik van jou inderdaad nog niet tegengekomen.
Wel al eerder van de twee BAGgeraars in de voorbeelden.
Ik ben zelf niet de snelste mapper maar wel heel nauwkeurig, vaak wat te veel en van anderen zal ik niet hetzelfde vragen.
Waar voor de een extra nauwkeurigheid meer voldoening geeft kan dat voor een ander meer snelheid/dataverwerking zijn, waarbij je het sneller wegwerken van achterstanden als grotere nauwkeurigheid kunt zien.
Dan kom je weer uit bij recente discussie… de reden dat imports met een zekere terughoudendheid gepaard moeten gaan.
Over schuurtjes maak ik mij ook minder druk. Daarbij vertrouw ik graag op een regionale update in plaats van een los importverzoek te doen.
Ik ben er wel eens langsgefietst en heb goed gekeken en er is echt niets van te zien.
Goed dat je meteen wat mogelijkheden hebt geschetst. Ik hoop dat andere BAGgeraars willen meedoen aan de discussie om, als ervaringsdeskundigen, samen het een en ander te stroomlijnen.
Een BAG-OSM-database kan omslachtig klinken maar als het slim wordt opgezet, als online-database met goed uitgewerkte front-end, zou het in theorie soepel kunnen werken. Ga je bijv. een bepaalde gemeente bijwerken dan typ je de naam in en verschijnt er een kort lijstje met aandachtspunten in dat gebied.
Wellicht is zo’n database meteen te combineren met andere zaken waarmee BAGgeraars gezamenlijk goed overzicht houden over de stand van zaken.
Het ‘elimineren’ van niet-gewenste BAG-data binnen de OSM-database zelf kan ook. Als dan maar voor iedereen, BAGgeraars en andere mappers, duidelijk is in welke situatie je wat doet.
Bij twijfelpunten zouden BAGgeraars een lokale mapper kunnen vragen of anders een note op de kaart plaatsen. Denk ook aan vernieuwing van het wegennet en dergelijke die kan worden opgemerkt bij handmatige controle van BAG-importeurs en door andere mappers kan worden opgepakt.
Een tijdje terug heb ik Limburg bijgewerkt met de BAG.
Hierbij zal ik ook vast fouten gemaakt hebben (sorry daar voor).
Wel merk ik dat veel gemeentes een heel eind zijn met het op orde brengen van hun bestand.
Wat ik erg positief vond dat de terugmeldingen via de de BAG viewer veelal snel afgehandeld werden.
De dag nadat ik tientallen meldingen gedaan had was bij een vierde deel al afgehandeld.
Waar een paar jaar geleden je van een aantal gemeentes niets terug zag (en niets gebeurde) werd de melding nu opgepakt.
Binnen een maand was bijna alles afgehandeld.
Het aantal gevallen waar ik niet importeerde omdat er iets niet klopt is aanzienlijk afgenomen sinds een jaar geleden.
Uiteraard juich ik een mogelijkheid toe om het kenbaar te maken dat een pand niet geimporteerd wordt.
Het is waarschijnlijk te simpel gedacht, maar is het volgende een werkbaar idee?
Als ik een BAG-pand verwijder en ik ben bang voor herimport, laat ik gewoon een node van het gebouw staan, met als enige tag note:BAG=pand is gesloopt of iets in die trant. Dat levert bij opnieuw importeren toch een validation error op (Duplicated nodes).
Dan zal de BAG-importeur toch niet uploaden zonder hier nog eens naar te kijken?
Op zich een leuk idee, maar bij een BAG import, krijg je nog al eens duplicate nodes in allerlei vormen en dan is mijn reactie meestal op Fix drukken en klaar.
Als een pand niet bestaat, maar wel in de BAG viewer staat, doe dan een terugmelding in de viewer. Dat is lastig, ik weet het, maar dat is de manier om het in de BAG goed te krijgen.
In OSM kun je dan op meerdere manieren het gebouw onzichtbaar maken. disused:building kan ook.
Als een pand recent gesloopt is, kun je ook een landuse=construction tekenen, dat geeft ook al duidelijkheid.
En ook in dat geval even in de viewer kijken en eventueel een terugmelding doen.
Dit brugwachters huisje is in de BAG inmiddels ook gesloopt. Ik heb dus maar de verantwoordelijkheid genomen het ook van osm af te gooien. In dit geval is er geen actie nodig om herhaling te voorkomen, aangezien de BAG inmiddels ook weet dat het pand niet meer bestaat.
Het geld overigens voor ongeveer de helft van de meldingen die ik krijg over foutief geïmporteerde panden dat ze al niet meer in de BAG staan op het moment van melden.
Voor de overige gevallen zijn er wel maatregelen nodig om herhaling te voorkomen.
Dit lijkt mij overdreven
Dit zou inderdaad een goede oplossing zijn. Echter er is momenteel al te weinig capaciteit om de huidige BAG-plugin te onderhouden. Ik zie dit dus niet snel van de grond komen.
Volgens mij is de beste oplossing om in het geval van een foutieve herimport, na een check in de BAG-viewer of het nog nodig is, de building=* tag te vervangen door demolished:building=* en eventueel een ‘note:BAG=pand is gesloopt’ toevoegen.
Wat mij betreft ligt de verantwoordelijkheid van de uitvoering hiervan in eerste instantie bij de baggeraar, maar dit mag uiteraard ook door andere mappers gedaan worden.
[TIP] Als je de Tag2Link plugin in JOSM installeert krijg je een directe link naar de BAG-viewer als je rechts-klikt op de ref:bag tag. Dit maakt controles en terugmeldingen een stuk sneller.
Op zich een goed idee en die informatie staat ook handig in een overlay.
Echter, dat gaat pas goed werken als de BAG op orde is en er alleen onderhoud gebeurd.
Nu zie ik dat in sommige gemeentes tot wel 90% van de import oude gebouwen zijn.
Bv. omdat eeen gebouw (bij het inmeten) in werkelijkheid 2 gebouwen zijn. Beide hebben dan een oudere bouwdatum.
Sommige gemeentes zijn afgelopen jaar begonnen met het massal invoeren van bijgebouwen.
Als er binnen een maand een paar honderd gebouwen in een gemeente bijkomen is dat een goede indicatie hiervoor.
Bij oudere gebouwen die nog niet geimporteert zijn is de luchtfoto een hulpmiddel, al valt dat tegen in een stad die volgebouwd is.
De twee belangrijkste vormen van foutieve herimport zijn:
een gesloopt pand dat nog wel in de BAG staat
een object dat in de BAG staat maar niet geschikt is voor OSM (zoals een ondergronds onzichtbaar component van een brug of aquaduct).
Wat nu regelmatig gebeurt:
Een object wordt uit OSM verwijderd.
Het object wordt vanuit de BAG opnieuw geïmporteerd.
Het object wordt opgemerkt en in vraag gesteld via een opmerking op de kaart (of verwijderd).
Toepassing van de oplossing met een tag om het van de kaart te houden, of verwijdering en dus op later moment herhaling vanaf punt 1…
Veel beter en efficiënter is dat het bij de eerste ingreep meteen goed gaat.
Daarvoor is nodig dat zoveel mogelijk mappers weten wat te doen en dat de werkwijze van BAGgeraars erop aansluit.
Een opzetje van mij:
Het risico blijft dat (onervaren) mappers objecten hoe dan ook regelrecht verwijderen. Alleen al de aanwezigheid van het object in de editor kan bij mappers voor verwarring zorgen.
En hoe voorkomen we foutieve herimport van adresnodes?
Inhoudelijk maar 1 ding op aan te merken: Niet iedere mapper zal de weg naar de BAG-Viewer weten te vinden, danwel de kennis/tijd/zin hebben deze info uit de Bag op te halen.
Wat mij betreft moet het altijd een optie zijn om via een PB of changeset comment de baggeraar van de problemen op de hoogte te brengen. Het is dan aan die baggeraar om het probleem via deze werkwijze op te lossen.
Het kan worden omgedraaid: standaard objecten omtaggen naar demolished:building danwel building=no. Daadwerkelijk uit OSM verwijderen doe je dan alleen als je in de BAG Viewer ziet dat het object afwezig of niet meer selecteerbaar is of de status ‘sloopvergunning verleend’ heeft.
Het gaat mij nou net om de preventieve optie door een definitieve werkwijze af te spreken voor zowel mappers als BAGgeraars.
Daar hebben we in principe ons eigen forum voor. Als nieuwere baggeraar vind ik de werkwijze aardig vanzelfsprekend en niet veel verschillen met hoe er normaal gemapped hoort te worden. Elkaars werk niet (zonder discussie) te niet doen en bij twijfel niet importeren, of de ervaringsdeskundigen (wiki, forum, etc.) raadplegen.
Ik heb meerdere gebieden in best extreem detail gezet in en rond Leeuwarden, dus qua mapping ethos zullen wij niet zoveel van elkaar verschillen.
Wanneer de sloopvergunning is verleend wordt de status van het gebouw ‘removal_due’, wanneer een gebouw deze status heeft moet hij, net zoals bij “vergunning verleend” handmatig geïmporteerd worden. Deze gebouw statussen kunnen niet met de update knop in BAG OSM komen. Wanneer een gebouw de status removal_due heeft zal een baggeraar het gebouw niet meer aanraken.
Het omzetten van de key naar demolished:building=* vind ik een prima methode. Desnoods met iets als ‘fixme=Pand gesloopt, BAG terugmelding benodigd.’
+1 Deze kende ik nog niet.
Gelijk maar even gebruik van gemaakt bij het actualiseren van de Gemeente Heerenveen.
Inmiddels heb ik via persoonlijke berichten contact gehad met Sander H en een en ander besproken. Het lijkt me goed om nu op het forum door te gaan.
Het onderwerp van BAG-import in relatie tot gewenste OSM-data is al vaker aan de orde gebracht door mij en door anderen. Diverse ervaren mappers hebben kritiekpunten naar voren gebracht.
Ik hoop dat er nu echt iets mee wordt gedaan door de betrokkenen. Er is voor een deel wel erkenning van het probleem. Verantwoordelijkheid nemen in de zin van actie is vooralsnog uitgebleven. Dus dan blijf ik erop terugkomen maar dat blijf ik niet op deze wijze doen. Het is niet aan mij om te bedenken hoe het kan worden opgelost, hoewel ik graag meedenkt. Het is niet aan mij om met een voorstel te komen.
Hierbij dan een duidelijke oproep aan mappers die ongecontroleerde BAG-imports uitvoeren, in elk geval De Vries en Sander H, om in actie te komen.
Sander heeft geopperd om een poging te doen alsnog een blacklist op te zetten.
Een inhoudelijke discussie over welke BAG-data in OSM gewenst is moet mogelijk nog worden gevoerd.
Meer algemeen denk ik dat BAGgeraars en andere mappers best meer kunnen samenwerken dan alleen middels het topc voor importaanvragen. Waar is bijvoorbeeld informatie over de status van BAG-info in Nederland? Waar kunnen we zien welk gebied ongeveer tot welke datum is bijgewerkt?
BAGgeraars kunnen, vooral als ze wel goede controles doen, allerlei zaken opmerken en andere mappers attenderen op zaken die verbetering behoeven, zoals het bijwerken van infrastructuur, groen en uitlijning in een wijk of dorp waar ze een import hebben gedaan. Op die manier krijgt het toch al nuttige werk van de BAG-imports nog meer waarde.
Laten we vooral het probleem niet groter maken dan het is.
Een foutieve BAG-import zo af en toe is geen ramp en wordt meestal uiteindelijk aan de hand van nieuwere foto’s, notes op de kaart en meer wel weer hersteld en zo niet: dan nog steeds geen ramp.
Als de BAG-geraars de zorgvuldigheid op zich nemen niet lukraak te gaan stofzuigeren en zorgvuldig te werk gaan (foto’s checken, datums, geschiedenis en dergelijke) valt het - zo denk ik - wel mee.
Ikzelf heb geen behoefte aan ‘geavanceerde’ tools met hun eigen nukken en fouten.
Nee, ik kon er ook niets ontdekken. Ik snap niet zo goed waarom dit ondergrondse object met zijn adresnode perse op de kaart moet. Ik ben helemaal voor zichtbare details, maar zo’n onzichtbaar systeemobject als dit met een adresnode midden op het water maakt de kaart niet beter. We tikken de gemeente Utrecht op de vingers dat ze geen wegen moeten opknippen om ze elk een eigen id te geven, maar zelf importeren we objecten die alleen relevant zijn voor een paar medewerkers van Rijkswaterstaat (die echt niet verwachten dat de ondergrondse, verborgen technische ruimte voor Akwadukt Langdeel op OSM staat).
Nee dat klopt, maar bij ongewenste rendering van een gewenst object moet het wel mogelijk zijn om die rendering te kunnen verbeteren. Bij een object als deze kan ik me voorstellen dat de gewenste rendering is om de adresnode net als het het object zelf te verbergen (in ieder geval op de standaardkaart), maar dan moet dat wel kunnen op basis van de tags. Ik draag met alle liefde een PR (pull-request) aan voor Carto-OSM om adresnodes van dit soort verborgen systeemobjecten ook te verbergen, maar dan moeten we iets afstemmen over de tags die dat mogelijk maken. Ik vermoed overigens dat ze bij Carto-OSM ook terecht zullen opmerken waarom deze objecten dan überhaupt in de database staan.
Een andere oplossing is om dit soort objecten gewoon niet te importeren. Eventueel via een BAG-ID blacklist. Ook goed. Ook hier draag ik graag een PR aan, alleen is dat geloof ik niet mogelijk omdat de BAG import plugin voor JOSM naar mijn weten nog gesloten software is.
Vorig jaar heb ik met de gemeente Leeuwarden contact gehad over dat object via een BAG-terugmelding:
Prima. Het is een object dat met een juridische reden in de BAG staat. Het heeft, gezien de opmerking van de gemeente, op OSM geen toegevoegde waarde. Als het adres er al in hoort, dan ergens op een plek op dat perceel waar het wel logisch is. Op het toegangshek bijvoorbeeld. Dus ik haal het nepgebouw weg, en… een paar maanden later staat het er weer door een automatische BAG-update.
Een BAG-terugmelding is hier niet geldig, dus zitten wij er in OSM aan vast?
Echt, ik vind beide oplossingen prima, alleen neigt de oplossing nu steeds naar niks doen en gewoon maar accepteren dat de kaart er kwalitatief op achteruit gaat door (bijvoorbeeld) spooknummers in een kanaal of niet-bestaande objecten middenin een haven.
