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.
De openstaande vraag is nog: hoe voorkomen we foutieve herimport van adresnodes?
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).
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?
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.
Daarom verdient dit een inhoudelijke discussie om meer meningen en argumenten te horen en om te kijken welke consensus kan worden bereikt.
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:
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.
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.
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!
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.
Hi mappers, wie kan een gebouw scheiden bij de import uit het BAG ?
Ieder kunstwerk (brug, viaduct etc) heeft een fundament of landhoofd, dat onlosmakelijk aan de brug is verbonden (vast of opgelegd) waarom valt bij beweegbare bruggen dan plotseling de bascule kelder er dan ineens niet meer bij ?
De norm is toch afsluitbaar, betreedbaar etc, maar de pomp- of machinekelder vallen daar dan ook onder, kijk bv maar eens naar de Brieneroordbrug, daar past een ieder’s huis met gemaak in. En niet niet stiekum de brug openen.
Of deze de famueze Den Uylbrug https://bagviewer.kadaster.nl/lvbag/bag-viewer/#?geometry.x=117390.78583664&geometry.y=493440.90423598&zoomlevel=7&objectId=0479100000083512&detailsObjectId=0479010000075952 of via
Mapillary https://nortonsafe.search.ask.com/web?chn=1007620&cmpgn=catalyst&doi=2019-06-25&geo=nl&guid=0a5da711-64cb-40e1-b805-134c6aae944d&o=APN12179&p2=%5EEQ%5Ecatalyst%5E&page=1&prt=ngc&trackId=&ver=22.17.2.47&q=Google+Maps&tpr=5&ots=1577020939283
e machine kamer en het brugwachters-(verlaten)huis vormen een onlosmakelijk deel, waarom onderscheiden ?
Of is dat gemakzucht het kost meer moeite om dat mooi te krijgen ?
En ja ik heb weet van BAG 2.0 die onvergelijkbaar is met BAG anno 2012.
Nou ja… onvergelijkbaar zou ik het niet noemen.
Maar wat bedoel je precies met “wie kan een gebouw scheiding bij de import uit het BAG ?” ?
Een BAG pand is gewoon een polygoon plus metadata die wij dan kopieeren naar OSM.
Voor de classificatie van objecten in de BAG zijn complete beslisbomen die doorlopen worden. Hier is die van een BAG pand: https://imbag.github.io/praktijkhandleiding/objecttypen/pand.
Fouten zoals missende panden, objecten die foutief geclassificeerd zijn als pand, of bijvoorbeeld een incorrecte pandgeometrie kan je een terugmelding over maken in de BAG viewer van het Kadaster https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html. Wanneer het dan in de BAG is gecorrigeerd is kan je een verzoekje maken in onze BAG-import verzoek forum thread om het opnieuw te importeren.
In sommige gevallen botsen de definities van de BAG en wat wenselijk is in OSM en dan kunnen we in OSM gewoon lekker afwijken van de BAG. Wel zo verstandig om de nodige note= tags achter te laten op zulke objecten om te voorkomen dat ze perongeluk worden vernield door BAG import acties.
Ik ga er eigenlijk van uit dat je dit allemaal wel weet dus deze post van mij gaat eigenlijk vooral over mijn vraag 
Neem deze: https://overpass-api.de/achavi/?changeset=78432086
Mass-import, weg classificaties onterecht aangepast, highway=residential die ineens overgaan op unclassiefied, UMTS masten die verdwijnen.
Heb intussen de Baggeraar op de hoogte gesteld via de changeset
Ninjoh, Het gaat me denk ik ook meer om de leidende rol die aan het BAG wordt toegekend. Ik proef bijna zoiets als dat wanneer het niet in het BAG staat dan krijgt het geen aandacht. Maar om terug te komen op scheiden, neem een school met meerdere panden en verschillende bouwlagen (verdiepingen) maar onderling verbonden. Dus het object school krijgt in het BAG 1 Id, maar hoeveel verdiepingen krijgt dat pand dan 5 of toch losgeknipt 5, 4 en 1 (gymlokaal) ?
Dus het BAG Id verknippen en juist weergeven ?
Zeg het maar ?
We laten de overheid voor het grootste deel het moeilijke werk voor ons doen: het landmeten en karteren gebaseerd op luchtfoto’s van veel hogere kwaliteit dan de 25cm/pixel foto’s die ons ter beschikking staan. Dat is waar de hele BAG import eigenlijk op neer komt. Tegelijkertijd leveren wij ook weer terug aan de overheid in de vorm van terugmeldingen, en zo is het eigenlijk gunstig voor beide partijen.
Uiteindelijk is OSM leidend, en er zijn best gevallen waar we ook bewust van de BAG afwijken. Een goed voorbeeld daar van is dat we niet lukraak alle panden in de BAG met de status ‘Bouw gestart’ importeren, maar wachten tot een mapper heeft gecontroleerd dat er ook daadwerkelijk is gestart met bouwen, wat lang niet altijd het geval is. Andere voorbeelden zijn bijvoorbeeld bijzondere gevallen van rare administratieve deadlocks in de BAG die voor de BAG technisch wel correct zijn maar de realiteit niet weerspiegelen, of complexe gebouwen waar de BAG definitie van een ‘pand’ afwijkt van wat wenselijk is om als building=* geometrie in OSM te hebben.
De werkwijze die ik mijn vorige post beschreef - dat is: fout constateren, terugmelden, importeren - is gebruikelijk omdat dit normaliter een relatief snelle en vooral nauwkeurige manier is van zulke fouten corrigeren, die als bijkomend voordeel het risico op perongeluk weer de fout terug-importeren minimaliseert.
Echter als het verwerken van zo’n terugmelding veels te lang duurt zou je ook best OSM alvast aan kunnen passen met een nieuwe geometrie, die later evt. weer gecorrigeerd kan worden met de nieuwe BAG geometrie als die BAG geometrie nauwkeuriger is (wat vrijwel altijd het geval is, tenzij je als mapper zelf bent wezen landmeten natuurlijk ;))
Een schoolgebouw dat onderling geheel verbonden is, is één enkel pand, en dat krijgt inderdaad één BAG pand id. De BAG kent natuurlijk alleen panden, geen ‘school’ of ‘gymlokaal’, en ook geen verdiepingen. Zulke extra informatie hangen we dus in OSM er zelf bij aan.
Een schoolgebouw dat onderling geheel is verbonden is in OSM gebruikelijk ook één enkel building=school, dus daar ligt geen conflict naar mijn inzien.
Verdiepingen en sub-delen van panden kan je taggen d.m.v. o.a. het Simple 3D Buildings tagging scheme (https://wiki.openstreetmap.org/wiki/Simple_3D_buildings).
Voor verdiepingen staat dit uitgebreid beschreven in https://wiki.openstreetmap.org/wiki/Simple_3D_buildings#Height_and_levels.
Een gymlokaal zou je dan kunnen taggen door een nieuwe closed way (polygon) te tekenen die aansluit op de building=school, en die te taggen als:
building:part=yes
leisure=sports_hall
Zoals ook beschreven staat op de wiki pagina van leisure=sports_hall (https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dsports_hall)
Wat ook belangrijk is om te benoemen denk ik is dat er veel objecten zijn in Nederland die wel in de definitie OSM ‘building’ passen, maar volgens de BAG geen echt ‘pand’ zijn, en dus niet in de BAG staan. Dan moet je vooral denken aan schuurtjes die niet stevig verankerd zijn in de grond, voorheen mega grote kapschuren (definities aangepast in BAG 2.0), overkappingen, carports, gebouwen die niet afsluitbaar zijn, enz.
Deze objecten worden meestal zelfstandig ingetekend in OSM, of er wordt gebruik gemaakt van de BGT (al dan niet als rasterkaart om over te tekenen) als ad-hoc bron voor de geometrie. Veel van de objecten uit deze klasse staan wel in de BGT maar niet in de BAG.
Als je daarbij huizen op een ziekenhuisterrein gaat zetten en een toegangsweg naar dat ziekenhuis ineens niet meer bestaat denk ik daar anders over.
Ik hem enorm veel respect voor onze baggeraars, maar dit gaat m.i. te ver.
https://www.openstreetmap.org/note/2144928#map=18/52.05595/4.26520
M.i. valt dit onder een automatische import die niet goed uitgevoerd is.
Deze is uitgevoerd door de vries, hij verzet bergen wat betreft de BAG panden up to date houden in NL. Hij voert zoveel BAG updates uit, ik snap niet hoe hij het doet. Dat gaat dus zo af en toe fout, soms ook grof fout, zoals hier is gebeurd. Ik begrijp dit geval wel moet ik zeggen: de status van deze panden in de BAG is “Bouw gestart”, niet de “Vergunning verleend” die we nooit importeren zonder andere bronnen te raadplegen. Normaal gesproken krijgt het pand pas weken of zelfs maanden nadat de bouw werkelijk is gestart de status “Bouw gestart”, “Bouw gestart” loopt dus achter op de werkelijkheid, niet voor, zoals hier het geval lijkt te zijn.
Eigenlijk is dit dus gewoon een fout in de BAG, tenzij ze werkelijk op het punt staan om te beginnen. Zo lsng er niet gebouwd wordt zou ik de gebouwen omtaggen naar proposed:building.
de status is teruggezet naar bouwvergunning verleend.
bij OSM gaat ‘ground truth’ voor
dat weet De Vries echt wel hoor
bij situaties die hij niet zag
blijft hij uitgaan van de BAG
en gaat dus op oude wijze door!
bij OSM is de vraag: wat is er echt?
dat heb ik De Vries al meermaals gezegd
bij situaties die hij niet zag
blijft hij uitgaan van de BAG
en doet andermans werk geen recht!
OSM gaat om afstemming zoals je weet
iets wat De Vries telkens vergeet
bij situaties die hij niet zag
blijft hij uitgaan van de BAG
daarom nog eens deze kreet!