BAG-imports: hoe niet-incidentele fouten voorkomen?

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.

Hendrikklaas · 2019-12-22T13:34:14.000Z

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.

Ninjoh · 2019-12-23T20:12:34.000Z

Hendrikklaas:

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

Geim · 2019-12-28T08:13:14.000Z

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

Hendrikklaas · 2019-12-31T13:12:04.000Z

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 ?

Ninjoh · 2019-12-31T13:57:58.000Z

Hendrikklaas:

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.