Parallellisera LAZ bearbetning

Lantmäteriets laserdata är i formatet LAZ, utan RGB och i några fall inkluderar dessa en del punkter klassade som brus. Dessutom så är data uppdelat i många mindre tiles (2.5 x 2.5 km).

Vore det inte bra att kunna automatisera en del hantering av dessa punktmoln för att förbereda dessa för hantering i QGIS och med Potree?

Processen är:

1. Läs in punktmoln
2. Filtrera bort bruspunkter
3. Färglägg från ortofoto
4. Sätt korrekt koordinatsystem
5. Spara som COPC.laz

Det vore bra om det gick att slå samman alla enskilda filer till en enda stor COPC.laz fil, men det kräver lite andra resurser så det får göras i ett steg 2.

För att göra många saker i ett sträck med PDAL så använder man ”pipeline”, som konfigureras med en JSON-fil. Dessa kommandon kan köras ett i taget, eller parallelliseras om man har möjlighet att skicka kommandon till olika CPU-trådar. I mitt exempel här så använder jag ”parallel” i Linux och jag vet inte om motsvarande kan användas i Windows. Det går däremot att köra parallel i WSL2.

Först och främst så behöver man skapa sin ”pipeline”. Detta är ett enkelt textdokument med JSON standard notation. En pipeline är en serie med readers, filter och writers som utgör själva processen.

[
	"input.laz",
	{
		"type":"filters.expression",
		"expression":"Classification != 7 && Classification != 18"
	},
	{
		"type":"filters.colorization",
		"raster":"ortofoto.jp2"
	},
	{
		"type":"writers.copc",
		"filename":"output.copc.laz",
		"a_srs":"EPSG:3006"
	}
]

I koden ovan så anges filnamn för input, output, och ortofoto. Detta är bara platshållare, men det är här du anger filnamn om du kör pipelinen manuellt för varje fil. Med kommandot pdal så kan man ”skriva över” olika delar tillsammans med kommandot, vilket även kan göras i ett dynamiskt kommandoflöde.

I pipeline-filen finns en ”reader” som bara anges som ett filnamn, men som skulle kunna utformats på motsvarande sätt som ”writer” för utdata. Mellan dessa finns ett filteruttryck som ignorerar alla punkter med klasserna 7 och 18, vilket motsvarar lågt och högt brus. Färgläggningen görs sedan med ännu ett filter. En ”finess” är att sätta projektionen i utdatafilen, så slipper man ”frågetecken” i QGIS när man lägger till filerna.

Tillbaka till parallel.

Det går att testa kommandot genom att skicka ett ls *.laz kommando till en pipeline som printar filnamnen till skärmen.

Första kommandot ovan är enbart ls där resultatet visas på skärmen, medan det andra skickar denna lista med filer till kommandot parallel med ett ”pipe” tecken. ”-I{}” fångar upp filnamnen och sedan kan man använda ”{}” som platshållare för dessa i kommandot. I exemplet ovan så har jag använt ”{/.}” som tar bort eventuella sökvägar och filnamnstillägg. I stället lägger jag till .copc.laz som ny filändelse.

Principen kan sedan tillämpas på pdal kommandot så att filer läses och skrivs till rätt sökväg.

ls ./63_4/*.laz | parallel -I{} pdal pipeline ./pipeline.json --readers.las.filename={} --filters.colorization.raster=./63_4.jp2 --writers.copc.filenamn={/.}.copc.laz

Kommandot använder gladeligen alla tillgängliga CPU trådar på datorn, så det kan vara lämpligt att låta datorn vara i fred medan den arbetar. Ett alternativ är att lägga till -P n där du ersätter ”n” med en siffra som anger hur många trådar som kan användas som max för varje körning.

Åter till ”problemet” att inte kunna skapa en enda stor COPC.laz fil. PDAL använder ”stream-mode” för bearbetningen, så länge det fungerar. För att skapa strukturerade data som COPC (octree) så behöver man antingen läsa in ALLT i ram, eller använda en disk-cache. Streaming mode stöds inte.

Detta påverkar även den här processen så om din dator inte har rejält med ram, så kommer du att behöva begränsa antalet samtidiga processer för att inte slå i taket under beräkningen. Skall du ändå konvertera med untwine senare så kan det vara lönt att spara till vanlig laz i stället för copc.laz i din pipeline. Då använder du –writers.las.filename i stället. Vanlig laz kan använda streaming mode och då är det bara att köra på med fullt blås. Du bör dock hålla koll på resursanävndningen och göra anpassningar vid behov.

Det går sedan att skriva ett bash-skript som kör parallella pdal kommandon följt av ett untwine kommando som KAN använda disk-cache för att skapa sammanslagna COPC.laz filer.

Bash skriptet blir då en rad för varje katalog med laz-filer med tillhörande ortofoto, följt av en rad med ett untwine kommando som slår samman allt.

Om man mest använder QGIS så kan man i stället skapa virtuella punktmolnsfiler med pyramider, men om man ska visa punktmolnen i Potree så är det bättre med stora filer som täcker större områden.

Genom att skapa en *.vpc fil så visas en outline för varje ingående punktmoln, tills man zoomat tillräckligt nära för att det skall vara lönt att börja visa innehållet. Om man vill se punktmolnet före detta så kan man även generera ”pyramider” för lagret som sedan kan användas i kombination med vpc-lagret. Det är två separata lager i layers-panelen, men det tror jag man kan leva med.

Till skillnad från en enda stor COPC.laz fil så kommer punktmoln som inte är omedelbart användbara bara att visas med outline. Med en stor COPC.laz så hade punkter från dessa visats i alla nivåer, tack vare octree struktureringen. För de enskilda filerna i vpc-filen så verkar detta sättas ur spel.

Processen som beskrivs ovan kan synas omständlig så länge man bara behöver bearbeta några få punktmoln, men om man behöver omvandla en hel kommun, eller ännu större områden, så blir det snabbt värt det. Det går exempelvis att skriva ett skript för bearbetningen (testa på mindre dataset) och sedan låta processen köras över en lämplig långhelg.

En avslutande kommentar. Verktygen blir bättre och bättre, men de är inte felfria. När du kör en omfattande process så var beredd på att allt inte fungerar varje gång. Räkna exempelvis hur många filer som produceras, och om dessa innehåller data. För filer som inte lyckades så får man helt enkelt köra dessa manuellt efteråt.