|
THIS IS A TRANSLATE!! THE ORIGINAL TEXT YOU CAN FIND HIER
I COMMENTED IT, SO ACTUALLY IT ISN'T A PROPRE TRANSLATE.
Majdnem négy év telt el a Mapping hacks című könyv megjelenése óta, a web alapú térképezés jelenlegi állapota pedig egyre közelebb kerül a közönséges halandókhoz és a dizájnerekhez. Egy szoftver, Artem Pavlenko nagyszerű, nyílt forráskodú renderelő könyvtára, a Mapnik pedig ebben közvetlenül felelős.
A rossz híre ellenére - amiszerint nehéz telepíteni - (még a Mapnik cégeknek ajánlott szolgáltatásáról is ez hírlik???), ha egyszer elindul, egyszerűen nincs jobb amivel saját web alapú (slippy - csúszós:) térképeket lehetne készíteni. A Mapnikot jópár oldal használja, hogy érthető legyen mit is tud a legjobb meglesni ezeket az oldalakat. Külön kiemelve a szövegek magas minőségű megjelenítését, az alakzatok egyenletes élsimítását, illetve a térképek általános "csiszoltságát":
Az Openstreetmap (Írtam róla mostanában) a felhasználók által beküldött adatokból készít utca szintű, az egész világra kiterjedő térképeket. Íme két példa Oaklandról, illetve Koppenhágáról.
Az orosz Kosmosnimko weboldalnak (Nem tudom kik ők, vagy mit csinálnak) van egy tökjó slippy térképe, elsősorban Moszkvára - különösen lenyűgöz itt az önálló épületek közelí nagyítású felvétele, a hatalmas metro hálózat ábrázolása és úgy általában az egész kinézete.
Az EveryBlock saját térkép csempéket készített egy maroknyi amerikai várost lefedve, elsősorban a nyilvánosan elérhető GIS adatokra, mint a TIGER/Line vagy a városi önkormányzatok - mint San Fransisco, Washington D. C., kattints ide, hogy lásd mindet - által előállíttatott shapefájlokra támaszkodva. Nézzük a példát, ezen a térképen páldául San Fransisco Mission Kerületét ábrázolták hír cikkekket helyezve a térkép fölé. Kedvelem azt az egyszerűséget, minimalista stílust, amit az EveryBlock dizájnere Wilson Miner követ az alaptérképnél, mert az ideális hátteret nyújt a helyi információk számára; A Google információ gazdag térképei ebben a helyzetben például nem hasznosak. Paul Smith már írt a Mapnikról az EveryBlock saját blogjában és a kitűnő A List Apart (ALA) áttekintésében.
Az utóbbi link, Paul ALA cikke egyébként jó áttekintést nyújt mire is való a Mapnik.
A legelső használat után, amikor a Mapnik legelső példáját (Hello World) kirenderelted, vajon gondolkodtál arra merre tovább?
Az elmúlt pár hónapban, egy különleges projekt kapcsán (amiről többet kicsit később) a Mapnik mélyébe ugrottunk, ebben a posztban megkísérlem összefoglalni azokat a szerkesztési tapasztalatokat/problémákat amikbe belefutottunk és amivel foglalkoztunk a projekt kapcsán. Feltételezem, hogy eddigre már kipróbáltad a Mapnikot és van valami elképzelésed vajon mire is jó. Röviden annyit a működéséről, hogy ez egy olyan program, ami összekapcsolja a sokszor hatalmas mennyiségű földrajzi (georeferált) adatokat, egy az XML nyelven leírt stíliuslappal aminek a kimenetei rendes képek lesznek. A jegyzet néhány példájának a végén kitérek a technikai részletekre is, például miképpen épül fel a Google és más népszerű slippy térkép szolgáltatók térképe, hogyan kell a csempék létrehozását felgyorsítani illetve mi az a kettős vetület.
Jelenítsd meg a munkád
A webes munkát igen egyszerűvé teszi, hogy a böngészőben ellenőrizni lehet mit csinaltunk. Ugyanez igaz a Mapnik stíluslapokra is: létre kell hozni egy HTML oldalt egy linkkel a térképek élő renderelőjéhez, illetve ezen megjeleníteni több térképlapot több különböző szinten és több különböző helyről. Miután a stílus leírókat átszerkesztetted, töltsd újra az oldalt és lásd milyen hatással van az egész megjelenésére a változtatás. Ezt a technikát EveryBlockosoktól, Paultól és Wilsontól tanultam és úgy tűnik őket jól szolgálta ez a fajta fejlesztő + dizájner felosztás (megjegyzés: így a dizájnernek nem kell foglalkozni a programozás részével). A legkönnyebb csapdába esni (a dizájnernek) az összetett rendszerekkel, mert ha abban történik változtatás, a sok kis apró mahináció megoldja ugyan a kis problémát, de ugyanakkor egy magasabb szinten, globálisan egy nagyobbat generál. A Mapnik stílusok is besűrűsödhetnek nagy és változatos adatállományok esetében - nézd meg az OpenStreetMap stílus szabályait, hogy elképzeld milyen mély is a nyúl ürege (megj: ez ilyen mátrixos duma lehet:...and I show you how deep the rabbit hole goes)
A sorrend számít
A Mapnikban a sorrend számít. Az alakzatok, szövegek rajzolásához a program a "festők algoritmusát" használja, ami annyit jelent, hogy ami egyszer a vászonra kerül az a helyén is marad. Ebből nyilvánvalóan következik, hogy a rétegek helye a stíluslapban is meghatározott. Az xml fájlban felül található rétegeket rajzolja ki először, és az alsókat hagyja utoljára a program. Az Óceánokat, a tengerparti sávot ezért érdemes az (xml-fájl) tetejére, míg a POI-kat és az utca neveket az aljára helyezni.
Kevésbé nyílvánvaló, de az eredmény szempontjából az adatforrás belső rendje is számít. Mert ha egy adatbázisból, vagy shape fájlból olvassuk ki például az utakat, azokat úgy fogja lerajzolni a program, ahogy az adatok sorrendben az adatbázisból vagy a fájlból beérkeznek. E módokon lehet finomhangolni a térképet.
Ha POSTGIS-ből az utakat rajzolod, az ORDER BY LENGTH(geometry) DESC paranccsal a leghosszabb utakat feliratozza majd elsőnek, ami így helyesebben fog kinézni kicsinyítéskor, amikor már nincs elég hely mindent feliratozni.
Ha a városok neveit feliratozod, az ORDER BY population DESC paranccsal a nagyobb városokat feliratozza majd először, míg a kisebbek maradnak utoljára. Ezt, a Mapnik ütközés felismerő algoritmusával kombinálva azt eredményezi, hogy a nagy, fontos helyek mindig látszani fognak, míg a kisebbek csak akkor, ha van elég hely. Kicsinyítésnél, a megye vagy állam szinten a térkép kinézete megfelelőbb lesz.
Külön elsőbbséget biztosító jelölőt is hozzá lehet adni az adatokhoz, hogy könnyebben lehessen majd irányítani a sorrendet. Lényegében ez akármi lehet: a fővárost a kis városok elé, aluljárók elé a felüljárókat, a bárok elé a posta hivatalokat.
Mapnik közvetlenül megengedi az ORDER BY klauza használatát a stíluslapon a POSTGIS esetében, míg a shape fájloknál újra kell építeni a ogr2ogr eszköz -sql kapcsolójával az adatbázis belső sorrendjét.
Az utak rendereléséhez használt alap stílus, valamint a belül világos színű, végony határvonalú feliratozott helyek a rétegek ismétlésével renderelhetőek ki sikeresen. A vastag, feketére színezett utakat kell ezért az aljára tenni (megj: xml-ben ez az első, így ott a tetején lesz) például 14 pixel szélességben. Másodszor egy vékonyabb, világos színű, körülbelül 12 pixel szélességű utak réteget kell erre rátenni. !!!! Itt eltérek az eredeti szövegtől !!!! Az általa felvázolt esetben két Style-t használ, nem pedig kér Roules-t egy Style-on belül. Ami nagy különbség, mert két Style-t használva az utak réteget lényegében kétszer hívja meg a Mapnik, így a kereszteződéseknél fedésmentesen, csak a széleken látszódik a fekete, alsó réteg, mivel a felső később renderelődik ki, így az teljes mértékben takarja. A második esetben csak egyszer hívja meg a Mapnik az utak réteget, így az adatforrás belső rendje lesz a mérvadó, tehát az első úthoz egyszer lefektet egy utca feketét, majd rá a fehéret, utána a következő utca feketét, majd a fehérjét stb, így a végén a kereszteződéseknél is átmennek a fekete élek ami nem túl guszta. Az utóbbi a wrong az előbbi a right példa magyarázata !!!!! Vége az eltérésnek !!!!
SZÖVEG
A Mapnikban egy rakat lehetőség van a szöveg vonalra helyezésére. Az első dolog, amivel tök elégedett leszel a hajlítható szavak az éles sarkoknál, amik egyébként csúfak lehetnek az utca neveknél. Szerencsére van egy tulajdonság, a max_char_angle_delta, amit a TextSymbolizerhez adva a feliratokat távol lehet tartani az éles fordulóktól - 20 fokra állítva már egész jól néz ki. Így megmaradnak a görbe utca nevek, de nem lesz olyan bántóan éles a fordulat:)
Amennyiben az adatbázisodban a hosszú utak kis szakaszokra vannak vágva, talán megtapasztalhatod te is azt, hogy a Mapnik nem tudja belepasszintani a kis szakaszokba a feliratot, vagy bele tudja, de fölöslegesen sokszor megismétli a feliratot. Mi kereskedelmi forgalomban lévő adatbázisból dolgoztunk, ami a térképek rugalmas előállítására volt beállítva és ezért számos szakaszra voltak bontva az utak, az útsávok száma, vagy egyéb más szakasz tulajdonságok miatt. Mivel ezt nem akartuk ilyen részletekben bemutatni, ezért az azonos nevűeket egy hosszú vonalba vontuk össze.
A sztrádák, vagy az autópályák felirata általában a "pajzs", ami a Mapnikban mint ShielSymbolizer van beépítve. A Shield a szöveg és a kép egyfajta kombinációja, aminek a célja az út hosszú név helyett rövid számmal való bemutatása (példa "CA 13" a "Warren Freeway" ellen). De ahogy a fenti sorrend trükközésnél, a shieldeknél is be kell vetni egy kis betyárságot a helyes megjelenitésért. Az általános SQL LENGTH(name) funkciót kombinálva a Mapnik style rule filter hármassal készíthető egy egyszerű feltétel: például olyan, hogy a széles kép hátterű shildekhez a hosszú út számjegyű, a keskeny kép hátterű shildekhez a kis út számjegyű számokat társítsa.
Követve a (piac)vezetőt
A Microsoft, Yahoo!, Google, OpenStreetMap és mások által használt mercátor vetület ideális a Föld nagy részének lefedéséhez. A lokális helyek (megj: települések) kb arányosak, míg az egész is megfelelő, amolyan iskolás-fali-térkép-emlékű kicsinyítéskor.
Három dolog van amire figyelni kell a kettős vetületnél:
!!!!EGY KIS KITÉRŐ!!!! Mivel én egész sokat szívtam ezzel a kettős vetülettel, így megjegyzésként írok róla. A Google maps (mint az összes többi) kétféle koordinátát használ. Ami általában leolvasható, ha leolvasható, az egy decimális vagy ilyen szögperces (43.3333 a 43°15' 12" helyett) földrajzi koordináta pár. A földrajzi "vetülethez" tartozik egy EPSG kód ez 4326, illetve egy proj4 formátum, ami "+proj=latlong +ellps=WGS84 +datum=WGS84 +no_defs" (Így ismeri fel a Mapnik a Grass ezt a "vetületet"). Viszont a térkép csempék, azok world - mercator vetület félében vannak (a sarkok felé a végtelenbe tart az egész, de amúgy a hosszúsági és a szélességi körök is párhuzamosak). A Mercator vetület tulajdonságából eredően egy négyzetlapon (ami itt 256px*256px) nem lehet ábrázolni az egész földet. A sarkok az alkalmazott technika miatt ezért egész egyszerűen le vannak csapva. A maximális kiterjedése északra és délre keletre és nyugatra egyaránt (Pi*6378137) ami az EPSG:4326-ban kb 85° szélességnek felel meg északon és délen, 180 keleten és nyugaton. Ennek a vetületnek az EPSG kódja 900913 vagy SR-ORG:6627, a proj4 formátuma "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs". Sajnos a térképészekre igen sértő lehetett ez a Google féle vetület, nagyon nehezen fogadták be - ha befogadták - így néhány helyen még egy hiper amorf szerkezettel is lehet találkozni. Amikor az EPSG:3395-ből (a hivatalos World MErcator) számolják ki az EPSG:900913-at. Ennek az az oka, hogy ugyanaz a vetület (ugyanaz a proj4 formátum), csak más az a terület amit lefednek! A csempék rendereléséhez viszont épp ez nem mindegy... Csempékről amúgy azért van szó, mert ezek a térképek csak 256 pixel oldalú négyzetekből állnak. A nulladik nagyitási szinten 1db ilyen van, ami minden egyes szinten 256*2^nagyításiszint szerinti sémában nő. !!!! Kitérő vége!!!!
Tehát a jótanácsok:
1. Mindenképpen ellenőrizd, hogy az adataid fokban vannak. San Fransisconak kb a -122, 37 közelében, Londonnak a 0,50 közelében kellene lenniük és így tovább. A pontos SRS definíció ez: "+proj=latlong +ellps=WGS84 +datum=WGS84 +no_defs" (Megjegyzés: Ezt egyáltalán nem értettem miért is jótanács, hiszen a Mapnik nem számol vele és egyébként is a vektorokat azonnal átszámítja, ott azt kell tudni miben van azt csá, míg a rastert nem ebben kell tárolni, de ez a megegyzés inkább kérdés a részemről, hiszen a posztíró egy A kategóriás programozó, nem pedig egy ZS kategóriás geográfus:)
2. Hagyj el minden dátumot/ellipszoidot az egyszerűség kedvéért, hiszen a Javascript, Actionscript kliensek könnyebben tudnak a gömb alakú Földdel számolni. Modest Maps például legtöbbször ezzel számol. A pontos SRS definíciója a térkép kimenetének ez legyen: "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs"
3. Állíts be valami értelmes rövidítést a minimális és a maximális nagyítási szinthez, mert egyébként a szemeid kiszáradnak, és kiesnek a fejedből. Itt a mienk.
Folyamatosság
Tapasztalatom szerint a Mapnikot leginkább mozgatható, nagyítható slippy maps-hoz használják, legtöbbször OpenLayers vagy Modest Maps alatt. A gyors betölthetőség miatt ezek négyzetre vágott, csempékből állnak. Azt az illúziót keltik, mintha a végtelenségig lehetne lapozni őket, ám így a feliratoknak csempéről csempére egyezni kell. A Mapnik determinisztikus algoritmust használ a feliratok elhelyezéséhez: adott nagyítási szinten a feliratok meghatározott földrajzi helyhez kötődnek tekintet nélkül a a renderelésre kijelölt területre. Pechünkre ez nem azt jelenti, hogy a szöveg pontokra lesz téve, mint a város nevek esetében, amik két csempe közötti határon is átmennek és megfelelően kirenderelhetőek. A Mapnikot használók ezért kitaláltak egy stratégiát, ezekben az esetekben a kirenderelendő területet körbeveszik egy sávval, amit aztán kivágnak, 128 pixel az általában javasolt sáv szélesség négyszerezve a területet 256*256 pixelről 512*512 pixelre, aminek a nagyobb része azután feláldozzuk a folytonosság oltárán. Ezt az OpenStreetMap-osoktól tanultam !!!! Megjegyzés: Sokáig nem értettem miről is ír. Nekem sokkal egyszerűbb az a magyarázat, hogy a Mapnik felirat renderelője nem következetes. Van amikor fixen egy helyre teszi a neveket, valamikor nem. Emiatt lesznek a térképen félbevágott szövegek, amivel az OpenStreetMap tele van, de nekem is sikerült párat kirenderelnem:
http://terkepek.baaa.hu/ujskocia/alap3/8_x82_y92.png
http://terkepek.baaa.hu/ujskocia/alap3/8_x83_y92.png
Ami itt megtévesztő lehet, hogy ő nem renderel ki 256*256 pixelnyi területet, hiszen épp előbb írja, hogy eléggé időtrabló. Ezért a képen ő a később még felvágandó csempe körül rajzolta be a sávot, hiszen neki azt rendereli ki a Mapnik. Az én renderelőmben a sáv technikát még nem alkalmaztam. Az én fejemben úgy áll össze ez a probléma, hogy talán így kényszeríti a Mapnikot az olyan renderelésre ami a városneveknél alapból már megvan, vagyis a csempék közötti megfelelő átrenderélsre. De nálam pont a városneveknél voltak a gondok, mert míg egyes helyeken tökjól kirenderelt a Mapnik, máshol összegabalyodott, és pont azokban az esetekben, amikor több Roule volt megadva egy Style-on belül... !!! Megjegyzés vége!!!!
Optimalizáció
Van abban valami, hogy nem egyesével, hanem egy tömbben érdemes a képeket kirenderelni, négyszer négyet egy időben, és ezt feldarabolni.. A Mapnik felállásának idejét így mérsékelve, szóval ezt a nagyságú területet lényegesebben gyorsabban rajzolja ki mint a kis képkockákat (megjegyzés: kb 10* gyorsabban!!). A csempék renderelésére én a 16-os, kb közepes csempeméretet találtam megfelelőnek fél-csempe szélességű sávval a tömb körül. Azt hiszem az OpenStreetMap 64-es csoporttal dolgozik, de ez tényleg attól függ a szerver mit tud kezelni, illetve mennyi idő van várni.
Ismert és elfogadott, hogy a Mapnikot vezérlő Python kód még nincs teljesen kidolgozva. A Paul által leírt TileCache/WMS megközelítés nagyon alap, és nem is a leggyorsabb. Épp végeztünk a mod_píthon + memchached szerkezet fejlesztésével ami kérésre rendereli a csempéket, persze már ez is tartalmaz némi alapvető kommunikációs logikát, szóval az egyidejű és egy területet lefedő kérések esetében megvárja a másikat és újrafelhasználja a másik kérás eredményét (nézd meg a kommenteket). Azt hiszem az OpenStreetMap már elég messze jutott, hogy kifejleszzen egy apache modult ami ezt egyszerűbbé teszi.
A Mapnik úgy tűnik elég okos, amikor meghatározza melyik méretarányban melyik adatra van szüksége: amennyiben a Style-ban meghatározod a rule scaledenominator-át, az ezen kívüli méretarányban az adatforrást blokkolja a program. Azonban ugyanez nem igaz a Filter-re a Style Roules-ban - ekkor meghívja minden egyes darabját az adatbázisnak , és nem optimalizál a PostGis kérés elküldésekor.
Get Hopping - Kezdjünk ugrándozni??:)
A legfontosabb amiről a Topic szólt:
- Felállítani a rendszert amin majd dolgozni fogsz.
- A munka folyamatos nyomonkövetése
-Festő modellre mindig emlékezni
-Haverkodni a Python fejlesztőkkel akik felépítik a munkakörnyezeted
|
