Ja eens; dat zou inderdaad vaak een hoop werk schelen 
1 Like
Voor het kopieren van objecten vanuit een BGT-objectlaag (BGTlaag aktiveren-Control C-OSMlaag aktiveren-ControlV) zou het handig zijn als de BGT-laag al de juiste OSM-tags had ipv de BGT-tags.
Daar zorgt dat script dus voor. Die voegt overal al de goede tags aan waar mogelijk. Vervolgens voeg ik 2 lagen in JOSM, 1 de OSM laag en 1 de BGT laag. Dan selecteer ik objecten uit de BGT laag, CTRL + Shift + M en daarmee merge ik de selectie met de OSM laag. Moet je alleen wat kleine geometrische correcties doorvoeren of tags aanpassen waar fout geclassificeerd.
Dit citaat even als basis voor de BAG/BGT discussie.
De frustratie waarom, dat die node niet op dezelfde plek ligt.
Want BGT en BAG zouden toch hetzelfde moeten zijn.
Dan moet je het proces begrijpen, waar komt het verschil vandaan.
En dat probeer ik ook te begrijpen.
Om het verschil aan te geven.
Heb je het hier over twee datasets BAG BGT, die je zelf gebruikt, gedownload hebt, beide polygonen gekopieerd naar Josm? En dan vergeleken. Kale data. Zit daar al een verschil?
Of het BAGpand dat via de Bagimport in OSM is gezet.
Via Josm dan geupload naar OSM, opgeslagen in osm databankformaat, in een josm nieuw layer, dan het gebied weer gedownload inclusief het pand en dan de node vergeleken met de BGT gekopieerde polygon.
Alles heeft te maken met de coördinatennotatie en het coördinatenstelsel, verwerkingsproces, gebruikte programmatuur.
Dan moet je begrijpen, hoe die BAG OSMnode tot stand is gekomen.
Het proces. De twee afzonderlijke wel aansluitende BAGgebouwen, waarvan de hoekpunten tot Ă©Ă©n punt zijn samengebracht, deze node via josm geupload naar osm, databank formaat en weer terug krijgen. (een begrijpelijk gekozen oplossing)
Het samen brengen van twee nodes, is een bewerking en bewerkingen kunnen al verschillen in notatie van de node opleveren.
Hoe veranderlijk de BAG nodes zijn, bijvoorbeeld na inmeting.
De vergelijking OSM:BAG
Bag bijwerken, stel bij een blok met huizen en 1 pand is veranderd met een achterzijde aanbouw, dan denk je, je pakt dat ene huis kopieert het, fix op elkaar liggende nodes, dezelfde notatie en klaar.
Van de vier ligt er 1 node op dezelfde plek en is met fix te verhelpen.
Na replace geometry en validatie
De BAG updater lost dat op zijn eigen manier op.
Nu is gertjan met deze BAGplugin bezig.
Het geeft aan hoe lastig het is om aansluitend te werken.
De invloed van voorbewerkingen, binnen de plugin.
Rechtstreeks uit een database.
Laat staan uit twee verschillende databases.
Dat je goed moet nadenken over het voorbewerken, dat andere dezelfde methodes gebruiken, om aansluitend te kunnen werken.
Versimpeling van polygonen, wat hier en daar voor BGT noodzakelijk is.
Dat is best wel een lastige. Dat het structureel op dezelfde manier gebeurd. En tot dezelfde notatie leiden.
Stel je voert in eerste instantie niet het wegvlak in en na een tijd wil je dat wel toe voegen als landuse=highway.
Hoe makkelijk is het dan?
In dat kader de BAG import houd geen rekening met de mogelijke aansluitend BGT .
Het op basis van afstand (minimaal) samenvoegen van nodes.
Al zou de BAG en BGT in de basis over dezelfde notatie beschikken. Dat zou je dus eerst moeten onderzoeken.
Ik stel me voor dat er een landelijk OSM/BGT database moet zijn, waar de nodes voldoen aan de osm node structure opmaak.
Zou dat het werken makkelijker maken?
Vooraf vergelijking met osm building of bag building als node op een bepaalde afstand van elkaar liggen.
Welke node dan te gebruiken voor de OSM/BGT database.
Maar dan nog BGT nodes veranderen (positie).
Dat zien we ook terug in de BAG, de soms kleine veranderingen na inmeting.
De kwaliteitsslag, die de BAG de afgelopen jaren heeft gemaakt.
Ik heb ook eens de BAG gedownload (POSTGIS dumps van Just). Hieronder zie je een screenshot van QGIS met geel de BAG panden en paars de BGT panden. Daar zit dus ook al een verschil (6cm in dit geval). CRS is van beide lagen het zelfde. Vraag me niet waar dit verschil dan vandaan komt. Worden de coordinaten met een andere precisie opgeslagen ofzo?
Dergelijke hele kleine verschillen zou ik mogelijk kunnen oplossen in QGIS in de verwerking van de BGT. Dat ik de BGT laag naar de OSM panden laag laat snappen. Dat zou ik eens kunnen proberen. Weet niet of ik daarmee alle gevallen kan oplossen. Je moet natuurlijk opletten dat je geen serieuze geometrie fouten in de BGT introduceerd.
Verschil Panden BAG en BGT heeft m.i. met contour over/onderbouw te maken. Hans is iemand die daar veel over weet en schrijft, bijv:
Ik zou gewoon Panden uit de BAG nemen en die uit BGT negeren, dan is er 1 bron. Blijft dat de BAG een subset van alle âGebouwenâ of eigenlijk van âHuman-made-structuresâ, is, bijv recreatie-woningen/sta-caravans missen. In BGT zitten wel nog andere interessante structuur-sets zoals: âOverigBouwwerkâ (âopen loodsâ,opslagtank,âlage trafoâ,bassin,bezinkbak,windturbine, schuur,voedersilo,bunker) en mindere mate âGebouwInstallatieâ (luifel,toegangstrap,bordes).
Zonder nu de BGT af te vallen, zie ik vooral in de buitengebieden matige dekking, (is BGT een âUrbanâ ding?). Dat gezegd, wil ik een lans breken voor BRT m.n. Top10NL, in historie opvolger van TOP10Vector waar denk ik, ooit 3DShapes vandaan kwam, maar wel verrassend vaak âdekkendâ, zeker in buitengebieden, en rijkere classificatie.
Kijk bijvoorbeeld eens op deze kaart. Gaat over terugmeldingen maar kaart is de enige die ik ken die BRT (TOP1000NL-tot-TOP10NL) en BGT (Topo Style) composiet integreert (helaas in frontend) naar zoomlevel.
Je kunt met deze template de hele TOP10NL (WMS) eens in Id als âCustomâ background invoeren en kijken:
https://service.pdok.nl/brt/top10nl/wms/v1_0?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&FORMAT=image%2Fpng&TRANSPARENT=true&LAYERS=top10nl&CRS={proj}&STYLES=&WIDTH={width}&HEIGHT={height}&BBOX={bbox}
Het grote plan bij Kadaster/Geonovum is BRT.Next , waarbij BRT afgeleid wordt van o.a. BGT, wel een meerjarenplanâŠ
1 Like
BAG versus BGT ligging, gelijk?
Ja.
De basis.
BGT opgehaald via BGT download viewer als citygml import met BGTimport plugin in QGIS
BAG wfs en gpkg download, link een paar posts hier boven.
garage met overhangende verdieping.
Qgis in het laagste zoom niveau, ik zie geen verschil
Zo ook bij panden waar de vorm van polygon BGT en BAG gelijk zijn.
Mag ik de conclusie trekken dat BGT gebouwen en BAG gebouwen in de basis, de hoeknodes als coördinaten gelijk zijn?
Het proces er na is bepalend.
Bij voorbeeld voor het aansluitend kunnen werken, wat wel een voorwaarde is.
Wellicht als eerste aanzet voor een BGT import; maar verlies je dan niet een detailniveau die je in OSM juist wel wilt hebben?
Volgens de BAG is bijvoorbeeld in Amsteram Overhoeks de nieuwbouw "The Cube"en âThe Wingâ Ă©Ă©n gebouw:
Terwijl dit de grondomtrek van de onderliggende parkeergarage betreft; terwijl ede twee appartmenten complexen (met balkons) en daktuin op maaiveld niveau goed laat zien:
En in OSM ziet dat er een stuk beter Ă©n herkenbaarder uit dan Ă©Ă©n groot vierkan gebouw
BAG vs BGT vs OSM
Om me ook eens in dit onderwerp te mengen:
Ik vind dit een veelbelovend idee. De BGT is super nauwkeurig en in de meeste gevallen ook erg actueel, dus het is een goede bron voor imports.
voor gebruik van de BRP hiervoor.
Je zou nog de multipolygons individueel langs kunnen gaan. Veel landuse multipolygons hoeven namelijk geen multipolygons te zijn.
In deze mapping methode zie ik nog steeds geen toekomst. Tijdens een online meetup van enige tijd geleden werd een kaart getoond van vlakken met bebouwde kommen. De naam weet ik niet meer, maar als we die uitknippen langs grote wegen en langs landuse=commercial/industrial, lijkt me dit een betere kandidaat voor een landuse=residential import.
Is dit hetzelfde als de simplificatie methode in JOSM? Hoe groot is de maximum afwijking die je van plan bent te gebruiken?
Wat betreft de geschiedenis: je kunt ook zoeken naar vlakken die in de afgelopen 8 jaar (dus sinds de imports) niet zijn aangeraakt en gewoon niet de moeite doen om daarvan de geschiedenis te behouden. Misschien scheelt dat wat werk met conflation.
Al met al een grote voor de uitwerking van dit plan.
2 Likes
Wat bedoel je met dekking hier? De BGT is vlakdekkend voor heel NL dus heel NL is met een vlak bedekt.
En hoe is dit voor andere panden? Is deze correctheid nu een toevalligheid? Doet de BGT downloader nog een nabewerking?
Ik verwijder nu ook best multipolygonen weer. Soms zit er ook ergens 1m2 aan verharding wat mijn inziens geen meerwaarde voor OSM heeft.
Hiermee is er ook voor de buitengebieden een geometrie beschikbaar voor bijvoorbeeld farmyards. Het script koppelt er nu landuse=residential aan dus dat moet dan zelf even worden aangepast. En origineel was het script voor me zelf gemaakt en ik map die landuse wel op die manier. Tijdens een import kan dat gwn in JOSM uitgezet worden middels een filter.
Het script heeft nu een threshold van 3cm. Als je tussen 2 punten een lijn trekt en 3cm bufferd, dan wordt een tussenliggend punt binnen die buffer verwijderd. In realiteit is het een veel complexer simplificatie script. Het script verwijderd geloof ik ongeveer 25% van de nodes met deze instellingen.
Het is overigens een QGIS model en ik ken verder de simplificatie functie van JOSM niet
1 Like
Dit is mij iets te kort door de bocht. Ik denk dat we kunnen stellen dat de datakwaliteit van de BGT nogal verschilt per bronhouder (meestal gemeente). In sommigen is het erg goed (heb ik me laten vertellen) maar in sommigen ook zeer matig en verre van actueel. Hier een voobeeld uit Leusden. Daar is volgens de BGT slechts een paar honderd meter ruiterpad te vinden terwijl er in de praktijk tientallen kilometers ruiterpad ligt. En van die paar honderd meter BGT is de helft niet eens juist want dat is een fietspad.
Mijn ervaring met BGT terugmelding hier in Leusden is dat het jaren duurt voordat het aangepast is.
Hier het plaatje met zwart de BGT ruiterpaden en rood de OSM ruiterpaden.
1 Like
Om bij Peter aan te sluiten, zie ook onderstaand voorbeeld:
Het geselecteerde vlak staat in de BGT als onbegroeidterreindeel â erf. In werkelijkheid is het een moeras en marsh en is het aangesloten aan de natuur boven dit vlak (link). Hier heb ik best veel werk gehad om de BGT om dit hele gebied te importeren omdat het op OSM veel beter was ingetekend en ik dat natuurlijk wou behouden. De BGT heeft geen tegenhanger van wetland=marsh.
Wat ik ook al heb gezien is de wisselwerking tussen struiken en bos. Vaak wordt iets in de BGT als struiken aangegeven terwijl het echt veel meer neigt richting bos.
En om hierbij aan te sluiten: de BGT geeft vaak paden en tracks in bebost gebied aan die of tientallen meters van de werkelijkheid afwijken (AHN) of gewoonweg niet (meer) bestaan. De BGT als uitlijnhulp (geen import dus) voor straten in bebouwd gebied: prima, maar voor de rest zou ik toch de uiterste voorzichtigheid willen betrachten.
Net heel veel panden in Apeldoorn west bekeken,
Ik kon op het oog geen verschil zien. Wel andere verklaarbare afwijkingen, overhangende verdiepingen historische data.
BGT downloader niet gebruikt handmatig de file gedownload en dan via bgt import in qgis gezet.
@Cartographer10 Ja dat weet ik, vlakdekkend, geen âwitte plekken op de kaartâ. De term heb ik hier verwarrend gekozen: ik bedoelde, zoals in meerdere antwoorden hierboven: BGT is vaak âonvolledigâ en âfoutiefâ, âmist granulariteit in classificatieâ, is gemeente-afhankelijk maar leemtes vooral in buitengebieden.
1 Like
Ha, @OttoR hmm, misschien mijn stellige bewering eens herzien. In de BGT werden op gegeven moment de BAG Panden opgenomen (in GML in een âBAGâ XML Namespace, heeft @fsteggink nog extra code voor moeten schrijven voor NLExtract). Ik dacht integraal opgenomen, maar altijd achterlopend. Dat BAG âoverhangâ en BGT Pand âonderhangâ (grondvlak) als contour aanhoudt wist ik min of meer wel, maar niet dat dit zo dramatisch zou zijn. Een Pand is een Pand, heeft een BAG Id, zou denken dat je daar niet zomaar in âsnijdtââŠMaar denk dat een Pand in BGT meedoet in de âvlakdekkingâ (?) en heeft ârelatievehoogteliggingâ.
Ik ging ook uit van de bestaande BAG processen/imports in OSM, de hogere actualiteit in BAG, de pandstatus, gebruiksdoelen (in BAG via VBO af te leiden). Maar bij die heel grote structuren idd dramatische verschillen, zo leer ik ook weer wat!
Ik zie bijv het Rijksmuseum in Aâdam (links BAG, rechts BGT):
Het Pand âRijksmuseumâ heeft BAG Id â0363100012237298â, maar lijkt in BGT opgeknipt, beide helften zelfde id. Maar grappig, tegelijk zie je in BGT linksboven een Pand missen (PC Hoofdstr 5) en in BAG gestippeld (ja, is de map5topo kaart met BAG Panden). Dan heeft het Pand een status zoals âBouwvergunning verleendâ, of âBouw gestartâ en stippel ik de Style. Dan komen we wat op terrein van @Dillen_GJ : moeten we Panden die in dergelijke âstateâ, in planning, meenemenâŠ?
@justb Hier staat het wel aardig uitgelegd. BAG en BGT hebben andere doeleinden.
De BAG neemt geen bouwwerken op die geen vier muren hebben; terwijl de BGT dit wel laat zien (zoals een kapschuur). In het verleden werden zo ook siloâs door Amsterdam wel opgenomen in de BAG (zie bijvoorbeeld de Olie terminal in Westpoort); maar nu is de richtlijn dat dit niet meer gebeurd. In de BGT worden die dan (soms) weer wel weergegeven. En in OSM hebben we de vrijheid om die twee bronnen te combineren.
Nu is Amsterdam erg nauwkeurig in het op orde hebben van beide bronnen; dus dat helpt
Het Science Park geeft ook wel een aardig voorbeeld van BAG vs BGT:
Bouwdeel F ziet er op PDOK zo uit:
Uit de BAG:
Uit de BGT:
Op Mapiillary:
En ingetekend is het dus dit geworden; maar zonder de BGT omtrek gericht; had ik de grondgebonden ingang nooit zo nauwkeurig kunnen intekenen :-). Laat staan de weg eronder door, de grindvlakken, de fietsenstalling en de pilaren van de loopbruggen:
1 Like
Kortom, alle bronnen bekijken plus survey, en dan naar beste weten intekenen.
Bij een semigeautomatiseerde import zou dit op de âhandmatig afwerkenâ lijst moeten komen.