A térinformatika hihetetlen fejlődésen ment át az elmúlt években és évtizedekben. Ez legfőképpen azoknak a műszaki megoldásoknak köszönhető, amelyek egyre pontosabban és részletesebben képesek feltérképezni területeket és objektumokat. Ám amíg régebben az egyszerűbb megoldások értelemszerűen egy jóval kisebb adathalmazt "termeltek", a mostani eszközök által előállított adathalmaz szinte kezelhetetlen méretűre nőtt.
Fogalmazhatunk úgy is, mint egy annak idején megjelent, teljesen más témával (a magyar politikával) foglalkozó könyv címe: "Jesszusmária, győztünk!" Azaz tényleg nagyszerű, hogy most már akár milliméteres, vagy még nagyobb pontossággal térképezhetünk fel térbeli objektumokat, de épp ezért olyan sűrű ponthalmaz-adatokat kapunk, amivel pedig már kifejezetten nehéz dolgozni, nem is beszélve a tárolásukról.
Szutor Péterrel, az MVMI Zrt. informatikai szakértőjével beszélgettünk, aki szintén felismerte ezt a problémát, méghozzá éles helyzetekben. A vállalat projektjeivel kapcsolatban, első sorban tárolási problémák miatt kezdett kutakodni olyan tömörítési megoldások után, amelyek csökkenthetik a keletkező adatok mennyiségét. Ezáltal a tárolási méret is kezelhetőbbé válik, de később sokkal gyorsabb és kényelmesebb lehet dolgozni is az eltárolt információkkal. Mindez beleillik az informatika minden más területét is érintő Big Data problémakörbe, hiszen a világban egyre több adat "termelődik". Ráadásul az emberek által előállítottakon felül egyre több olyan információ is létrejön, amelyeket szenzorok, automata berendezések, internetre kapcsolódó okoseszközök szolgáltatnak. Az egyre növekvő adatmennyiség kezelése pedig az egyik legforróbb IT-témakör.
Szutor Péter
Nagy adat, nagy öröm, nagy baj
A konkrét, térinformatikai példához visszatérve Szutor Péter több olyan problémakört is felvázolt, amelyek az új megoldások által generált hatalmas adatmennyiség miatt jelentenek korábban nem ismert kihívást. Az adattárolásra vállalati környezetben virtuális gépeket, illetve tárolóhálózatokat (SAN-okat) használnak. Ez utóbbiak jól el tudják osztani a jelentkező terhelést a hálózati merevlemezek között, de ha már egyenként is sok gigabájtos blokkokat kell terelgetni, amely jelentősen növelheti a latency, azaz a késleltetés mértékét.
Az adatmentés során szintén a méret jelenthet hátrányt: egy átlagos vállalati Oracle archiválás néhány megabájtos lehet, míg egy térinformatikai pontfelhő már a gigabájtos kategóriába esik. Ez természetesen a vállalati hálózatot is leterheli. Épp ezért célszerű a tárolás előtt tömöríteni az eszközök által generált állományokat, ez viszont a másik oldalon okozhat gondot: egy tömörített adatmennyiséggel sokkal nehezebb később dolgozni, tehát keresni, szerkeszteni, megjeleníteni az egyes információkat.
Sok jó pont kis helyen is elfér
A Szutor Péter által kifejlesztett tömörítés az Octree alapú módszert alkalmazza. Az aritmetikai mód a számok ábrázolásának memóriaigényét igyekszik csökkenteni - például az ismert MrSID, illetve a LasZIP, amiket már elterjedten használnak tömörítéshez. Az úgynevezett nyolcasfa-alapú eljárás alapján már léteznek tömörítési módszerek, például a streaming pontfelhő megjelenítésnél használják az NI eszközökön (mint amilyen a Microsoft Kinect játékvezérlője), de a fejlesztő egy saját megoldáson kezdett dolgozni 2016-ban, leginkább azon megfontolásból, mivel így jobban integrálható a láthatósági számításokba mindaz, amit a pontfelhőkkel végez. Elmondása szerint maga a tömörítési folyamat viszonylag lassú, mivel egy 3D-s objektumok láthatóságát számító algoritmus fut végig a pontfelhőkön rendszeresen. A beolvasott adatmennyiség miatt a folyamat így akár egy hetes nagyságrendű is lehet. Hab a tortán, hogy a fejlesztés közben kiderült, a saját megoldás bizonyos pontfelhő típusoknál még jobb tömörítési rátát is eredményez.
A program Python nyelven íródott, Numpy és PyOpenCL modulok felhasználásával. A folyamat során az OAE tömörítő először megállapítja az Octree kódokat 16-s mélységig, majd rendezi őket. Ekkor következik az első tömörítési fázis (az aritmetikai), amely kiszűri az ismétlődéseket, végül az entrópiakódolás következik a végső tömbön. A tömörítés folyamata erősen számolásigényes, ezért az octree kódolást OpenCL segítségével a videókártya végzi - ez szerencsére tökéletesen párhuzamosítható feladat.
A felhasználáshoz fontos tudni, hogy az eljárás lényege miatt veszteséges tömörítésről beszélünk. Ennek pontossága a kiterjedéstől és az octree mélységétől függ. 30 méteres befoglaló és 16-s mélységnél ez nagyjából 0,5 milliméteres pontosságot jelent. A LASzip és a MrSID eljárásokhoz képest egyelőre csak XYZ tartalmat képes kezelni.
A tömörítési arányok összehasonlításakor azonban jól látszik, hogy sok területen már nagyon ígéretesek az eredmények. Az alábbi táblázatokban jól látható, hol veri meg a saját fejlesztésű OAE a meglévő megoldásokat.
Az értékekből jól kivehető, hogy sima és sűrű pontfelhőket kezel a leghatékonyabban az új eljárás. A zajos, illetve kevéssé sűrű pontfelhők esetében az octree tömörítési módszer már kevésbé jó eredményeket ad. Az OAE leginkább láthatósági és ütközésvizsgálatoknál használható, ahol csak az XYZ értékekre van szükség.
Szutor Péter szerint az eljárás nagyjából késznek mondható, bár vannak még továbbfejlesztési elképzelések, leginkább a pontfelhők racionalizálásával kapcsolatban. Ez tovább csökkentheti majd a tömörített állományok méretét.
Tetszett a cikkünk?
Kövess minket a Facebook oldalunkon is!
