Koordinater och 32 bitar

Över jul och nyårsledigheten så har jag stött på ett ”problem” som dessutom gjorde sig påmind när det var dags att gå tillbaka till arbetet. Det handlar om begränsningen med lagring av koordinater i 32 bitars tal.

Hur kan då detta vara ett problem?

Jo, i takt med att kraven på noggrannhet ökar så blir ju antalet siffror i koordinaterna fler. Och då ett 32-bitars tal bara kan hantera tal mellan 0 – 4,294,967,296 eller mellan -2,147,483,648 – 2,147,483,647, så är utrymmet för precision begränsat.

Koordinater i SWEREF99TM har sex siffror i X-led (öst) och sju siffror i Y-led (nord). Med en precision på en meter så räcker 32 bitar mer än väl, men om du exempelvis laserskannar och georefererar så kan du inte lagra alla koordinater med millimeternoggrannhet. Centimeter går bra, men inte millimeter…

Men då är det väl bara att använda 64 bitar i stället? Jovisst, men då måste alla applikationer, inklusive operativsystem klara av att hantera 64 bitar. Men gissa vad! Det gör dom inte…

Inledningsvis stötte jag på problemet i Blender som bara kan hantera koordinater i 32-bitar, vilket ger konstiga avrundningsfel när man importerar georefererade data. Nästa gång jag stötte på problem var när jag försökte konvertera ett punktmoln till EPT format i QGIS genom untwine, vilket helt enkelt inte fungerade (helt utan felmeddelande). När jag försökte igen och hade startat QGIS från ett kommandofönster så skrevs ett felmeddelande ut om att det inte gick att tolka en koordinatsiffra med för hög precision. Inte heller Potree verkar kunna visa alla typer av data med hög precision…

En del program klarar av att hantera detta och de flesta GIS har inga problem att skapa koordinater med 15 decimaler som standard, men i en del sammanhang blir det som sagt problem.

Om du stöter på obegripliga problem när du skall hantera detaljerade data så kan du prova att reducera koordinaternas noggrannhet till maximalt två decimaler (centimeter) för UTM eller SWEREF99TM. Om det löste problemet så har applikationen du vill använda inte stöd för mer än 32 bitars koordinater.

Tills vidare är det så här jag kommer att göra. Öppna punktmoln i CloudCompare, sub-sampla till 1 cm och spara med endast två decimaler. När jag genererar punktmoln med OpenDroneMap så är det däremot inget problem, eftersom ODM redan vid genereringen bara använder 32 bitars koordinater. Jag är nu inte 100% säker på att detta är ett 32-bitars problem enbart, då jag bestämt har för mig att jag har genererat punktmoln med millimeternoggrannhet tidigare, men det kanske inte var med fullständiga koordinater i SWEREF99TM utan lokala koordinater.

Ett annat alternativ är att skapa ett anpassat koordinatsystem för punktmolnsdata som har falsk northing på -6,000,000. Då borde det gå att komma ner på millimeterprecision. Det blir rörigt och lätta att göra fel, men det borde fungera. I alla fall tills jag behöver hantera data med ännu högre krav på noggrannhet…