21

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.

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.