Voorverwerken BGT voor import in OSM

Ik ben de laatste tijd bezig geweest om de BGT voor te verwerken tot een dataset die importeerbaar is in OSM. Ik wil gewoon eens delen wat er allemaal bij komt kijken om de BGT voorverwerkt te krijgen. Mochten jullie vragen of feedback hebben dan hoor ik dat graag.

Misschien als eerste, Ik laat die voorverwerkte laag in JOSM in. Vervolgens controleer en kopieer ik ieder vlak handmatig voordat ik de geometrie overkopieer naar de OSM laag. Daar pas ik het waar nodig ook nog aan. Ik gebruik het nu dus om mijn mapwerk te ondersteunen en ik importeer niet blind zeg maar.

Nu naar de BGT. De BGT heeft verschillende lagen (zoals panden, begroeidterreindeel, waterdeel, ondersteunend waterdeel etc). Ik ben gewoon al die lagen een voor een gaan toevoegen aan het model. Een deel van de gegevens kunnen gewoon qua attributen gemapt worden. Bijv begroeidterreindeel grasland overig → landuse=grass + landcover=grass. Bij de bossen geeft de BGT mooi aan of het naaldbomen, loofbomen of een mix zijn. Naar koppel ik dan bijv de tags natural=wood, landcover=trees, leaf_type=*, leaf_cycle=*.

In onderstaande tabel heb ik een aantal van die simpele mappings gezet.

BGT laag BGT fysiekvoorkomen Plus fysiekvoorkomen BGT Type BGT plus type OSM tags
Begroeidterreindeel grasland overig - - - landuse=grass + landcover=grass
Begroeidterreindeel gemengd bos - - - natural=wood + leaf_type=mixed
Begroeidterreindeel loofbos - - - natural=wood + leaf_type=broadleaved + leaf_cycle=decidious
Begroeidterreindeel naaldbos - - - natural=wood + leaf_type=needleleaved + leaf_cycle=evergreen
Begroeidterreindeel groenvoorziening bosplantsoen - - natural=wood
Begroeidterreindeel fruitteelt - - - landuse=orchard
Begroeidterreindeel struiken - - - natural=scrub
Begroeidterreindeel groenvoorziening heesters OF waardeOnbekend OF bodembedekkers - - natural=shrubbery
Begroeidterreindeel boomteelt - - - landuse=plant_nursery
Begroeidterreindeel zand - - - natural=sand + landcover=sand
Begroeidterreindeel groenvoorziening gras- en kruidachtigen - - landuse=grass + landcover=grass
Begroeidterreindeel moeras - - - natural=wetland + wetland=swamp
Waterdeel - - alles - natural=water
Waterdeel - - waterloop sloot natural=water +water=ditch
Waterdeel - - waterloop greppel, droge sloot natural=water +water=ditch + intermittent=yes
Wegdeel - - parkeervlak - amenity=parking + parking=street_side
Wegdeel - - spoorbaan - landuse=railway

Overige aandachtspunten
1. Landbouw
De landbouw vlakken zijn in de BGT vaak niet goed geclassificeerd. Daarom heb ik de BRP gewaspercelen gepakt en deze met de BGT landbouw vlakken gecombineerd. Ik hou dan de grens van de BGT aan (anders sluiten mijn andere vlakken niet meer aan) maar ik deel die landbouw vlakken dan op volgens de BRP.

2. Ondersteunend waterdeel
De BGT tekent overal oevers. Wat ik eerst doe ik kijken of een oever aan een stuk struikgewas of bos aansluit. Dan neem ik die landuse of natural waarde over. DIt om te voorkomen dat er een rare grasstrook naast waterlopen in bijvoorbeeld bossen komt. De rest classificeer ik als gras (voor nu)

3. Puntdichtheid BGT
De BGT heeft soms een erg dichte puntdichtheid in de BGT zitten. Ik gooi er een simplificeer algorithme overheen die de punten gaat uitdunnen met een minimale impact op de geometrie. Deze stap duurt net zo lang om uit te rekenen als alle voorgaande stappen omdat dit algorithme dit wel erg goed doet.

4. Niet geclassificeerde vlakken
De BGT is vlakdekkend. Er zijn dus ook vlakken die gewoon niet volgens het OSM model geclassificeerd kunnen worden, zeker niet als vlak (soms wel als lijn). Dit resulteert soms in gaten in je vlakken (met multipolygonen als gevolg). Bij mijn handmatige imports verwijder ik die weer. Maar dit automatisch oplossen is lastig goed te doen).

Sommige vlakken heb ik wel geclassificeerd maar die zijn twijfelachtige in sommige situaties. BIjvoorbeeld bij bgt_fysiekvoorkomen=groenvoorziening + Plus_fysiekvoorkomen=WaardeOnbekend OF bodembedekkers is me opgevallen dat ik dergelijke vlakken vaak als natural=shrubbery of zelfs als natural=wood zou mappen. Het model koppelt er nu natural=shrubbery aan maar dit is dus een van de gevallen waar handmatige interpretatie nodig is.

5. BGT geometrie fouten

Daarnaast bevast de BGT geregeld geometrie fouten. Op onderstaande afbeelding gemaakt in JOSM zie je dat er tussen de grasvlakken kleine gaten zaten. Toen ik alle grasvlakken heb samengevoegd was deze multipolygoon het resultaat. In het script heb ik dit nu opgelost door vlakken met een oppervlakte < 0,5m2 te verwijderen. Maar goed, dat lost niet alles op
image

Daarnaast moet ik voor ik de BGT exporeer eerst een fix geometries er over heen gooien. Dan gaat die geometrie fouten zoals self intersects verwijderen.

6. BAG panden vs BGT panden
De BGT bevat ook panden alleen die matchen niet altijd met de BAG. Bij de imports die ik nu dus heb gedaan heb ik geregeld de geometrie van de BGT moeten aanpassen zodat die niet overlappen met de BAG panden die bij ons leidend zijn.

7. Residential landuse vlakken
Ik doe geregeld het landgebruik ook gedetailleerd mappen. Wat ik heb gedaan is de BGT onbegroeidterreindeel > erf + de BGT panden gepakt en die geometries samengevoegd. Dan krijg je bijvoorbeeld onderstaande. Bovenstaand punt 6 is van toepassing dus soms zijn aanpassingen maar dit geeft wel een mooie aanzet, zeker ook in buitengebieden. Ik heb nog niet de moeite genoemen om deze vlakken op te knippen naar gebruik (nu krijgen alle vlakken gewoon landuse=residential.

8. Parkeervakken
De BGT slaat ook parkeerplaatsen op. Alleen, er is maar 1 optie voor de BGT om een parkeervlak aan te geven. Die optie wordt gebruikt gebruik, voor wat wij in OSM zouden taggen als grote parkeerplaatsen, street_side parking en parking_spaces. Voor nu heb ik gewoon gezegd, alle parkeervlakken zijn amenity=parking + parking=street_side. Mogelijk dat ik in de toekomst obv grote van het vlak een ander voorstel kan doen of iets street_side parking is of een individuele parkeerplaats.

9. Importeren
Zoals al gezegd, ik gebruik dit bestand om mijn map werkzaamheden te ondersteunen. Er is ook wel vaker gesproken over grootschalige BGT imports. Ik moet zeggen, daar komt veel bij kijken. Het beste kun je dan een gebied (met 3dShapes) het beste leeggooien en de BGT importeren. Maar, met wat handmatige interpretatie kan het wel prima ondersteunen bij het updaten van een gebied.

Daarnaast, is het ook nog het principe van geschiedenis behouden. Als het 3dShapes zijn dan geef ik in dit geval niet om de geschiedenis. In andere gevallen probeer ik de geschiedenis te behouden.

Daarnaast kan het zijn dan een gegeven vlak al gedetaileerder is gemapt (qua attributen). Dan moet je ook handmatig dingen oplossen om het harde werk toch te behouden maar de geometrie te updaten.

10. Overig
Ik heb het model in QGIS gemaakt (met Python). Het zijn vooral een hoop tools achter elkaar plaatsen die velden berekenen, met uitzondering van bovenstaande punten.

Hieronder wat voorbeelden van changesets waar ik de BGT als importbron heb gebruikt:

5 Likes

Indrukwekkend !

Goed bezig hoor. Geeft ons een mooi inzicht in wat er komt kijken als we BGT wat grootschaliger zouden willen importeren. Dit bevestigt mijn beeld dat dit een zeer lastige zo niet onmogelijke klus is.

Zeker automatisch is het gewoon onmogelijk voorlopig als we een goede kwaliteitatieve import zoals de BAG willen hebben. Als handmatige steun vind ik het wel een erg goede dataset moet ik zeggen obv mijn testimports.

Ik wil ook nog eens een testgebied importeren in de buitengebieden. Zeker bij grote landbouwgebieden kan het mogelijk best goed omdat die vrij homogeen zijn. Dan moet ik de landbouwgebieden in mijn script nog iets verbeteren. Daarnaast moeten dan gewoon alle (landuse) vlakken in zo’n gebied worden verwijderd. Dan kun je de BGT er overheen importeren.

Dit gaat lastigere worden in gebieden waar mensen wel als aanpassingen hebben gemaakt. Om te voorkomen dat hard werk wordt vervangen door een mogelijk minder accurate BGT import.

Mooi werk @Cartographer10 ! De BGT is inderdaad nogal een “beest”. Ik ben er ook bijna dagelijks mee bezig voor de map5topo kaart. Overigens ook BRT (Top10NL Top50NL, Top100NL), maar kan schaalafhankelijk werken (bijv BGT alleen op zoom >= 18).

Ik zou ook graag BGT en BRT in OSM terugzien, de vraag is alleen wat een slimme aanpak is, m.n. voor toekomstig onderhoud. Is ingewikkelder dan de BAG. Maar per “thema” bijv “landcover” en een voorbewerking, lijkt mij goede richting.

Over “landcover”: m.i. in BGT is dit meer dan “Begroeidterreindeel” (bevat, zoals je laat zien, ook “landuse”, bijv orchard). Er is ook bijv “Onbegroeidterreindeel” (vraag mij niet waarom, er zit veel (GBKN) erfenis in BGT). Maar bijv een stuifzand zoals bij Soestduinen of op Veluwe is vaak “Onbegroeidterreindeel”. Daarnaast, zoals je noemt, is er “Ondersteunendweg/waterdeel”. Die betrek ik ook in “Landcover”, dus totaal 4 objecttypen.
“Gaten” zie ik ook wel, bijv in Wegdeel-vlakken, maar dat zijn weer plekken waar bijv “Vegetatieobjecten-vlakken” als bomen, in passen. Er zijn bijv “Hagen” als vlakken, bijv in coulisse-landschap.

Voert allemaal wat te ver hier, denk iets voor de komende Jitsi, mogelijk een werkgroep.

Klopt, ik focus me hier nu alleen op vlakken van bijv landgebruik etc omdat ik dat veel doe mappen. Het is niet strikt alleen maar landcover maar ook landuse en wat functioneel (zoals parkeervakken).

Over onderhoud, is het zelfde als 3dshapes. Je importeert het nu, dan ziet het erg weer netjes en up-to-date uit. Daarna is het aan mappers om dat gaande weg gewoon bij te houden. Ik denk (semi-)automatisch met een plugin ofzo update dat dat lastig is. Beetje het zelfde tijdrovende probleem waar ik nu tegen aanloop als ik geschiedenis wil behouden of als vlakken door andere mappers al eens zijn verrijkt.

Ik miste ineens ook wat zandvlakken. Bleken die in ongegroeidterreindeel te zitten terwijl ik alleen die in begroeidterreindeel had gemapt. Maar die gaten (ook in begroeideterreindelen) zijn best wel eens vervelend ja. Ze zorgen voor naar (mijn inziens) voor onnodige multipolygonen door onnodige detail toe te voegen voor osm. Hieronder zie je bijvoorbeeld kleine (groene) vlakken van bestrating, uitgesneden in een groenstrook (gras). Die kleine vlakken heb ik weggehaald bij het importeren maar dat was natuurlijk handwerk om een multipolygoon weg te werken.

image

Goed bezig :+1: ! Tijd die wordt geïnvesteerd om te kijken hoe we BGT goed kunnen inpassen in OSM kan zich dubbel en dwars terugverdienen. Ik merk vaak al als ik paden rechtleg dat ik dan geen puf heb om alle veel minder precieze 3dShapes landuse ook recht te leggen (monnikenwerk…) en denk "ik wacht wel tot we BGT gaan gebruiken.

Misschien mooi om deze methode ook hier vast te leggen in onze lijstje met toepassingen in de BGT-wiki

En misschien heb je voor je plannen in het buitengebied nog iets aan mijn ervaringen met de import van BGT-data van polderwater

(dat was aan mijn kant stilgevallen omdat ik geen intensief klikwerk meert kon doen, op zich was de BGT-data een grote vooruitgang ten opzichte van de bestaande OSM-data)

Naast het te grote aantal punten dat je al noemde viel me ook op dat de data in de BGT vaker in verschillende vlakken was gesplitst die we in OSM zouden samenvoegen. Daarvoor is in de data-voorbereiding een “dissolve” toegepast

Succes, mooi dat je hier tijd in steekt, en goed ook dat je oog hebt voor de relatie met bestaand werk in OSM. Ben benieuwd naar de voorstellen voor werkwijzen die hieruit gaan voortkomen!

Als we een goede methode vinden om BGT-landuse in OSM te verwerken dan kan er veel tijd vrijkomen bij mappers die we nu besteden aan verslepen van 3D-Shapes data voor de zaken waarin OSM meerwaarde kan hebben tov de BGT en andere bronnen,

2 Likes

Ah, goede. Ik wil eerst wat verder zijn en wat kleine testimportjes doen. Daarmee wil ik eerst een beter zicht krijgen op wat een goede aanpak is en het data verwerkingsscript afstemmen.

Dit is een goede. Aangrenzende vlakken binnen begroeidterreindeel (bijv aangrenzen bos- of grasvlakken) die voeg ik al samen (de BGT splitst ze bijvoorbeeld of ze op een helling liggen of niet).

Wat nog een openstaand punt is zijn de ondersteunende waterdelen (vooral taluds langs een waterlichaam). Ik twijfel nog of of ik dat zou samen voegen met het naastgelegen vlak als dat het zelfde type is (bijv allebij gras)

Ik zal sowiezo binnenkort wel eens een test dataset delen van eens stuk verwerkte BGT.

1 Like

Deze snap ik wel. Ik heb gister eens hier een flink stuk geimporteerd: achavi - Augmented OSM Change Viewer  [attic]

Of ik nu zelf als die vlakken overteken of gewoon meteen de geometrie uit de BGT kopieer maakt dan ook niets uit. Dit is sneller en dan kan ik ook de kleinere vlakken meenemen die ik normaal niet als zinvol zie.

Talud is een onderdeel van de sloot, dat moet je niet samenvoegen met farmland.

1 Like

Toen ik met BGT-data bezig was, heb ik inderdaad het farmland en de taluds waar gras op stond gescheiden, voorbeeldje

Dat heb ik ook weleens gedaan bij het inleggen van wandelroutes. Een pad over akkerland kan eigenlijk niet. Uiteraard uitzonderingen daargelaten. Maar langs veel watergangen ligt een schouwpad en dat is gras.

@Allroads, @multimodaal en @dvdhoven Dank voor de reactie. Kennelijk had ik mijn vraag niet duidelijk omschreven.

Tuurlijk, ik ga geen landuse=grass en landuse=farmland samenvoegen als die naast elkaar liggen. Het ging mij er om als er meerdere landuse=grass vlakken naast elkaar liggen. Bijvoorbeeld op onderstaande afbeelding. Daar liggen meerdere grasvlakken naast elkaar, allemaal uit verschillende BGT lagen. Die naast het water komt uit ondersteunend waterdeel en de rest uit ondersteunend wegdeel. Die 3 uit ondersteunend wegdeel kan ik samenvoegen maar moet ik daar dat talud van het water daarbij ook meenemen. Want waar leg je die grens. ZIe daarvoor maar eens afbeelding 2.

Bij onderstaande afbeelding heb ik alle vlakken met de zelfde tags samengevoegd (gedissolved). Daarbij ontstaan dergelijk ontzettend grote vlakken zoals de rood geselecteerde (landuse=grass). DIt lijkt mij ook ontwenselijk. Niemand heeft er wat aan dat het vlak zo groot en complex is.

Die waterkant is vaak ook riet (reedbed) in plaats van gras en soms wet_meadow.
Dus te fanatiek samenvoegen zou ik voorzichtig mee zijn. :slight_smile:

Wat in de BGT overigens ook nog welleens apart wordt gehouden is:

  • de zijkant van de weg: erg kort (gemaaid) gras op verharde (berijdbare) ondergrond. Niet per se grass_pavers.
  • de rest van het grasveld wat vaak wat langer groeit met bloemen e.d. erin en met een zachtere ondergrond.

Hiervoor is in OSM niet echt een onderscheid; maar ik volg hier altijd wel de BGT lijn en hou de twee vlakken gescheiden.

Goede constastering. Dan zal ik de dingen als ondersteunende weg- en waterdelen niet samenvoegen.

Bij de begroeide terreindelen heb ik dat momenteel wel gedaan. Dat komt omdat daar aparte vlakken zijn voor de verschillende liggingen (op een talud of niet). Bijvoorbeeld op onderstaande afbeelding zie je een stuk dijk. Alle bruine vlakken zijn gras, alleen liggen sommige op een talud of niet. Lijkt me zinloos die in OSM ook los te mappen.

Wellicht alleen om de lijn te gebruiken om een embankment aan te geven; maar dat is lastig te programeren vrees ik. Soms geeft de BGT hier een aparte lijn voor; maar zeker niet altijd.

Lijkt mij juist wel zinvol met name bij dijken, om aan te geven waar de dijk precies ligt, waar het talud begint en tot waar het talud reikt.
Voor dit soort ondersteunende delen zou ik liefst een extra tag toevoegen om de bijzondere eigenschap te specificeren. Dus bij een aflopende oever een tag voor oever (naast de tag voor de begroeiing of bedekking), en bij een dijktalud een tag voor dijktalud (naast de tag begroeiing of bedekking).

PS
Bij embankment had ik daar trouwens al een tag voor gesuggereerd (dus voor een area die een dijktalud voorstelt), al zou ik ff na moeten kijken welke precies. landuse=embankment:slope of zo. Da’s alleen lastig als er vee op graast, want dan moet het tegelijk landuse=meadow zijn… dus het zal wel iets anders geweest zijn.

Het is inderdaad alleen zinvol als er ook echt een onderscheidende tag aan wordt gehangen.

Ik wil nu alleen op vlakken focussen. Embankment wordt als lijn gemapt. Je kunt altijd de BGT omtrekgericht in JOSM er on hangen en de embankments er overheen tekenen.

PS dit was onderdeel van mijn nog uit te brengen embankmentvoorstel:

  • man_made=embankment:slope as tag for an area covering an embankment slope from upper edge (crest edge line) to bottom edge (toe line).

Dus dat zou de extra tag kunnen zijn voor begroeid terreindeel op een talud. Het is nergens strijdig mee, vziw, in ieder geval niet met de begroeiingstags.

Dat snap ik op zich wel; alleen als je de vakken wel importeert en niet samenvoegt; dan is de embankment heel simpel toe te voegen door de bestaande lijn te volgen; die anders door het samenvoegen verloren zou gaan.