Oke, daar zit wat in. Dan zal ik de dissolve voor begroeideterreindelen wel weghalen voor nu
1 Like
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):
- Buitengebied import: achavi - Augmented OSM Change Viewer [attic]
- Stedelijke import: achavi - Augmented OSM Change Viewer [attic]
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.
Ben benieuwd naar jullie mening over bovenstaande
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.
Waar kom het verschil qua gebouwen tussen BGT en BAG vandaan? Zou toch dezelfde bronhouder moeten zijn? En de BAG zou de basis moeten zijn voor de Gebouwen; dus zou dit leidend houden.
Met enige regelmaat kom ik hier achterstallig onderhoud door de Gemeente Amsterdam van tegen en dan meld ik dat daar terug via de PDOK API. Zij pakken dit eigenijk altijd erg voortvarend op.
Ik denk dat een import van de lijnen van vlakken van de BGT al best een vooruitgang kan zijn. Dan kan je via ctrl-g de betsaande vakken âcorigerenâ in plaats van zoals nu het handmatig volgen van een lijntje.
Zie hier de uitleg voor de verschillen: PND | Pand · IMGeo objectenhandboek De inwinningsregels zijn net iets anders.
Helemaal mee eens. Maar als je nu in bebouwd gebied gewoon alles er in plakt heb je veel overlap of net niet snappende geometrie met de BAG panden. ZOu het slordig vinden als dat niet wordt gefixt. Maar dat fixen kost veel handmatige tijd
1 Like
Ik heb een tijdje geprobeerd BGT area objecten als import te gebruiken (een voor een, in JOSM, object kopiëren naar de OSM datalaag). UIteindelijk was het voor de meeste objecten meer werk om het in te passen in de al aanwezige data, dan om het gewoon opnieuw te tekenen. De bestaande dat weggooien en dan een hele bak objecten importeren was ook geen optie, er zit teveel toegevoegd OSM-data aan vast. Vergelijkbaar met het probleem van de entrances bij de BAG-import, maar dan nog veel compliceerder. Uiteindelijk importeerde ik vooral waterobjecten en groenperken die in OSM nog niet bestonden, en dan inpassen in de bestaande landuse/natural met PolygonCutOut. En dan had ik nog steeds handwerk daarna omdat het bv kruiste met gebouwen en wegen.
1 Like
Maaiveld van huis en garage is BGT-geometrie.
De overbouw onder carport is BAG-geometrie. De carport zelf is geen BAG of BGT-inhoud en kan eventueel worden geclassificeerd als IMGeo-inhoud.
Deze carport is geen inhoud voor de BAG of BGT, het vormt immers geen onderdeel voor pand of vbo. Eventueel kan de luifel worden geclassificeerd als plustopografie in IMGeo.
Dan ben ik toch blij met de gegevens in beide Ă©n soms vanuit IMGeo. Want ik gebruik vaak de omtrek van de BGT om in OSM de gegevens uit de BAG te verrijken; bijvoorbeeld hier bij het EYE Museum:
Helemaal eens met net niet snappende geometrie; maar denk dat dit een keuze is tussen twee kwaden 
ik moet vaak uitleggen waarom OSM nog steeds zoveel handwerk is. Zelfs voor HOT/Missingmaps werkt AI/Automatisering vaak maar matig.
Toch blijft het frustrerend om een lijntje dat al in een database staat over te moeten trekken.
Zeker.Maar het is nog frustrerender om eindeloos na te moeten bewerken van een o zo gemakkelijke import, terwijl je het veel sneller nieuw zou kunnen tekenen. Bij het intekenen van water blijkt dat de BGT nogal wisselt van precisie en opvatting; je ziet dat de tekenaars ook verschillende keuzes maken wb de detaillering van de waterlijn; soms nemen ze de waterkant, soms nemen ze een stuk oever mee, soms volgen ze het water om een rietbed heen en soms volgen ze het land om het rietbed heen. Soms trekken ze de waterlijn heel recht, soms volgen ze precies de inhammetjes en uitsteeksels. Soms loopt de waterlijn onder een tuinvlonder door, soms eromheen.
âNatuurvriendelijke oeversâ zijn van nature erg onregelmatig en veranderlijk, dus daar slaan ze meestal maar een slag naar (net als OSM-mappers), maar ik vind meestal mijn âslagâ beter!
2 Likes
Hier eens een voorbeeld over wat voor een verschillen ik het heb. Hier heb ik een grasvlak uit de BGT gekopieerd, het pand kunt uit de BAG. Ik probeer dergelijke verschillen op te lossen maar dat is wel handwerk. Kan natuurlijk ook dat ik misschien hier te nauwkeurig wil zijn (1 pixel is 7,5cm bij 7,5cm ter referentie). Ik weet even niet of JOSM over deze overlaps gaat klagen.
En dit soort onnodige driehoekjes werk ik dan ook weg
1 Like
Het ondersteunendwaterdeel kent het principe van natuurvriendelijke oever helaas niet. Kwam ik gister ook achter. Heb handmatig maar wat vlakken op natural=wetland + wetland=reedbed gezet
1 Like
JOSM klaagt hier volgens mij niet over. (En ik ben er nog steeds voorstander van om de nodes aan elkaar te plakken als daadwerkelijk het gras tot aan de gevel loopt)
Ja; dat snap ik; maar als dit het ergte is; dan valt het toch wel mee?
Zeker mee eens. Maar dit vertraagt het importeren in stedelijk gebied enorm.
Zeker, maar dat is niet het ergeste denk ik. Voor het aansluiten op bestaande geometrie en misclassificaties in de BGT (gewone fouten of omdat het datamodel het niet ondersteund) zijn wat prangendere dingen.
Daarnaast, bij mijn testimports heb ik overigens veel bestaande data gewoon verwijderd, zeker als er 3dShapes als source bij stond of als ik de laatste editor was. Als we een BGT import doen moeten we accepteren dat bestaande geometrie beter verwijderd kan worden. Uitzonderingen daar gelaten natuurlijk. Als een stuk nauwkeuriger is gemapt door een mapper dan zeker behouden.
Met het verwijderen van de 3DShapes heb ik geen probleem; het was destijds een mooie massa import om het openbaar groen in te laden bij gebrek aan een beter detail niveau. Maar inmiddels is de BGT zĂłveel nauwkeuriger en de 3Dshapes zĂł outdated en soms ronduit niet correct, dat het behouden omwille van de historie / werk van ander niet echt van waarde meer is.
Ik zou al blij zijn met een JOSM plugin die alleen maar een S selected OSM wegdeel ophaalt uit de BGT en hem alligned legt waar ik dus kennelijk bezig ben, Dan hoef ik maar te kijken of hij goed ligt en anders een CTRL-Z om het alsnog met W te doen.
De enige revert (clean) die ik tot nu toe deed was mijn juiste (BGT en luchtfoto) handmatige allignment terugdraaien omdat hij er vandalistisch uitzag voor het golfterrein noord van Molenschot; Goorbergseweg
2 Likes
Kan je dat met voldoende zekerheid geautomatiseerd vaststellen?
Eens, en als daar dan tussen een niet 3dShapes object ligt wat al door een mapper is aangepast dan zou ik zeggen jammer dat voor dat ene vlak.
Korte antwoord: Nee
Langere antwoord: Zie bijvoorbeeld onderstaand voorbeeld. Het meertje staat in de BGT. Het gras eromheen is terecht als wetland=marsh gemapt op OSM. In de BGT staat dit echter als grasland met een ondersteunendwaterdeel om het meertje. Hier wil je toch echt het werk van de mapper behouden maar visueel constateren is de enige manier.
Ik vrees dat het massa importeren altijd nog de visuele controle nodig heeft.
Waarbij dan de meerwaarde van de import is dat het overeenkomt met een kwalitatieve bron.