Rectificatie van bovenstaande in die zin dat het niet letterlijk zo geschreven is. Ik heb een hele zwik berichten samengevat in een zin en tussen aanhalingstekens gezet. Het stond er dus niet letterlijk zo.
Sterker nog, niemand heeft het zo bedoeld. Blij dat je hier even op terugkomt!
Een manier om verschillen tussen BAG en BGT panden te vinden is om van beiden de oppervlakte te berekenen en kijken of verschillen zijn > x%. In BGT ligt BAG ID vast dus een sql join hoeft niet gemaakt te worden met een geo functie. Het betreffende pand valt ook in de selectie. Bij een verschil van 20% oppervlakte zijn er 76000 panden (als ik geen fout maak 
)
Oh nee?
De realiteit is in ieder geval dat mensen naar Verbeterdekaart worden gestuurd zoals hier en hier.
Sinds ik dit topic heb gelezen en dingen aan het bijwerken ben denk ik regelmatig, zou dat niet kunnen door een BGT object te gebruiken in plaats van het bestaande OSM object uit te lijnen of zelf overtekenen van de BGT omtrekgericht.
Mijn doel is om te beginnen was simpel, gewoon één OSM object vervangen door de BGT shape.
De eerste stappen heb ik gezet:
- Een BGT GML extract gemaakt via PDOK download viewer voor het gebied waarin ik geïnteresseerd ben
- De BGT_extract.zip uitgepakt
- Dat levert 35 *.gml files op, de 6 grootste:
bgt_wegdeel.gml
bgt_pand.gml
bgt_begroeidterreindeel.gml
bgt_onbegroeidterreindeel.gml
bgt_vegetatieobject.gml
bgt_put.gml
Op basis van de openingspost begroeidterreindeel in QGis geopend, Open Data Source Manager (Ctrl+L) en daar onder Source bgt_begroeidterreindeel.gml als Vector Dataset opgegeven. Na “Add” en inzoomen levert dat op:
Dat komt prima overeen.
NB: Bij de PDOK download kan je ook ook de download beperken tot begroeidterreindeel alleen.
QGis gebruikt onder water OGR on dingen te lezen, voor de volgende stap:
Commando:
> python3 -m ogr2osm -e 28992 bgt_begroeidterreindeel.gml
Using default translations
Preparing to convert 'bgt_begroeidterreindeel.gml' to 'bgt_begroeidterreindeel.osm'.
Warning 1: Unrecognized geometry type : -2147483648
Unhandled geometry, type 10
<repeated 2170 times>
Unhandled geometry, type 10
Splitting long ways
Writing file header
Writing nodes
Writing ways
Writing relations
Writing file footer
Daarmee krijg ik een .osm file en als ik die in Josm laadt dan zijn redelijk wat objecten daar maar niet het object dat overeen komt het het OSM object dat ik wilde bijwerken. Even gekeken wat dat type 10 is maar dat is type CURVEPOLYGON dus daar ook maar ondersteuning voor toegevoegd. Verder een SimplifyPreserveTopology toegevoegd om “3. Puntdichtheid BGT” zoals genoemd in de openingspost te verlagen.
Verder op basis de tabel van de openingspost en de waarden die voorbij kwamen een translation subclass aangemaakt, die ook BGT objecten met een “eindRegistratie” datum verwijderd.
Daarmee krijg je een .osm file:
Ziet er goed uit wat mij betreft.
Wel zie ik nog objecten die in OSM als één object horen bestaan regelmatig uit meerdere BGT objecten bijv. de twee rood geselecteerde objecten. Op te lossen met Josm Join overlapping Areas (Shift-J) maar BGT omtrekgericht heeft daar geen last van en die functionaliteit zou ook door het script gedaan moeten worden.
Daarna is het nog steeds te vraag wat een goede Josm werkwijze is. Je kan dat .osm bestand als aparte laag openen maar je wilt zeker niet die objecten zomaar opladen. Kopiëren naar een andere laag kan maar dan blijft wel de shape maar niet de locatie niet behouden.
Wat ik nu heb gedaan is in de nieuwe laag de bestaande OSM data downloaden, dan de objecten vervangen met Replace Geometry en dan de vier bijgewerkte objecten en drie nieuwe objecten geselecteerd en daarna Upload selection, resultaat.
Verre van een makkelijke werkwijze en ik denk te makkelijk om fouten te maken. Ik zou veel liever BGT objecten in de huidige edit laag laden of een object selecteren en dan “replace by BGT geometry” uitvoeren.
2 Likes
Lekker bezig 
Als je in JOSM wilt plakken in een nieuwe laag en op de zelfde locatie dan kan dat met Ctrl+Alt+V.
1 Like
denk je dat je dat ‘BGT objecten in de huidige edit laag laden’ kunt scripten? Please?
Kan aan mij liggen, maar het is toch niet handig om een hele laag objecten zomaar in je gebied te plempen? Ik denk meer aan precies aangeven welke objecten ik hebben wil en die dan inplakken, dus met Control-klikklikklik… en Control-C in de ene laag, dan Control-Alt-V in de andere laag, en dan de detailinpassing doen.
1 Like
Je hebt gelijk. Die tussenlaag hebben we nodig. Maar ik zou zo graag die scripting hebben die een geselecteerde rechthoek uit de BGT naar de tussenlaag haalt. Dan kan ik zelf daar wel selecteren wat ik naar de edit laag doorlaat. Al was het maar alleen de geometrie
Bedankt @PeeWee32, Ctrl+Alt+V, Paste at source position is de truc.
Een stukje mee gedaan, dat is de werkwijze die @Peter_Elderson beschrijft en dat werkt aardig, een stuk beter dan de eerdere werkwijze van OSM data laden over de BGT laag heen.
Toch vindt ik dat nog moeilijk, voor het wisselen van een Layer is niet echt een shortcut. Als ik de OSM Layer actief heb en de “BGT layer” visible is dan is de BGT layer slecht zichtbaar:
Hier is het nog wel te doen maar bij complexere situaties eigenlijk niet.
Verder moet de BGT conversie echt nog wat opgeschoond worden:
- Gelijksoortige objecten samenvoegen
- Soms zijn er overlappende objecten
- BGT geometrie fouten (punt 5 in the openingspost)
- Classificatie van vlakken (punt 4 in the openingspost)
- De hack voor CURVEPOLYGON werkt veel beter dan ik had gedacht, maar ik heb er al wat problemen mee gevonden, het zou anders moeten.
Ja, dat is denk ik wat je zou willen kunnen en je kan Josm scripten dus mogelijk moet het ook zijn. Hoe moeilijk het is weet ik niet.
Ik dacht dat je de doorzichtigheid van een layer kan instellen (per sessie) en je kan toch met een enkele klik de aktieve laag wisselen?
Als het toch te ingewikkeld wordt, bijvoorbeeld een pedestrian area overdekt alles, klik ik de aktieve datalaag wel eens even weg.
En dan staat er 1 element in.
Maar dan:
De volgende keer na afsluiten josm.
Of ook een nieuwe gml opgehaald en bewerkt.
Aansluitend werken, andere elementen tussenvoegen.
Die problematiek ben ik al tegengekomen tijdens DTB gebruik.
En dat is al een tijdje geleden.
De gml begint met Rijksdriehoek uiteindelijk komen we bij OSM data uit.
Met een bepaalde stuctuur.
7 decimalen WGS84 projection
Het proces van projectie omzetting en afronding, hoe de OSM database het opslaat, hoe JOSM het terug krijgt, het toevoegen/invoegen van elementen, welke nodes liggen op dezelfde plaats, die met een fix aan elkaar te koppelen zijn.
Dit proces moet duidelijk en hetzelfde zijn, voordat, je zelf en andere in de toekomst aansluitend en invoegend zo min mogelijk problemen ondervinden.
Wanneer maken we de omzetting naar wgs84 7decimalen, doen we dit vooraf met heel de BGT of aan het eind bij opslag in OSM.
Het lijkt mij, dat een voor ons alle opvraagbaar OSM data structuur beginbestand, de minste problemen op zal opleveren.
We zien in bovenstaande posts, het begint met het bronbestand, vele programma’s die worden gebruikt, met hun eigenschappen, omzettings methodieken, tussentijdse opslagen in projectie(?) met hoeveel decimalen(?).
Welke problemen gaan we ondervinden?
Vooral als eenieder zijn eigen route gaat volgen.
Met die zoektocht was ik bezig.
BGT in een zo vroeg mogelijk stadium omzetten naar WGS84 7 decimalen.
Ik zie dan meer in een soort van BGT_extract OSM notatie.
Wel lettend op dat dit bestand geopend in een ander programma en wederom opgeslagen, dat de projectie opmaak niet veranderd. Een voorwaarde.
Neem ik nu een adress veld uit @justb zijn post
Dan zie ik daar ik 10 cijfers achter de komma voor de lat en 12 voor de lon
Dit is dan in OSM node
Hierbij is er voor gekozen om bij upload in OSM databank, daar de omzetting afronding te laten verwerken.
Dan krijg je dus deze verschillen.
Met shift-D in JOSM lat=“38.8477488903” lon=“-0.161647179237” toegevoegd.
Zo ook als je dit met polygonen doet.
En later aansluitend/invoegend wil werken.
Wat zijn jullie gedachten?
Dit als toevoeging op.
Naar mijn idee is dat een klein probleem, het grotere probleem is dat BGT dat wat betreft de geometrie van vele objecten een CurvePolygon is.
Dat betekend dat de geometrie wordt beschreven met (meerdere) segmenten van cirkels.
De OSM data structure ondersteund geen curves dus deze curves moeten vertaald worden in line-strings/ways en daarmee is de geometrie niet meer 100% hetzelfde. Verder is er “3. Puntdichtheid BGT” zoals genoemd in de openingspost.
Ook eerder genoemd, meerdere BGT objecten samenvoegen. Dat is naar mijn idee noodzakelijk, zelfs BGT omtrekgericht laat soms één object zien dat uit meerdere objecten in de BGT dataset bestaat.
Ik kan je gedachtegang wel volgen. Als we ons even zouden beperkten tot de vlakken BGT dan is het zaak dat deze allen aansluiten en geen overlap en gaten opleveren. Daarnaast denk ik dat deze ook een geometrie versimpeling zouden moeten/mogen krijgen maar daarbij is het van belang dat aansluitende polygonen de zelfde versimpeling krijgen om netjes aan te sluiten. Dat is volgens mij best een uitdaging. Op de postgisdag van vorige week liel Tom van Tilburg nog wel zien dat de nieuwe OGC postgis functie
daar een oplossing voor zou kunnen zijn.
De BGT curve polygonen leveren daarbij een probleem op dat getackeld zou moeten worden en dat lijkt in postgis te lukken. Zie o.a. deze post op het geoforum.
Ik denk dat het mooi zou zijn als analoog aan het voorbeeld uit Spanje er een aantal .osm files klaar zouden staan voor mappers om in JOSM te openen in een aparte laag en van daaruit OSM bij te werken. Dat zorgt er in ieder geval voor dat gebieden waar mappers te maken krijgen met anderen mappers de vlakken netjes aansluiten.
1 Like
Om dit punt te ondersteunen: ik ben overal in het land de trailheads aan het nalopen, en het valt mij op hoe ontzettend fout, achterhaald en gefragmenteerd het op veruit de meeste plekken is. Er zijn wel goed aangepakte stukken, maar echt, het is een druppel op de gloeiende plaat als je het hele land doorgaat. Tevens, dat waar het wél goed of in ieder geval min of meer bijgewerkt is, dat de 3Dshapes sourcetags meestal domweg zijn blijven staan. Dus bij opsplitsen hebben de delen allemaal de 3Dshape-tag behouden. Dat betekent dat je niet kan filteren op die tag om te bepalen (of zelfs maar de waarschijnlijkheid verhogen) dat iets gecheckt of aangepast moet worden.
Ander punt is het landgebruik van het platteland. Er zijn best stukken die goed blijven, maar ontiegelijk vaak zijn akkers weilanden geworden en omgekeerd, en omzettingen bomen naar gras, boomgaard naar gras of bos, kassen naar gras en omgekeerd, horticultuur naar akker, etcetera. Boerenland wisselt kennelijk heel sterk wat ze ermee doen. Ik vraag me dus serieus af of dit wel zinvol is om onderscheid te blijven maken, of dat we misschien een veel grovere kategorie voor boerenland moeten gebruiken waar akkerland, weiland, hooiland, bomen- en plantenkwekerij en tuinbouw allemaal onder vallen. Zomaar een gedachte.
Het gebruik en dus ook de periodieke gewaswisseling van het platteland wordt al keurig bijgehouden.
Dit kun je ook gaan importeren. :- )
Ik begrijp je punt en dat is niet alleen relevant bij (kleinschalige) import maar ook bij onderhoud. Vandaag hadden @justB en ik een overleg met een paar mensen van het Kadaster over BGT datakwaliteit. Dit op mijn verzoek omdat ik toch best veel issues zie in BGT (en ook OSM) als ik de 2 datasets vergelijk. Met name in het buitengebied zie ik heel veel issues in BGT.
Het kadaster heeft te maken met heel veel bronhouders. Dat zijn m.n. de gemeentes. Die gemeentes hebben uiteraard hun eigen prioriteiten en die liggen niet in de buitengebieden. Gemeentes hebben te maken met onderhoud en dan zijn voornamelijk de wegdelen en het gemeentegroen belangrijk ook o.a. voor uitbesteding (de vierkante meters). Terugmeldingen hierop hebben dan ook vaker prio boven die van de buitengebieden zoals bos, akkers en ruiterpaden.
Als ik kijk naar begroeid terreindeel dan zijn er alleen al 16 soorten BGT_fysiekvoorkomen. Als die ook nog worden uitgesplitst naar plus_fysiekvoorkomen dan worden het er al 33. Als we dat laatste niveau zouden gaan gebruiken en omzetten naar OSM tags dan vraag ik mij af wie dat in OSM wil gaan bijhouden. Dat nog even los van de vraag of het bijhouden uit de BGT heel zinnig is omdat daar de datakwaliteit/actualiteit te wensen over laat in m.n. het buitengebied.
Ik denk dat het al heel mooi zou zijn als we iets kunnen verzinnen voor BGT fysiekvoorkomen. Lijkt mij al uitdaging genoeg
| bgt_fysiekvoorkomen | plus_fysiekvoorkomen |
|---|---|
| boomteelt | waardeOnbekend |
| bouwland | akkerbouw |
| bouwland | bollenteelt |
| bouwland | braakliggend |
| bouwland | vollegrondsteelt |
| bouwland | waardeOnbekend |
| duin | gesloten duinvegetatie |
| duin | open duinvegetatie |
| duin | waardeOnbekend |
| fruitteelt | hoogstam boomgaarden |
| fruitteelt | klein fruit |
| fruitteelt | laagstam boomgaarden |
| fruitteelt | waardeOnbekend |
| fruitteelt | wijngaarden |
| gemengd bos | waardeOnbekend |
| grasland agrarisch | waardeOnbekend |
| grasland overig | waardeOnbekend |
| groenvoorziening | bodembedekkers |
| groenvoorziening | bosplantsoen |
| groenvoorziening | gras- en kruidachtigen |
| groenvoorziening | heesters |
| groenvoorziening | planten |
| groenvoorziening | struikrozen |
| groenvoorziening | waardeOnbekend |
| heide | waardeOnbekend |
| houtwal | waardeOnbekend |
| kwelder | waardeOnbekend |
| loofbos | griend en hakhout |
| loofbos | waardeOnbekend |
| moeras | waardeOnbekend |
| naaldbos | waardeOnbekend |
| rietland | waardeOnbekend |
| struiken | waardeOnbekend |
Werkt dit beter dan om het als laag in te laden en dan te mergen met de “active laag” om dan de vlakken te vervangen middels ctrl-shift-g (replace geometry)?
Voor mij wel, maar dat zou wel eens van geval tot geval kunnen verschillen.
Met het kopiëren van de BGT laag naar de edit laag met Ctrl+Alt+V, Paste at source position gebruik ik nog steeds ctrl-shift-g (replace geometry) om voor bestaande objecten de geometrie te vervangen door de BGT geometrie.
Zodra het conversie script een stuk verder is wil ik wel wat .osm files generen voor iedereen die dat wil zodat meer mensen eens wat kunnen proberen, maar dat kan nog wel een tijdje duren.
Ik ben ernaar aan het kijken, maar ik heb wat moeite met die waardeOnbekend. Ik denk bij bv naaldbos waardeOnbekend, dat naaldbos gewoon niet verder onderverdeeld is in soorten.
Maar bij akkerbouw staan specifieke vormen van akkerbouw, en vervolgens ook nog waardeOnbekend.
En verder snap ik het door elkaar gebruiken van uiterlijk en functie niet. Bouwland is een functie, maar duin is geen functie.
En dan zijn sommige dingen in de eerste kolom al onderverdeeld, en andere in de tweede kolom. Bijvoorbeeld grasland agrarisch en grasland overig zijn apart, elk met waardeOnbekend erachter, waarom is dat niet grasland en dat onderverdeeld in - agrarisch en - overig?
Onder meer daarom vind ik de tabel niet een op een vertaalbaar naar OSM.
Bijvoorbeeld duingebied, daar vind je naaldbos, loofbos, heide, grasland, scrubland en struikgewas, en open stukken zand. “Gesloten duinvegetatie” zegt mij niet wat het is. Overstappen op een grove indeling open duinvegetatie en gesloten duinvegetatie doet MI geen recht aan de kaart. Voor onderhoud van de gebieden zal het wel een belangrijke indeling zijn, maar we maken geen specifieke onderhoudskaart.