Popis renderovania na freemap.sk
Renderovanie dát je rozdelené na dve oblati:1. denné renderovanie
Každé ráno sa vykonáva postupnosť krokov, ktoré zabezpečia spracovanie cca 99% OSM dát (t.j. všetky, ktoré nespracovávajú neskôr).| Časový posun | názov procesu: jeho popis |
|---|---|
| +0min | osmparser: Stiahnutie zmien z OSM.org servera za prechádzajúci deň, orezanie dát na BBOX Slovenska |
| +10min | osmparser: Naimportovanie súboru so zmenami do databázy |
| +20min | osmparser: Spracovanie relácií (turistických, cyklistických, MHD, ...) |
| +35min | osmparser: Export nových/zmenených dát z databázy do súboru vo formáte pre TRAPI |
| +40min | trapi/trapilow: TRAPI+LowTRAPI nachádza vo svojom vstupnom adresári nový subor a začína s jeho importom |
| +45min | osmparser: Výpočet z/x/y koordinátov zmenených tiles a ich označenie (ako "dirty") na prerenderovanie DiSK klientmi |
| +1h10min | osmparser: Ukončenie procesu |
| +1h0min až +1h30min | trapi/trapilow: Ukončenie procesu |
| +1h45min | disk: Začatie renderovania DiSK klientmi. |
| +4h až +12h | disk: Ukončenie renderovania, závisí od počtu tiles, ich komplexnosti a počte/výkone renderujúcich DiSK klientov |
Na serveri bežia nepretržite nasledujúce procesy/služby:
- disk upload - po uploade vyrenderovaných obrázkov DiSK klientom, sú tieto rozbalené do preddefinovaného adresára
- postprocessing - vyrenderované obrázky sú porovnané s existujúcimi na serveri, a ak sa líšia, sú posunuté na ďalšie spracovanie
- prerendering - proces LayerAllInOne AllInOne načíta všetky potrebné vrstvy (podkladový tile, reliéf, vrstevnice, názvy, turistické/cyklistické trasy, ...) a vygeneruje finálny tile pre A+C+T vrstvy.
Priorita spracovania tiles:
z8-z14: najprv sa spracovávajú tiles na z8, potom z9 ... až nakoniec z14. Pre každú vrstvu sa začína na najmenšej súradnici X (západna strana mapy), pre ktorú sa prechádza od najmenšej súradnice Y (sever) až po maximálnu súradnicu Y (juh). Následne sa nájde ďalšia súradnica X (kde sú zmenené tiles) a postup sa opakuje. Na jednu iteráciu sa spracuje 32 tiles. Ak počas spracovania týchto tiles napr. na z14, pribudnú do fronty prioritnejšie tiles (z13 a menej), tak v ďalšej iterácii sa proces vráti späť a spracuje ich prednostne. Príklad SQL príkazu by mohol byť:
z15+z16: pre každý zoom beží separátny proces (pre z16 až dva procesy), ktorý postupne spracuje tiles od západu na východ a až po dosiahnutí východnej hranice mapy sa vráti späť na západnú hranicu a postup opakuje (ak medzitým pribudli nejaké nové tiles do fronty). Týmto je zabezpečené rovnomerné spracovanie mapy aj pri vačšom počte tiles pre každý zoom (na z15 je 150 tisíc tiles, na z16 až 600 tisíc, kým na z8 až z14 je dokopy len 51 tisíc tiles).
z8-z14: najprv sa spracovávajú tiles na z8, potom z9 ... až nakoniec z14. Pre každú vrstvu sa začína na najmenšej súradnici X (západna strana mapy), pre ktorú sa prechádza od najmenšej súradnice Y (sever) až po maximálnu súradnicu Y (juh). Následne sa nájde ďalšia súradnica X (kde sú zmenené tiles) a postup sa opakuje. Na jednu iteráciu sa spracuje 32 tiles. Ak počas spracovania týchto tiles napr. na z14, pribudnú do fronty prioritnejšie tiles (z13 a menej), tak v ďalšej iterácii sa proces vráti späť a spracuje ich prednostne. Príklad SQL príkazu by mohol byť:
SELECT z, x, y FROM tiles WHERE state="needs_merge" ORDER BY z, x, y LIMIT 0,32;
z15+z16: pre každý zoom beží separátny proces (pre z16 až dva procesy), ktorý postupne spracuje tiles od západu na východ a až po dosiahnutí východnej hranice mapy sa vráti späť na západnú hranicu a postup opakuje (ak medzitým pribudli nejaké nové tiles do fronty). Týmto je zabezpečené rovnomerné spracovanie mapy aj pri vačšom počte tiles pre každý zoom (na z15 je 150 tisíc tiles, na z16 až 600 tisíc, kým na z8 až z14 je dokopy len 51 tisíc tiles).
- packaging - proces TileDistribution DPC načíta 128 tiles, spraví balíček, ten rozdistribuuje na cieľové servery a/b/c/d.freemap, kde sa rozbalí. Ak nemá vo fronte k dispozícii 128 tiles, tak sa zastaví na 15 minút.
2. občasné renderovanie
Do tejto oblasti spadá renderovanie názvov obcí/lokalít/rázcestníkov/... a POI, pri ktorých treba zabezpečiť, aby sa neprekrývali na jednolivých zoom-och a taktiež neboli príliš blízko pri sebe. Vzhľadom na veľkú časovú náročnosť výpočtu (kde pre niekoľko stoviek tisíc bodov je potrebné vypočítať vzájomné prekrytie), sa tento proces spúšťa len raz za mesiac.- POI placement - optimalizuje rozmiestnenie a viditeľnosť POI ikony
- label placement - optimalizuje rozmiestnenie a viditeľnosť názvov
| zoom | Labels celkovo | Viditelných Labels | Čas výpočtu |
|---|---|---|---|
| 8 | 82 | 55 | 3s |
| 9 | 404 | 282 | 13s |
| 10 | 6767 | 2461 | 3m20s |
| 11 | 29195 | 5490 | 17m47s |
| 12 | 42723 | 11923 | 27m3s |
| 13 | 78085 | 21059 | 70m52s |
| 14 | 149305 | 79361 | 308m35s |
| 15 | 150954 | 102921 | 412m17s |
| 16 | 151573 | 118584 | 493m26s |
rôzne poznámky
- rychlost renderovania: po vacsinu roka by som to zvladal renderovat sam, ale to by posledne zmeny na mape boli viditelne az okolo vecera alebo az v noci (co by niekomu mohlo narusit pokojny spanok ;) ). Aktualny stav sa da porovnat s internetovym pripojenim: asi nikto nema 1mbit linku, ktoru vyuziva 24 hodin denne na maximum. Kedze mame rychle linky, za kratky cas stiahneme data a mozme sa venovat niecomu inemu. Takisto DiSK klienti rozoberu frontu 100-200 tiles denne za 2 az 4 hodiny a potom mozu "odpocivat" :) Tiez ma aktualny stav dve vyhody:
1) ak niekto vypadne (napr. HW problem, dovolenka), ostatni ho zastupia, len sa trochu predlzi cas renderovania
2) mame rezervu na planovane rozsirenie renderovania, t.j. jednak planujeme pokryt CR a sfunkcnit zoomy 17+18, co by pomohlo hlavne v obciach (POI, adresy). Obe tieto aktivity blokuje aktualny centralizovany sposob renderovania nazvov a POI, ktory je uz na hranici svojich moznosti (resp. za nou).
- LowZoom, t.j. z8 az z11: 99% zmien vykonanych na mape nie je viditelnych na tychto zoomoch, napr. ak spresnite cestu tym, ze ju posuniete o 20 metrov (napr. podla Bing), na tychto zoomoch nepostrehnete ziadny rozdiel. Pritom taka zmena vynuti renderovanie prislusnych tiles na z8 az z11, a napr. na z8 treba stiahnut viac ako 300MB OSM dat na 1 tile a potom par hodin ho renderovat. A nasledujuci den sa udeje podobna zmena a kolotoc sa opakuje :) Pritom sa dost casto stavalo, ze niekoho ineho DiSK si zobral taketo "velke susto" a nepodarilo sa mu tile vyrenderovat kvoli nedostatku RAM. Nasledne mapa vyzerala poskodena a musel som manualne opravovat tile za tile-om, aby ho zase neuchmatol niekto iny. Aby sa takto zbytocne neplytvalo dostupnymi prostriedkami, renderuje sa LowZoom raz za mesiac, nepisane pravidlo je, ze je to prvy vikend v mesiaci. Samozrejme na poziadanie sa LowZoom prerenderuje hocikedy, napr. ak ste robili velke zmeny landuse a potrebujete pouzit vyrez z mapy na z11.
- DiSK statistiky: tie sa aktualizuju len vtedy, ked DiSK bezi v mode "./tilesGen.pl loop". Ak pouzijete "xy" a nasledne "upload", server ponechava dany tile tomu uzivatelovi, ktory ho naposledy vyrenderoval cez "loop". Ak si na mape nastavite zomm 12, a v pravom rohu z "Viac vrstiev..." vyberiete "Rendered by", vypise sa na kazdy tile informacia, kto ho renderoval a kedy zacalo renderovanie (t.j. bol mu prideleny serverom). Tento cas mozete porovnat s tym, ktory ziskate kliknutim pravym tlacitlom mysi na tile a kliknutim na ikonu "Tile info" - toto je cas ulozenia vyrenderovanych tiles na serveri, a mal by byt o par minut az hodin posunuty (ale menej ako 24hodin). Posledna funkcia sluzi na manualne vynutenie tile na prerenderovanie: kliknut na dany tile pri stlacenej klavese CTRL, stranka sa vas opyta, ci chcete zaradit tile na prerenderovanie, potvrdit. Po skonceni renderovania obnovit stranku (pripadne aj vymazat cache prehliadaca) a ak vysledok nie je ocakavany, hlasit!
- LayerUpload=1 - takto sa odosielaju vyrenderovane vrstvy priebezne ako mape ZIP subory. Ak to nastavite na 0, bude sa robit upload len na uplnom konci a vtedy to moze ovplyvnit funkcnost internetoveho pripojenia, ak mate pomaly upload (napr. DSL linka). Takisto serveru pomaha, ked mu chodia vysledky priebezne a nie narazovo.
- prava: DiSK klient nevyzaduje ziadne specialne prava, preto nema zmysel robit hocico pod root-om. Kedze vsetci moji DiSK klienti boli nainstalovali pod beznym pouzivatelom, nikdy som nenatrafil na problem so startovanim :)
- expiracia tiles: tile sa dostane do fronty na renderovanie, ak splni jednu z nasledujucich podmienok:
1) bol zmeneny za predchadzajuci den, t.j. automaticky ho prida denna aktualizacia
2) uplynulo 60 dni od posledneho renderovania (aktualne mame 200 tiles na z12, ktore boli naposledy renderovane pred viac ako 50 dnami, a ak sa na nich nic nezmeni, do 10 dni sa automaticky ocitnu vo fronte)
3) niekto manualne naklikal tile na prerenderovanie