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.
Goed bezig ! 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
(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,
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.
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.
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.
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.
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.
Heb nu eens een aantal importen gedaan om te kijken waar ik tegen aanloop. Hier mijn bevinding:
Enkele voorbeelden (beide changesets hebben ongeveer een uur gekost):
Eigenlijk loop ik steeds tegen de 3 zelfde problemen aan.
BAG vs BGT
In bebouwd gebied merk ik dat ik erg vertraagd wordt doordat de BAG panden en BGT panden kleine beetjes verschllen. Aangezien ik het toch goed wil hebben kost het veel tijd om alles netjes op elkaar te laten aansluiten zodat er geen overlap is.
Aansluiten op bestaande geometrie
Geregeld moet ik de BGT laten aansluiten op bestaande geometrie. Er zijn redenen waarom je bestaande geometrie wilt behouden (even los van de bag panden). Zo kan het zijn dat je importeerd in blokken (je moet ergens een grens trekken). Ook is de BGT geometrie soms fout en is de geometrie in OSM beter. Die wil je dan natuurlijk behouden
Foute classificaties BGT
Er zijn dingen in de BGT die heel anders of met minder detail worden geclassificeerd in de BGT. De BGT heeft bijvoorbeeld geen versie van wetland=marsh of wet_meadow (alleen reedbed, saltmarsh en swamp). Marsh en wet_meadow worden echter in NL geregeld gebruikt. Vaak maakt de BGT er dan water of grasland van.
Daarnaast moeten zoals eerder uitgelegd landbouwvelden en de ondersteunende water- en wegdelen aanvullend worden geinterpreteerd. Ondanks dat het vaak een goede benadering is, klopt er ook geregeld geen hol van.
Er zijn ook geregeld vlakken met waardeOnbekend. Soms kan ik in het script een schatting maken op wat het meeste voorkomt maar vaak ook niet. Door deze en bovenstaande “fouten” moet ieder vlak handmatig visueel gecontroleerd worden bij het importeren. Dit is erg tijdrovend.
Afsluiting
Ik betwijfel of we een proces opgezet krijgen waarmee we met redelijke snelheid de BGT kunnen importeren die ook aan onze kwaliteitseisen voldoet. Binnenstedelijk sowieso niet door de BAG panden vs BGT panden. Ik moet zeggen dat ik het persoonlijk wel fijn vind om de BGT te gebruiken bij eigen mapping activiteiten. Of ik nu de BGT overteken of over kopieer. Hierdoor kan ik sneller werken om de 3dshapes uit te roeien.
De ervaring die iemand heeft die zelf meters heeft gemaakt is eigenlijk niet te evenaren zonder dat zelf te doen, dus ik verwacht dat je weinig zinnige feedback gaat krijgen
Het verschil tussen BAG/BGT is me ook al opgevallen en vervelend, dat zou de overheid wel beter kunnen doen.
Jammer, dat het lijkt dat een proces opzetten waarmee we met redelijke snelheid de BGT kunnen importeren niet echt realistisch lijkt. Ik zou graag zien dat zeker in landelijk gebied heel wat meer sloten worden toegevoegd.
Zit wat in maar het is niet alleen over het daadwerkelijke importeren maar ook wat ik tegenkom bij het voorverwerken
Als je hele grote gebieden hebt met argrarische gebieden zal het zeker wat sneller gaan. Maar in mijn voorbeeld (wat volgensmij best typisch NL is) heb je veel afwisseling tussen landbouw, natuur en bebouwing.
! 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.
