BAG-imports: hoe niet-incidentele fouten voorkomen?

AndriesWijma · 2019-12-09T19:48:33.000Z

E de Wit:

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.)

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.

E de Wit:

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.

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.

Kogacarlo:

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.

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.

JanWandelaar · 2019-12-09T21:05:37.000Z

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.

alphensebezorger · 2019-12-09T23:08:05.000Z

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?

dvdhoven · 2019-12-10T06:29:25.000Z

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.

Geim · 2019-12-10T07:34:02.000Z

Kan je bij de import niet naar de startdatum kijken en er voor kiezen om oudere panden niet opnieuw te importeren?

de_vries · 2019-12-10T09:10:02.000Z

AndriesWijma:

Als voorbeeld dit geval:
https://www.openstreetmap.org/note/2020950

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.

Kogacarlo:

afspreken dat “normale” mappers gesloopte panden nooit verwijderen maar altijd de tag building=no geven, of zoiets.

Dit lijkt mij overdreven

Kogacarlo:

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.

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.

JanWandelaar · 2019-12-10T11:35:46.000Z

Geim:

Kan je bij de import niet naar de startdatum kijken en er voor kiezen om oudere panden niet opnieuw te importeren?

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.

AndriesWijma · 2019-12-11T16:56:07.000Z

Bedankt voor de reacties.

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:

Gesloopt object

De mapper controleert de BAG-status. Is het object nog volledig aanwezig in de BAG? Zet dan de key building=* om naar demolished:building=*. Als het object in werkelijkheid al meer dan een half jaar geleden is gesloopt dan is een BAG-terugmelding gewenst.
Is het object afwezig, niet meer selecteerbaar of heeft het de status ‘sloopvergunning verleend’? Dan kan het object gewoon worden verwijderd uit OSM.

De BAG-importeur importeert geen objecten met status ‘sloopvergunning verleend’ of objecten die in OSM staan als demolished:building=*.

Ander ongewenst BAG-object in OSM

De mapper controleert de BAG-status. Is het object nog volledig aanwezig in de BAG? Zet dan de tag building=* om naar building=no. Is het object afwezig, niet meer selecteerbaar of heeft het de status ‘sloopvergunning verleend’? Dan kan het object gewoon worden verwijderd uit OSM.

De BAG-importeur importeert geen objecten die in OSM staan als building=no.

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?

de_vries · 2019-12-11T19:43:43.000Z

AndriesWijma:

Een opzetje van mij:
[…]

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.

AndriesWijma · 2019-12-12T01:12:46.000Z

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.

de vries:

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 gaat mij nou net om de preventieve optie door een definitieve werkwijze af te spreken voor zowel mappers als BAGgeraars.

E_de_Wit · 2019-12-12T22:11:26.000Z

AndriesWijma:

Is er tussen de BAGgeraars wel eens overleg over de werkwijze?

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.

AndriesWijma:

Ik ben zelf niet de snelste mapper maar wel heel nauwkeurig, vaak wat te veel en van anderen zal ik niet hetzelfde vragen.

Ik heb meerdere gebieden in best extreem detail gezet in en rond Leeuwarden, dus qua mapping ethos zullen wij niet zoveel van elkaar verschillen.

AndriesWijma:

De BAG-importeur importeert geen objecten met status ‘sloopvergunning verleend’ of objecten die in OSM staan als demolished:building=*.

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.’

de vries:

[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.

+1 Deze kende ik nog niet.
Gelijk maar even gebruik van gemaakt bij het actualiseren van de Gemeente Heerenveen.

AndriesWijma · 2019-12-14T01:08:46.000Z

De openstaande vraag is nog: hoe voorkomen we foutieve herimport van adresnodes?

AndriesWijma · 2019-12-19T23:30:53.000Z

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.

Martin_Borsje · 2019-12-20T06:05:14.000Z

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.

JeroenHoek · 2019-12-20T14:16:12.000Z

AndriesWijma:

Ik ben er wel eens langsgefietst en heb goed gekeken en er is echt niets van te zien.

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).

https://www.openstreetmap.org/changeset/78652192#map=19/53.17030/5.85158&layers=N

Wat is er op tegen om zo’n object als dit met zijn adresnode als geschikte kandidaat voor een BAG-blacklist te zien?

AndriesWijma · 2019-12-20T17:17:27.000Z

Jeroen, ik ben het met je eens en had het er al met Sander over gehad.

Waar het om gaat is of zo’n object wel of niet een plaats verdient in de OSM-database.

Als er vindt van wel en als het deugdelijk tags heeft, dan is ongewenste rendering op de standaardkaart geen geldig tegenargument.
Als je vindt van niet dan is het voorkomen van rendering ondanks aanwezigheid in de OSM-database wel het minste wat je mag verwachten.

Daarom verdient dit een inhoudelijke discussie om meer meningen en argumenten te horen en om te kijken welke consensus kan worden bereikt.

JeroenHoek · 2019-12-20T17:35:17.000Z

AndriesWijma:

Als er vindt van wel en als het deugdelijk tags heeft, dan is ongewenste rendering op de standaardkaart geen geldig tegenargument. Als je vindt van niet dan is het voorkomen van rendering ondanks aanwezigheid in de OSM-database wel het minste wat je mag verwachten.

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.

Hier is nog een mooi voorbeeld: https://www.openstreetmap.org/way/627597719

Vorig jaar heb ik met de gemeente Leeuwarden contact gehad over dat object via een BAG-terugmelding:

Bevindt zich hier daadwerkelijk een object met huisnummer onder water?

Uw melding betreft het adres De Zwemmer 3 en betreft een uitzonderlijke situatie. De gemeentelijke afdeling Bouwen, Wonen en Milieu (BMM) heeft in het verleden namelijk de eigenaar van dit perceel geweigerd een opstal te plaatsen en daarbij de toezegging gedaan dat hij desondanks een adres zou krijgen.

Niettegenstaande het feit dat uw melding terecht is zie ik me om deze reden genoodzaakt het authentieke adres te handhaven.

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.

de_vries · 2019-12-20T20:17:45.000Z

AndriesWijma:

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.

Ik snap dat je de verantwoordelijkheid voor een oplossing bij de bag-updaters neerlegt en kan het hiermee ook niet oneens zijn. Echter herken ik het beeld dat je hier schetst niet echt. Allereerst heb je zelf hierboven onder de titel “Een opzetje van mij” een vrij gedetailleerd voorstel gedaan hoe om te gaan met gesloopte objecten. Daarnaast zie ik meerdere BAG-updatende mappers verantwoordelijkheid nemen door hier in dit topic openheid over hun werkwijze te geven en mee te zoeken naar een oplossing.

Ik kan niet voor alle BAG-updaters spreken, maar ik zal in dit bericht proberen uit te leggen wat ik zelf doe om (herhaling van) fouten te voorkomen.

Tijdens het uitvoeren van een bag-update ben ik continu op zoek naar hints dat er iets mis is met de BAG data. Dit begint met het de in JOSM ingebouwde validator, waar ik alle panden en adressen doorheen haal voor en na dat ik deze naar osm kopieer. Fouten die ik hierbij aantref probeer ik te fixen met behulp van PDOK of bij nieuwere panden met latest mosaic van het satelietdataportal. (Als ik geen oplossing kan vinden behoud ik de huidige situatie.) Daarnaast zij er nog vele andere bronnen die kunnen leiden tot een vermoeden dat er iets niet klopt en die ik gebruik om bij een dergelijk vermoeden nader te onderzoeken wat er aan de hand is. Denk hierbij o.a. aan tags zoals ‘start_date’ ‘note’ en ‘note:bag’, afwijkingen tov PDOK, conflicten met wegen, aanwezigheid van andere objecten nabij of op de zelfde plek als een bag pand, of een pand is bewerkt sinds de initiële BAG-import, door wie een pand is bewerkt (BAG-mapper of iemand anders), hoe recent een pand bewerkt is, de changeset comments, de historie van een object, etc.
Om een voorbeeld te geven: Als er volgens de BAG een pand staat waar volgens osm een parkeerterrein is zal ik eerst op PDOK kijken. Als er op PDOK een pand te zien is kijk ik naar de datum waarop het parkeerterrein is toegevoegd/voor het laatst gewijzigd. Als dit bv. 5 jaar geleden is kan je er van uitgaan dat PDOK en dus de BAG klopt. Als het parkeerterrein recent is toegevoegd is het pand waarschijnlijk net afgebroken loopt de BAG achter. (tenzij je te maken hebt met een onervaren mapper die Bing heeft nagetekend.)

Ik ben me er van bewust dat deze methode niet feilloos is, maar als ik mag afgaan op de verhouding tussen het aantal fouten dat ik hiermee eruit filter en het aantal meldingen van andere mappers dat ik iets verkeerd gedaan heb, durf ik te concluderen dat deze methode het over grote deel van de fouten weet te voorkomen.

In het geval ik toch een bericht krijg dat ik iets foutief heb geüpload zal ik hier altijd op reageren en mijn best doen en er prioriteit aan geven om dit probleem op te lossen, danwel de mapper te helpen het probleem op te lossen en herhaling te voorkomen.

AndriesWijma:

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.

Als ik een gebied download voor een BAG-update probeer ik altijd om meer toe te voegen dan alleen de BAG data. Allereerst haal ik alle osm data door de JOSM validator en ik probeer zoveel mogelijk fouten op te lossen. Daarnaast zijn er veel andere zaken die je zonder survey kan verbeteren. Bijvoorbeeld in gebieden waar weinig mappers actief zijn, zijn veel wegen niet meer aangeraakt sinds de AND import. Met behulp van PDOK en bgt leg ik deze dan recht en voeg ik zaken als verkeersdrempels toe. Andere zaken ik ik regelmatig bewerk zijn landuses, sportparken en wikidata.
Deze werkwijze heeft twee voordelen: Natuurlijk de directe verbetering van de osm data, maar ook dat ik iedere uithoek van het update gebied zorgvuldig bekijk en hiermee de kans vergroot dat ik BAG-problemen spot die er niet systematisch uit te filteren zijn, maar visueel opgemerkt moeten worden.

Ik hoop dat ik hiermee voldoende openheid over mijn werkwijze heb gegeven en het idee dat ik ongecontroleerd te werk ga enigszins heb kunnen doorbreken.

AndriesWijma · 2019-12-20T23:39:58.000Z

De Vries, bedankt voor je uitgebreide reactie.

Zo’n inkijk in je werkwijze is op zichzelf al nuttig en interessant om te lezen. Het is duidelijk dat je zeker tijd en moeite steekt in controle.
‘Ongecontroleerd’ heb ik overigens zeker niet in de zin van ‘lukraak’ bedoeld maar in de betekenis ‘niet per object/situatie/locatie beoordeeld’. Is het zo dat jij wel min of meer alles individueel beoordeelt?

Zo’n geval als bij de vernieuwde brug te Zuidhorn, BAG-import van een brugwachtershuisje die al twee jaar eerder is gesloopt, doet mij denken aan een niet-gecontroleerde situatie.

Het gaat mij echt om dit soort gevallen waarbij zelfs een simpele controle op de positie van objecten al alert zou moeten maken, zoals een object in het water. Genoeg lucht- en satellietfoto’s waarop te zien was dat het gebouwtje er niet meer was.

Nog een allerlaatste keer noem ik het volgende: het is geen kritiek is op incidentele fouten, of op wijze van herstel van incidentele fouten of op de ratio goede-foute data. Dat doet allemaal niet ter zake.

Ik constateer alleen dat het bij dergelijke objecten in of bij het water herhaaldelijk fout gaat met BAG-imports… dus een patroon… dus iets wat te voorkomen moet zijn in plaats van telkens achteraf te corrigeren.

Verder heb ik inderdaad opgemerkt dat je tijdens BAG-updates zelf verbeteringen in andere omliggende data doorvoert, en daarmee in je eentje meer doet voor bepaalde gebieden dan alle andere mappers er sinds de grote imports ooit hebben gedaan. Dat vind ik top!

AndriesWijma · 2019-12-21T00:14:56.000Z

de vries:

Ik snap dat je de verantwoordelijkheid voor een oplossing bij de bag-updaters neerlegt en kan het hiermee ook niet oneens zijn. Echter herken ik het beeld dat je hier schetst niet echt. Allereerst heb je zelf hierboven onder de titel “Een opzetje van mij” een vrij gedetailleerd voorstel gedaan hoe om te gaan met gesloopte objecten. Daarnaast zie ik meerdere BAG-updatende mappers verantwoordelijkheid nemen door hier in dit topic openheid over hun werkwijze te geven en mee te zoeken naar een oplossing.

Hier nog even op reageren. Het opzetje was bedoeld om te worden opgepakt door één van de verantwoordelijken. Bovendien bleef het stil na mijn nog cruciale openstaande vraag over adresnodes, waardoor ik het zelf hoe dan ook niet verder kon uitwerken.
Het was belangrijk dat ook Sander H zou reageren en daarom heb ik hem persoonlijk geschreven. Ik hoop dat hij nog van zich gaat laten horen in dit topic.