Projekt Kogutowicz -- Szabad Szoftver pályázat beszámoló

Ezeknek a térképeknek az adatait akartam felhasználni és nyomtatható térképeket gyártani, amikor kiderült számomra, hogy az elérhető opensource térkép rajzoló alkalmazásoknak számos gyenge pontjuk van.
Sok ilyen térképalkalmazás létezik, de mindegyik csak egy szűk funkcionalitást ad. A Mapnik – amivel az OSM webes térképeit renderelik – elsősorban webes renderelésre alkalmazható. Nagyon nehezen bővíthető ki (pl. turistajelzések saját módon való megjelenítése) és mégnehezebben illeszthető be más programokba (pl. a JOSM térképrajzoló alkalmazásba). Más programokkal ugyanilyen problémáim voltak (pl. a Kosmos szép térképeket generál, de csak Windowson és csak nyomtatható térképeket, webes megjelenésre nem lehet használni.

Hamar körvonalazódott egy egyszerű, de kiterjeszthető általános célú térképrajzoló alkalmazás víziója. Az elképzelés szerint az alkalmazás egyaránt tudna webes térképeket valamit nyomtatásra szánt térképeket generálni. A szabadon elérhető forrásokból lehetne például nyomtatható Magyarország Autóatlaszt, Budai hegység turista térképeket generálni, de ugyanígy lehetne OpenLayers alapú magyarország térkép oldalt készíteni.

Már épp proof of concepteken dolgoztam, amikor az FSF.hu Szabad Szoftver pályázat megjelent. A pályázaton sikerült támogatást szerezni a projekt első lépéseinek a megtételéhez: a kód projekté alakításához, hogy nyilt licensz alatt közzé lehessen tenni, és az alap funkciók fejlesztéséhez

Az alkalmazás, technikai részletek

A Kogutowicz egy Java alapú térképrakzoló alkalmazás. A fontosabb komponensek mind implementációk és függetlenek minden tehcnológiától. Ez azt is jelenti, hogy habár alapvetűen az OpenStreetMap terminológiát használ a program, mégsem függ közvetlenül annak adatszerkezetétől.
Mivel a szabadon elérhető amatőr térképformátumokból az OpenStreetMap az egyik legelterjedtebb jelenleg ezt a formátumot olvassa be fájlból. (A turistautak.hu adataira létezik már C alapú konverter, amivel OSM formátumba konvertálható az állomány.)

Beolvasás után már saját adatszerkezetben tárolja a térkép adatokat, ezzel elvileg lehetőség van másfajta adatforrások implementására is, amiknek az elemeik lefordíthatóak OSM-hez hasonló domain modelre. (UPDATE: a beszámoló írása óta már a garmin formátumú beolvasó is készült, és úgy tűnik kis munkával közvetlen garmin fileokból is fog tudni rajzolni)

Hasonlóképpen rendereléskor is saját 2D osztályokat használ, csak a végső stádiumban fordítja ezeket a jávás Graphics2D objektumokra (illetve bármilyen más rajzoló keretrendszer objektumaira). Ezzel (és a csomagolási struktúra későbbi átalakításával) akár Androidon is futtatható lehet, ha a megfelelő renderelési adapter réteget implementáljuk.

Maga a renderelési mechanizmus is kiterjeszthető. Az alapértelmezett algoritmus kissebb téglalap alapú részekre bontja a renderelendő területet és ezeken egyesével megy végig (amennyiben nem szomszédos területeket renderelünk egy időben, akkor ez később párhuzamosítható lesz). A renderelt területek rajzából absztrakt geometriai elemek keletkeznek, amiket egy átmeneti tárolóban tárol (jelenleg a memóriába be kell férnie, de később elosztott cache jelegű implementációk is lehetségesek). A geometriai elemeken opcionális műveletek elvégzése után (pl. ütközés detektálás: a túl közel eső hasonló ikonokat normalizálja) részterületenként lerendereli tetszőleges renderelő használatával (jelenleg PDF, PNG, SVG támogatott).

A köztes tároló réteg bevezetésével későbbiekben lehetőség lesz inkrementális renderelésre is. Egy adatbázis (vagy elosztott cache) tárolhajta a lerenderelt geomteriai elemeket, amik közül csak azokat kell módosítani, amihez megváltozotak a térkép forrás adatai.

Az elképzelés szerint megfelelő párhuzamosítással a tervek szerint map reduce rendszereken is futtathatóvá vállhatna a renderelő az elképzelések szerint (pl. Hadoop clusteren).

A pályázat

Az FSF.hu Szabad Szoftver pályázata során elkészült projekt valahol a proof of concept és a használható termék között van. A pályázatban vállalt fejlesztések megszülettek, a kezdeti prototípus projekt letisztázásra került annyira, hogy közreadhatóvá válljon és Apache licensz alatt publikálásra került a forráskód, példákkal, alap dokumentációval.

A megígért funkciók implementálásra kerültek: PDF, SVG, PNG kimenet működik, többfajta renderelési procedúra (több lapos, atlasz jellegű, egylapos fali plakát jellegű, webre szán PNG mozaik típusú kimenetek) érhető el. És persze az implementálás közben (mint az ilyen kezdeti stádiumban lenni szokott) számos refaktor vált szükségessé valamint előre nem várt funkciókat is meg kellett valósítani, hogy használható legyen az alkalmazás.

Magát a Szabad Szoftver pályázatot jónak és hiánypótlónak találom. Mivel nyílt forrású fejlesztésre nem mindig jut ugyanannyi idő, ezért erős motivációként hatott, hogy az előre beígért funkcionalitásnak mindenképpen meg kellett születnie. (Persze összességében jóval több időt foglalkoztam vele, mint amit piaci alapon ezen összegekért lehetne csinálni, de nyilván nem is ez a kérdés egy ilyen pályázatnál. Mindenesetre több idő volt mindent teljesíteni, mint elején hittem)

Mindenképpen haszosnak tartanám, ha lennének még hasonló pályázatok itthon. A formáját nyilván lehet vitatni (a Google SoC fix összegű támogatásának sok előnye van a rugalmas keretösszeghez képest, de persze vannak esetek, amikor a jelenlegi módszer rugalmasabb.

A jővőre nézve ha javasolnom kéne valamit, annyit mondanék, hogy a tapasztalatok alapján érdemes lenne már a kiíráskor meghatározni, hogy a pályázott pénzek milyen formátumban kerülhetnek folyósításra (adók, számlázás, stb.). (Ez egyébként az első Google Summer of Code projektben is felmerült, mert csak az eredmény hírdetés után derült ki, hogy a Google se tudja, hogy pl. egy török programozó hogy kell, hogy adózzon amerikában).

További tervek

Ahogy feljebb is írtam a jelnlegi kódbázis egy proof of conceptnél már többet, de egy használható terméknél kevesebbet nyújtanak. Ahhoz hogy elérjük az 1.0 állapotot még sok fejlesztésre lesz szükség. Ezek közül néhány:

1. Az első és legfontosabb feladat szebb térkép stílusok kifejlesztése. Technikailag hiába tud jól renderelni az alkalmazás, ha ezt csak egyszerű kevésbé látványos térképeken tudjuk demózni. Már meg van az alapja különböző térkép stílus beolvasóknak (HTML alapú Kosmos térkép stílusok, XML alapú Mapnik stílusok). Ezekből valószínű a Kosmos definíciókat egyszerűbb támogatni.

2. A térkép elemeket ki kéne bővíteni a színtvonal razolással és az utca név címkézéssel is. Mindkettő probléma önmagában is egy külön projekt méretű.

3. A memória kezelésen mindenképpen javítani kell. A jelenlegi default renderelési mechanizmus abból indul ki, hogy inkább több memóriát használ, csak hogy gyorsabb legyen. Ország szintű térképeknél ez problémás lehet, ezért meg kéne írni néhány elosztott cache-re épülő köztes tároló megoldást.

4. Hasonló okokból kéne fejleszteni egy alacsony memória fogyasztású renderelő algoritmust, ami inkább több disk művelettel és lassabban működik, de kevés memóriával is megy.

A kód hozzáférhető a http://code.google.com/p/kogutowicz címen.