”Cloud Optimized Point Cloud” eller COPC är en ”ny” öppen standard för effektiv och rationell hantering av punktmoln. Det är en bakåtkompatibel standard med LAZ, utvecklad av Hobu Inc och finns beskriven på https://copc.io/.
COPC till skillnad från vanlig LAZ 1.4 är att punkterna lagras i ”block” eller ”chunks” som är strukturerade enligt octree på samma sätt som EPT formatet (Entwine Point Tile). Utöver det som är standard i LAZ finns det en chunk-tabell och en VLR (variable length records) som beskriver hur denna octree struktur med chunks skall hanteras.
Eftersom godtyckliga VLR stöds av LAZ och ordningen för hur punkterna lagras inte i sig styrd, så blir formatet helt bakåtkompatibelt. Om ditt program som öppnar filen inte har stöd för COPC så läser det filen som en vanlig LAZ och alla punkterna hanteras som vanligt. VLR tabellerna ignoreras helt enkelt.
Om programmet däremot har stöd för COPC så kommer det att hitta VLR tabellerna och använda dessa för att läsa in de octree chunks som för tillfället behövs för visning eller beräkning.
COPC påminner väldigt mycket om EPT, men har som sagt strukturen och hänvisningen till denna internt i en enda fil och inte i filer i en katalogstruktur. Det finns därmed många fördelar med COPC jämfört med EPT. Vi får väl se hur det fungerar när punktmolnen blir väldigt, väldigt stora (TB). Men detta blir framför allt ett filsystemproblem.
Hur kan man då använda COPC?
Det är här det börjar bli intressant. PDAL 2.4.0 släpptes i slutet på förra veckan (2022-03-25) och här ingår stöd för COPC i form av såväl Reader som Writer. COPC kommer därmed att hanteras i PDAL precis som alla andra format som stöds av biblioteket.
QGIS har stöd för PDAL och i min 3.24.1 version så är det PDAL 2.2 som gäller. När QGIS byter till PDAL 2.4 så kommer det tekniskt att finnas stöd för COPC, men formatet behöver även inkluderas i processerna. Detta behöver inte vara något större problem, speciellt inte när det gäller att läsa COPC. När det sedan gäller visualisering så är det antagligen lite krångligare.
QGIS använder EPT formatet för att visa punktmoln såväl i 2D som 3D. Omvandlingen till EPT är automatisk och obligatorisk, just nu. För att kunna använda COPC i stället och inte omvandla detta format till EPT först, krävs betydligt mer arbete med koden i programmet (tror jag).
Här finns det dock en del goda nyheter redan. Lutra Consulting, som är en av de företag som jobbar med 3D i QGIS, drev en Crowd Funding kampanj före jul som uppfylldes med råge (tillsammans med NorthRoad och Hobu Inc). I denna ingick stöd för COPC, men då det skulle krävas ändringar i såväl PDAL som Untwine, så implementerades detta stöd inte i 3.24. När nu PDAL 2.4 är släppt, så är dock förutsättningarna goda för COPC stöd i QGIS 3.26. Läs mer om kampanjen på Lutra Consulting webbsida.
Webbvisning
För att tillgängliggöra punktmoln för ”massorna” så har jag testat Potree och då med punktmoln i EPT. Ambitionen är att även stödja COPC i visare som Potree och det finns redan demo för hur det går att göra med Cesium direkt i en webbläsare (länk). För Potree så är planen att det skall finnas stöd när ”Potree 2” släpps. Här avvaktar man inte minst att den nya standarden WebGPU skall landa in lite bättre, vilket tyvärr kan dra ut på tiden då det är många ”jättar” som är inblandade och som skall komma överens. Dessutom så skulle jag tro att utvecklarna av Potree behöver finansiering och/eller stöd när det väl är dags att sätta igång på allvar.
Elefanten i rummet
Det finns program och företag som redan arbetar med att stödja COPC, exempelvis FME. Om stödet kommer att begränsas till att ”läsa” eller om det även kommer att gå att skriva till COPC återstår att se. När jag senast kontrollerade FME så hade man stöd för att ”läsa” EPT, men inte skriva. Det finns risk att COPC hanteras likadant. Eftersom COPC i praktiken är LAZ i ett sådant fall, så behövs inget arbete från Safe för att kunna läsa formatet, eftersom stödet för LAZ redan finns.
Däremot… Esri. Här envisas man fortfarande med att bara hantera punktmoln i sina egna format. Ja det går att importera LAZ med ett processverktyg, men om du ens vill titta lite på data så måste det vara lagrat i Esri ägda format, utan undantag. Hur är det möjligt att användare fortfarande kan acceptera detta?
Hur kan en leverantör av punktmolnsdata eller myndighet som skall tillgängliggöra dessa som öppna data ens överväga att använda Esri som plattform, när de inte stödjer annat än sina egna stängda format (exempel på när man inte gör det senare i texten). Det går att ”exportera” punktmoln i exempelvis LAZ, men vem skall betala för den konverteringen när jag vill ladda ner punktmolnsdata? Vad händer när punktmolnet är hundratals GB stort? Esri får gärna skapa vilka verktyg och tjänster de vill, men när de verkar aktivt undvika öppna standarder som faktiskt skulle underlätta för användare så kan jag inte göra annat än skaka på huvudet och slå handflatan mot pannan. Jag använder Esri produkter på jobbet, och jag ser många fördelar med att fortsätta göra det, men för #%!#%£! Esri. Lägg till fullt stöd för öppna format!!!
Vill man se exempel på stora organisationer som väljer öppna format för sina punktmoln (som NOAA och USGS) så kan man kika på den här bloggsidan, där det finns exempel på användning av såväl EPT och Potree, som planer på implementering av COPC. Inte ett ord om Esri, men det finns säkert andra exempel där man framgångsrikt använder Esri plattformen för stora mängder punktmolnsdata, eller?
Hur skall en GIS användare konsumera dessa data? Skall jag gå omvägen via nedladdning, konvertering, konvertering igen innan det går att använda dessa data lokalt. Eller skall jag installera QGIS och helt enkelt lägga till url-länken till de öppna data direkt och använda data i mitt GIS efter några sekunder… Jag vet vad jag väljer.