2022 är året då mitt geografiska område laserskannas och resultatet publiceras som öppna data via Lantmäteriets FTP.

Det är ytterligare några områden som skall skannas (har skannats) längre norrut i år, och sammantaget så är det nu ganska stora delar av de något tätare befolkade områdena i landet som är avklarade.

Det finns en ”lucka” i trakten av Örebro och hela inlandet i norra Sverige saknas. Örebro skannas sannolikt nästa år tillsammans med en remsa av inlandet i höjd med Umeå samt ett rejält område väster Luleå. Resten av de områden man avser skanna under trädgränsen hanteras 2024 (gissar jag). Det finns en långsiktig plan på Lantmäteriets webbsida om man är nyfiken. Sedan är det dags att börja om igen…
Data hämtas i rutor med data i LAZ-format uppdelat i mindre områden där varje ruta är 2.5 x 2.5 km. I snitt så finns det 1-2 punkter per kvadratmeter och det finns i stort sett inga punkter på vertikala ytor, så väggar på hus kommer inte att synas. Beroende på klass så är punktmolnet klassat i olika mer eller mindre grundläggande kategorier. De data jag använder i mitt test här är klass 1 vilket är maskinbearbetat med klasser ”mark” och ”övrigt”. Det finns dessutom ”mark inom vattenyta” där man klassat punkter som finns inom en vattenpolygons område. För klass 3 så kan man även få ”bro” som klass. Det finns även ”brus” där punkter hamnat under markytan eller i moln och liknande.
Det är mycket stora datamängder det handlar om! Enbart ruta 22C001 (Eksjö med omnejd) består av 200 LAZ-filer på sammanlagt över 18 Gb. Att hantera alla dessa samtidigt kräver enorma datorresurser, för att inte tala om att hantera hela landet. För att exempelvis göra om alla punktmoln i Sverige till en enda COPC eller EPT katalog hade krävt mycket tid även på en ”superdator” med många terabyte ram.

Planen för Sverige omfattar 335 områden med totalt 65’552 rutor, som i snitt (min uppskattning) är runt 90 Mb stora med nuvarande punkttäthet. Detta ger uppskattningsvis en total datavolym i *.laz filer på strax under 6 Tb. För färgläggning och EPT konvertering så får man lägga på runt 30% i datavolym, vilket landar i runt 8 Tb totalt för alla data i strömningsbart format.
Jag nöjer mig med 100 rutor på runt 9.2 Gb, men även detta tar lång tid att hantera.
För att titta på data så kan man läsa in enskilda LAZ i exempelvis CloudCompare och beroende på datorprestanda så kan ett mindre antal hanteras samtidigt. I mitt fall fungerade 3 x 3 rutor ok, men 10 x 10 kommer knappast att vara hanterbart.
I stället så använder jag PDAL för att slå samman alla filer till en enda, samtidigt som jag applicerar några filter. Jag hade planerat att även byta format till COPC, men då min lite mer kraftfulla dator ännu inte uppgraderats så har jag bara PDAL 2.2 installerat, så jag gör konverteringen till EPT i stället lite senare.
Punktmolnen är utan färg, men det hade jag tänkt fixa med ett PDAL filter och flygfoto. Det går nämligen att skapa en ”pipeline” för PDAL kommandon i en textfil (JSON format) där en ganska komplicerad process kan beskrivas i ett antal steg som ren text. I stället för att köra PDAL kommandot direkt så gör man det genom detta flöde. När jag testade att köra ”merge” med ett terminalkommando så tog mitt ramminne slut, och då har jag 64 Gb i datorn. Med pipeline så äter det inte upp så mycket ram, inte i närheten. Detta beror på att ett så kallat stream mode används då. Det går att ”kräva” stream mode med ett kommandotillägg, som avbryter körningen om stream mode inte är möjligt, så man inte riskerar att tömma datorns resurser och hänga datorn.

Min JSON fil består av en lista med filer och filter. Först kommer ett filnamn med ”joker” tecken för att få med alla filer jag vill slå samman. Efter detta kommer ett filter som använder ”merge”, för att göra själva sammanslagningen. Därefter ytterligare ett filter som färglägger punkterna baserat på en rasterfil (valfritt GDAL format inklusive vrt), för att slutligen ange ett filnamn som resultatet skall sparas som. Om jag hade haft PDAL 2.4 eller senare så hade jag kunnat lägga till att det skulle vara LAZ i COPC format för lite mindre dataset, men som sagt…
Denna ”pipeline” körs sedan med ett PDAL kommando som anropar JSON filen (pdal pipeline -i min_fil.json).
Totalt så täcker mitt testområde 25 x 25 km och flygfotot är 50 x 50 km (överlappande). Totalt är det som sagt drygt 9 Gb o-färgade punkter, och det färglagda punktmolnet kommer att vara några Gb större (12.3 Gb). Med andra ord är punktmoln för mycket stora ytor något som inte lämpar sig för enskilda skrivbordsapplikationer, utan någon form av ”streaming” är att rekommendera. Det hade varit önskvärt att kunna läsa punktmolnsdata direkt till QGIS eller webbapplikationer i format som COPC eller EPT. Nedladdning eller konvertering till andra format med PDAL skulle då kunna göras med ett geografiskt filter där man begränsar området man är intresserad av.
För att konvertera LAZ till ett ”hanterbart” format så använder jag untwine som är det verktyg QGIS använder för att konvertera punktmoln till EPT. Dessa data kan jag nu använda i såväl QGIS som i webbapplikationer som Potree. All bearbetning tar som sagt en hel del tid och det krävs en kraftfull dator, men när det är klart så går det blixtrande fort att läsa dessa data i de applikationer som stödjer formaten.

Färgläggningen är baserad på 2D data, så även punkter som ligger på marken, kommer att färgläggas efter sådant som visas över. Det underlättar också om fotot är samtida med de skannade punkterna, vilket jag inte hade möjlighet till här. Dessutom så är flygfotot i lägre upplösning än punkterna, men oj vad bra resultatet blev trots allt.

Konverterat till EPT och visat med Potree så är detta punktmoln en fröjd att arbeta med. I QGIS så är det inte så mycket sämre och jag ser verkligen fram emot QGIS 3.26 där det finns mängder med förbättringar rörande just punktmoln och 3D.
Nu kan man bara önska att Lantmäteriet köper in lite superdator tid och gör om alla punktmolnsdata på liknande sätt och publicerar dessa som Entwine eller COPC data så det går att ”streama” data direkt till olika klienter. De behöver inte ens göra det till ”ett” paket. Det skulle räcka långt att ha de nuvarande rutorna som enskilda url-adresser till octree strukturerna. Beroende på var man är så bör man inte behöva mer än 1 till 2 rutor åt gången (upp till 50 x 50 km). Och 6-8 miljarder punkter är ju inga problem att hantera med dessa format, samtidigt som filernas (katalogerna för EPT) storlek blir hanterbara (under 50 Gb). Vill du sedan ha ett utsnitt för ett mindre område i ett annat format, så kan PDAL hjälpa till där med. För detta finns ett crop filter som kan exportera en ”box” eller ”cirkel” med punkter. COPC, las/laz, e57, ply med flera format stöds för exporten.
Uppdatering
Jag har sedan ovanstående skrevs lyckats installera PDAL 2.4.1 med hjälp av ”Conda” och kunnat testa även COPC formatet, med blandat resultat. För samlingar av data som kan hanteras i Ram (kräver väldigt mycket Ram), så fungerar det fint. Men jag har inte lyckats med större dataset utan att Ram tar slut, och då har jag 64 Gb i datorn.
Problemet är att writers.copc inte kan hantera ”stream mode” där bearbetningen görs löpande och inte på kompletta inlästa dataset. COPC såväl som EPT behöver bearbeta alla data i minnet, eller i en disk cache, vilket inte fungerar med stream mode. För väldigt stora ”pipelines” så finns även risken att något går fel. Ju större dataset, desto större risk. När det går snett så är meddelandet från PDAL att det är något ”fel” på data, men om detta stämmer kan jag inte värdera. Det har dock hänt ett antal gånger när jag bearbetat Lantmäteriets laserdata. En funktion för att ”testa” alla data före bearbetning kanske kan underlätta och minska risken för tidsödande felsökning.
Min process just nu är att köra merge och colorization till ett nytt vanligt LAZ, och sedan konvertera detta till EPT med untwine i QGIS. Dessa set, samma som Lantmäteriets paket med 25×50 km data, kan sedan läsas in och visas i Potree var för sig, eller tillsammans i lämplig omfattning. PDAL kan sedan även användas för att ”exportera” valda områden till andra punktmolnsformat, inklusive COPC, så länge området inte blir för stort. Jag har bara gjort några få områden på det här sättet, då beräkningarna tar timmar på min dator (single thread). Men 50×50 km med 6.6 miljarder punkter i Potree fungerar riktigt bra.
Om du har behov av bearbetning av mycket stora datamängder (50 Gb eller större), så finns det kommersiella licenser som utvecklats av Hobu Inc, som också är villiga att ”konsulta” vid implementering av processer som bygger på PDAL, Entwine/EPT, COPC med mera.