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.
Ik snap je punt Peter. Ik had iet duidelijker kunnen zijn. BGT kent een verplicht en een niet verplicht deel (ook wel Plus genoemd) . Dat betekent dat soms alleen het verplichte deel gebruikt wordt en dat daar de “plus_fysiekvoorkomen” kolom de waarde “waardeOnbekend” heeft. Soms worden er wel plus waardes gebruikt en dan worden ze gevuld in dat tabelletje. Overigens maak ik dat tabelletje obv wat er momenteel in de BGT voorkomt. Als in theorie een pluswaarde ‘eikenbos’ voor zou kunnen komen onder “loofbos” maar het in de praktijk niet gebruikt wordt dan ontbreekt deze in het tabelletje dat ik heb gemaakt.
Het mappen op OSM zal best een dingetje zijn als we BGT willen gebruiken zullen we het moeten doen met wat we hebben. Hier nog meer info over begroeidterreindeel met de uitleg wat er mee bedoeld wordt.
1 Like
Wat ik doe is:
- een OSM laag laden
- Mijn gemaakte BGT shape bestanden als nieuwe laag inladen
- In mijn BGT laag de vlakken selecteren die ik wil over kopieren
CTRL + SHIFT + Mom de BGT selectie in de OSM laag te mergen- Met
SHIFT + {ofSHIFT + }wisselen tussen mijn actieve laag in JOSM (scheelt weer klikken
) - Dan staat mijn geometrie in de OSM laag. Moet je alleen geometrie vervangen of eerst voor stap 3 de vlakken uit de OSM laag gooien die je wilt vervangen
1 Like
Bedankt @Cartographer10 voor de beschrijving, weer wat geleerd.
Shift + { (Cycle layer up} en Shift + } (Cycle layer down) zijn precies wat handig is voor het schakelen tussen verschillende lagen.
CTRL + SHIFT + M kopieert gewoon de objecten naar de laag maar meer dan 1 object geeft een warning als je meerdere objecten hebt geselecteerd staan, het lijkt wel te werken.
Je kan de doorzichtigheid van een active laag instellen, maar niet die van een inactive laag zover ik zie.
Ja klopt maar meestal negeer ik die. Ik doe het gewoon in kleine overzichtelijke stukjes. Overigens, let bij het uploaden wel op dat je de goede laag upload 
. Maar goed, je krijgt van zelf een duidelijke melding hierover.
Ik ben de uitdaging aangegaan en heb sectie Vertalen BGT Fysiek Voorkomen toegevoegd aan Basisregistratie Grootschalige Topografie.
De openstreetmap waardes heb ik gebaseerd op de start post en dingen opgezocht op de Wiki.
Ik zou het goed vinden een discussie te hebben over {forest_wood}, zie Forest
Voor andere gemaakte keuzes is er de Opmerkingen kolom of dingen hier bediscussiëren lijkt me ook prima.
4 Likes
Niet omdat dit post 100 is in deze thread, want jouw 99 is veel chiquer 
, maar…
Ik heb wel vaker landuse=meadow gebruikt al het volgens de BRP blijvend gras in argragische gebieden is. Niet meer doen? Dus vaker grass?