« zpět na výpis měsíce |

[Talk-cz] Vizualizace aktivity v OSM

Vlákno 7.10. - 7.10.2008, počet zpráv: 14


7.10.2008 05:07:07 (#1)
gravatar

BH

<singularita at gmail.com>
306
Tak mne napadlo, ze by mohlo byt zajimave zjistit kde to v OSM zije nebo hnije ... aneb zjistit jaka mista lidi edituji. Spatlal jsem maly skriptik, ktery projde czechii (nebo i jiny dump) a body a ways ktere se za posledni 3 tydny zmenily oznaci na skale od modre (3 tydny stare) pres bilou (1 tyden stare) po cervenou (nejnovejsi data v souboru, podle atributu timestamp) Bere to body a ways (u ways oznaci pak vsechny body, pokud uz body nemaji novejsi timestamp), ignoruje to relace. Vysledky jsem dal na: http://git.wz.cz/czechia-081006-3whist.png (1600 pixelu siroky) - je tam treba videt pomerne velka nedavna aktivita na silnicich ve strednich cechach a na jizni morave. Pro zajimavost jsem tam soupnul i vetsi verze czechia-081006-3whist-4x.png (6400pix) czechia-081006-3wlist-10x.png (16000pix) A to same jeste pustene na nejstarsi dump dostupny u Kubajze czechia-071115-3whist.png Co si o tom myslite? Ma cenu to poustet nejak systematicky/pravidelne, nebo na nejake vetsi/mensi/jine vyrezy newbo s jinym nastavenim? Nejake napady na vylepseni? Je to relativne rychle, z czechie to udela obrazek za par minut (dle velikosti), takze se to da dat nekam treba do cronu (bohuzel nemam nikde na netu na tohle vhodny stroj), mala nevyhoda skriptu je, ze musi nody drzet v pameti (byt jen jejich id a souradnice), takze na vetsi sady (planet, cele US, cela evropa) by to asi pouzit neslo. Skript (v perlu) na generovani opensourcnu, az ho trochu ucesu a debordelizuju .... Martin

7.10.2008 07:02:18 (#2)
gravatar

Jachym Cepicky

<jachym.cepicky at gmail.com>
407 93
M? se to l?b?. Mysl?m, ?e m?t takov?hle obr?zek ?ekn?me jednou za t?den, m??e za rok d?t p?kn? filmek. j Dne 7. ??jen 2008 5:07 BH <singularita at gmail.com> napsal(a): zobrazit citaci
> Tak mne napadlo, ze by mohlo byt zajimave zjistit kde to v OSM zije > nebo hnije ... aneb zjistit jaka mista lidi edituji. Spatlal jsem maly > skriptik, ktery projde czechii (nebo i jiny dump) a body a ways ktere > se za posledni 3 tydny zmenily oznaci na skale od modre (3 tydny > stare) pres bilou (1 tyden stare) po cervenou (nejnovejsi data v > souboru, podle atributu timestamp) > Bere to body a ways (u ways oznaci pak vsechny body, pokud uz body > nemaji novejsi timestamp), ignoruje to relace. > > Vysledky jsem dal na: > http://git.wz.cz/czechia-081006-3whist.png (1600 pixelu siroky) > - je tam treba videt pomerne velka nedavna aktivita na silnicich ve > strednich cechach a na jizni morave. > > Pro zajimavost jsem tam soupnul i vetsi verze > czechia-081006-3whist-4x.png (6400pix) > czechia-081006-3wlist-10x.png (16000pix) > A to same jeste pustene na nejstarsi dump dostupny u Kubajze > czechia-071115-3whist.png > > Co si o tom myslite? Ma cenu to poustet nejak systematicky/pravidelne, > nebo na nejake vetsi/mensi/jine vyrezy newbo s jinym nastavenim? > Nejake napady na vylepseni? > > Je to relativne rychle, z czechie to udela obrazek za par minut (dle > velikosti), takze se to da dat nekam treba do cronu (bohuzel nemam > nikde na netu na tohle vhodny stroj), mala nevyhoda skriptu je, ze > musi nody drzet v pameti (byt jen jejich id a souradnice), takze na > vetsi sady (planet, cele US, cela evropa) by to asi pouzit neslo. > > Skript (v perlu) na generovani opensourcnu, az ho trochu ucesu a > debordelizuju .... > > Martin > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
-- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

7.10.2008 08:02:52 (#3)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Ahoj, je to hezky, ale nechapu 2 veci. Proc je potreba mit vsechny nody v pameti? Dve moznosti: 1. Vykresli se cela cesta i kdyz se v ni hybne treba jen jednim nodem? To bych mozna takto nezeslozitoval... Jak to vypada kdyz se kresli jen modifikace nodu? Kdyz se totiz pridava way, tak by se rozsvitila, pokud se jen upravi geometrie, rozsviti se skutecne jen ten nod. Chapu, ze by to svitilo mnohem mene, ale asi by vice odrazelo realitu. Nevyhoda: Neviditelne pracne zpresnovani tagu a uprava ways... 2. Prochazet osm.xml 2x. V prvnim prubehu si poznamenat idcka nodu, ktere nalezi zmenenym ways a jez se maji vykreslit. V druhem uz probihat identicky jako u 1 s tim, ze se vykresli navic i ty s timestamp. Pokud budou kolizni vykreslit tou svetlejsi barvou. V teto variante budou mezivysledky asi dost male (vse se ihned kresli a pamatuji se jen IDcka nodu ze zmenenych ways), ale pro poradnou paranoiu se da pouzit sqlite jako zasobarna IDcek. Nejhezci by bylo pri prvnim pruchodu udelat mezisoubor s nodama (napr. ID\tabLAT\tLON), ktery bude zarucene sesortovany podle ID a ten pak jenom mergovat se sesortovanym mezivysledkem nodu zmenenych ways (sort | uniq). Pak je pametova naroznost nulova pro libovolnou velikost dat. Pokud to vypada slozite tak z duvodu me snizene schopnosti se vyjadrovat :) No a druha vec, kterou nechapu je pouziti PERLu :-) Ale to je ciste z duvodu, ze jsem do nej nemel nikdy silu proniknout (bohuzel jsem se drive naucil citelnejsi jazyky). Pro mensi znalce (jako ja), je pak nulova moznost do takoveho kodu prispet... Ale jinak hezka a efektni prace. T BH writes: zobrazit citaci
> Tak mne napadlo, ze by mohlo byt zajimave zjistit kde to v OSM zije > nebo hnije ... aneb zjistit jaka mista lidi edituji. Spatlal jsem maly > skriptik, ktery projde czechii (nebo i jiny dump) a body a ways ktere > se za posledni 3 tydny zmenily oznaci na skale od modre (3 tydny > stare) pres bilou (1 tyden stare) po cervenou (nejnovejsi data v > souboru, podle atributu timestamp) > Bere to body a ways (u ways oznaci pak vsechny body, pokud uz body > nemaji novejsi timestamp), ignoruje to relace. > > Vysledky jsem dal na: > http://git.wz.cz/czechia-081006-3whist.png (1600 pixelu siroky) > - je tam treba videt pomerne velka nedavna aktivita na silnicich ve > strednich cechach a na jizni morave. > > Pro zajimavost jsem tam soupnul i vetsi verze > czechia-081006-3whist-4x.png (6400pix) > czechia-081006-3wlist-10x.png (16000pix) > A to same jeste pustene na nejstarsi dump dostupny u Kubajze > czechia-071115-3whist.png > > Co si o tom myslite? Ma cenu to poustet nejak systematicky/pravidelne, > nebo na nejake vetsi/mensi/jine vyrezy newbo s jinym nastavenim? > Nejake napady na vylepseni? > > Je to relativne rychle, z czechie to udela obrazek za par minut (dle > velikosti), takze se to da dat nekam treba do cronu (bohuzel nemam > nikde na netu na tohle vhodny stroj), mala nevyhoda skriptu je, ze > musi nody drzet v pameti (byt jen jejich id a souradnice), takze na > vetsi sady (planet, cele US, cela evropa) by to asi pouzit neslo. > > Skript (v perlu) na generovani opensourcnu, az ho trochu ucesu a > debordelizuju .... > > Martin > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

7.10.2008 09:06:35 (#4)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Moc libi - pokracovat :)

7.10.2008 09:33:30 (#5)
gravatar

Karel Volný

<kavol at seznam.cz>
515
zdar, zobrazit citaci
> Tak mne napadlo, ze by mohlo byt zajimave zjistit kde to v OSM zije > nebo hnije ... aneb zjistit jaka mista lidi edituji. Spatlal jsem maly > skriptik, ktery projde czechii (nebo i jiny dump) a body a ways ktere > se za posledni 3 tydny zmenily oznaci na skale od modre (3 tydny > stare) pres bilou (1 tyden stare) po cervenou (nejnovejsi data v > souboru, podle atributu timestamp)
p?kn?, jenom si mysl?m, ?e by to mohlo br?t del?? ?asov? obdob? ... zobrazit citaci
> Je to relativne rychle, z czechie to udela obrazek za par minut (dle > velikosti), takze se to da dat nekam treba do cronu (bohuzel nemam > nikde na netu na tohle vhodny stroj)
t?ch "p?r minut" je na jak?m ?eleze? m?m jednu mrchu, kde by nevadilo si to n?kdy v noci pou?t?t; nen? vyb?rav?, ch?oupe i Perl ;-) ... jedin? v?c je, ?e nen? zrovna za tlustolinkou, ale to by se dalo vy?e?it pushem hotov?ho obr?zku na n?jak? hosting K.

7.10.2008 09:38:53 (#6)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2008/10/7 Karel Voln? <kavol at seznam.cz>: zobrazit citaci
> > zdar, > >> Tak mne napadlo, ze by mohlo byt zajimave zjistit kde to v OSM zije >> nebo hnije ... aneb zjistit jaka mista lidi edituji. Spatlal jsem maly >> skriptik, ktery projde czechii (nebo i jiny dump) a body a ways ktere >> se za posledni 3 tydny zmenily oznaci na skale od modre (3 tydny >> stare) pres bilou (1 tyden stare) po cervenou (nejnovejsi data v >> souboru, podle atributu timestamp) > > p?kn?, jenom si mysl?m, ?e by to mohlo br?t del?? ?asov? obdob? ... > >> Je to relativne rychle, z czechie to udela obrazek za par minut (dle >> velikosti), takze se to da dat nekam treba do cronu (bohuzel nemam >> nikde na netu na tohle vhodny stroj) > > t?ch "p?r minut" je na jak?m ?eleze? > > m?m jednu mrchu, kde by nevadilo si to n?kdy v noci pou?t?t; nen? vyb?rav?, > ch?oupe i Perl ;-) ... jedin? v?c je, ?e nen? zrovna za tlustolinkou, ale to > by se dalo vy?e?it pushem hotov?ho obr?zku na n?jak? hosting > > K. > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
no ja mam mrchu ktere nevadi ani to stahovani (po nixu, ze zahranici je tam nakej limit) a v noci je casu spousta -- Michal Gr?zl http://walley.org

7.10.2008 10:48:39 (#7)
gravatar

hanoj

<ehanoj at gmail.com>
713
Ahoj, neco podobneho je tady: http://www.itoworld.com/static/osmmapper hanoj

7.10.2008 11:37:23 (#8)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> Ahoj, > > je to hezky, ale nechapu 2 veci. > > Proc je potreba mit vsechny nody v pameti? Dve moznosti: > 1. Vykresli se cela cesta i kdyz se v ni hybne treba jen jednim nodem? To > bych mozna takto nezeslozitoval... Jak to vypada kdyz se kresli jen > modifikace nodu? Kdyz se totiz pridava way, tak by se rozsvitila, pokud se > jen upravi geometrie, rozsviti se skutecne jen ten nod. Chapu, ze by to > svitilo mnohem mene, ale asi by vice odrazelo realitu. Nevyhoda: Neviditelne > pracne zpresnovani tagu a uprava ways... > > 2. Prochazet osm.xml 2x. V prvnim prubehu si poznamenat idcka nodu, ktere > nalezi zmenenym ways a jez se maji vykreslit. V druhem uz probihat identicky > jako u 1 s tim, ze se vykresli navic i ty s timestamp. Pokud budou kolizni > vykreslit tou svetlejsi barvou. V teto variante budou mezivysledky asi dost > male (vse se ihned kresli a pamatuji se jen IDcka nodu ze zmenenych ways), > ale pro poradnou paranoiu se da pouzit sqlite jako zasobarna IDcek. > > Nejhezci by bylo pri prvnim pruchodu udelat mezisoubor s nodama (napr. > ID\tabLAT\tLON), ktery bude zarucene sesortovany podle ID a ten pak jenom > mergovat se sesortovanym mezivysledkem nodu zmenenych ways (sort | uniq). > Pak je pametova naroznost nulova pro libovolnou velikost dat. Pokud to > vypada slozite tak z duvodu me snizene schopnosti se vyjadrovat :)
Nadherna prace, zlaty merge sort (sort -m) Ale vyrobit ten druhy sesortovany soubor taky nebude zadarmo.... Tak jako tak, world ma kolem 300M nodu, to se da pro tenhle ucel stale zpracovat v gigu RAM (kdyz si clovek sikovne pohraje s bity). -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

7.10.2008 12:57:16 (#9)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> Proc je potreba mit vsechny nody v pameti? Dve moznosti: > 1. Vykresli se cela cesta i kdyz se v ni hybne treba jen jednim nodem? To
Ne, pokud se hybe nodem tak ne, ale pokud se pridavaji nebo ubiraji nody nebo meni tagy tak jo. zobrazit citaci
> bych mozna takto nezeslozitoval... Jak to vypada kdyz se kresli jen > modifikace nodu? Kdyz se totiz pridava way, tak by se rozsvitila, pokud se
Kdyz se to pusti jen na nody, tak to "sviti" o neco mene, ale ne zas o moc. zobrazit citaci
> jen upravi geometrie, rozsviti se skutecne jen ten nod. Chapu, ze by to > svitilo mnohem mene, ale asi by vice odrazelo realitu. Nevyhoda: Neviditelne > pracne zpresnovani tagu a uprava ways...
Mozna bych mohl vygenerovat dva obrazky zvlast, jeden pro nodes, jeden pro ways zobrazit citaci
> 2. Prochazet osm.xml 2x. V prvnim prubehu si poznamenat idcka nodu, ktere > nalezi zmenenym ways a jez se maji vykreslit. V druhem uz probihat identicky > jako u 1 s tim, ze se vykresli navic i ty s timestamp. Pokud budou kolizni > vykreslit tou svetlejsi barvou. V teto variante budou mezivysledky asi dost > male (vse se ihned kresli a pamatuji se jen IDcka nodu ze zmenenych ways), > ale pro poradnou paranoiu se da pouzit sqlite jako zasobarna IDcek.
U nodu skladuju jako klic ID (zatim se do 32bitu vejde :) a jako hodnotu prepocitane souradnice v obrazku (coz se narozdil od 2x double vejde s prehledem do 32 bitu). Teoreticky min. 8 bajtu/nod, ale je to nejaky overhead u pouzitych datovych struktur. Takze udelat to pro planet by asi slo po mensi optimalizaci i na 4gb ram (neco sezere i vystupni obrazek, ktery by mel byt pro planet asi velky, aby bylo neco videt) Moc bitu se uz usetrit neda, pro cely planet a vetsi obrazky se to u obou k tem 32 bitm celkem dost blizi (takze 300M nodes=min 2.4gb ram) zobrazit citaci
> Nejhezci by bylo pri prvnim pruchodu udelat mezisoubor s nodama (napr. > ID\tabLAT\tLON), ktery bude zarucene sesortovany podle ID a ten pak jenom > mergovat se sesortovanym mezivysledkem nodu zmenenych ways (sort | uniq). > Pak je pametova naroznost nulova pro libovolnou velikost dat. Pokud to > vypada slozite tak z duvodu me snizene schopnosti se vyjadrovat :)
Pokud se to vejde do pameti, tak to bude asi lepsi nez to mit na disku. Uvidime :) zobrazit citaci
> No a druha vec, kterou nechapu je pouziti PERLu :-) Ale to je ciste z > duvodu, ze jsem do nej nemel nikdy silu proniknout (bohuzel jsem se drive > naucil citelnejsi jazyky). Pro mensi znalce (jako ja), je pak nulova moznost > do takoveho kodu prispet...
Za zaklad jsem vzal nejaky svuj starsi skript pracujici s OSM .... ktery byl v perlu :) Ma to asi 3kb, mozna o prepisu do c++, kde by sly nektere veci delat asi precejen efektivneji. Martin

7.10.2008 01:00:35 (#10)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> p?kn?, jenom si mysl?m, ?e by to mohlo br?t del?? ?asov? obdob? ...
Asi bych mohl vygenerovat rovnou vice obrazku, kazdy s jinym casovym zakladem (jeden 3 tydny jako tento, pak treba 3 dny, 3 mesice a mozna i jeden nebo 3 roky). Nejdele trva nacitani dumpu, takze generovani vice variant je rychle .... zobrazit citaci
>> Je to relativne rychle, z czechie to udela obrazek za par minut (dle >> velikosti), takze se to da dat nekam treba do cronu (bohuzel nemam >> nikde na netu na tohle vhodny stroj) > > t?ch "p?r minut" je na jak?m ?eleze?
Core2quad Q6600 2.4ghz, 4 gb ram (ten 16000pix siroky obrazek sezral asi 1.3gb pri generovani). I kdyz ten skript je jen jednovlaknovy... Martin

7.10.2008 01:55:05 (#11)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
BH napsal(a): zobrazit citaci
> U nodu skladuju jako klic ID (zatim se do 32bitu vejde :) a jako > hodnotu prepocitane souradnice v obrazku (coz se narozdil od 2x double > vejde s prehledem do 32 bitu).
Tak jsem to myslel... zobrazit citaci
> Teoreticky min. 8 bajtu/nod, ale je to
... ale tady se rozchazime ;-) zobrazit citaci
> nejaky overhead u pouzitych datovych struktur. Takze udelat to pro > planet by asi slo po mensi optimalizaci i na 4gb ram (neco sezere i > vystupni obrazek, ktery by mel byt pro planet asi velky, aby bylo neco > videt) > Moc bitu se uz usetrit neda, pro cely planet a vetsi obrazky se to u > obou k tem 32 bitm celkem dost blizi (takze 300M nodes=min 2.4gb ram)
Vzhledem k tomu, ze set ID je vcelku huste populovany (pokud se bavime o celem world), nema smysl IDcka drzet a hashovat. ID je samo nejlepsim "hashem", nody jsou pak jen jednoduchym polem 32bit hodnot prepocitanych souradnic. Co node, to jeden int. Chci node 227321453, sahnu na [227321453]. Spotreba 1.2GB RAM. Ale je to hack tak na rok, dva, pak uz zase tech nodu asi bude moc.... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

7.10.2008 02:46:51 (#12)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> Tak mne napadlo, ze by mohlo byt zajimave zjistit kde to v OSM zije > nebo hnije ... aneb zjistit jaka mista lidi edituji. Spatlal jsem maly > skriptik, ktery projde czechii (nebo i jiny dump) a body a ways ktere > se za posledni 3 tydny zmenily oznaci na skale od modre (3 tydny > stare) pres bilou (1 tyden stare) po cervenou (nejnovejsi data v > souboru, podle atributu timestamp) > Bere to body a ways (u ways oznaci pak vsechny body, pokud uz body > nemaji novejsi timestamp), ignoruje to relace.
... zobrazit citaci
> Co si o tom myslite? Ma cenu to poustet nejak systematicky/pravidelne, > nebo na nejake vetsi/mensi/jine vyrezy newbo s jinym nastavenim? > Nejake napady na vylepseni?
Rozhodne se libi ;-). zobrazit citaci
> Skript (v perlu) na generovani opensourcnu, az ho trochu ucesu a > debordelizuju ....
To se tradicne dela obracene. Opensourcnu aby mi to lidi pomohli debordelizovat ;-). -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

7.10.2008 02:49:20 (#13)
gravatar

BH

<singularita at gmail.com>
306
On 07/10/2008, Petr Nejedly <Petr.Nejedly at sun.com> wrote: zobrazit citaci
> BH napsal(a): > > > U nodu skladuju jako klic ID (zatim se do 32bitu vejde :) a jako > > hodnotu prepocitane souradnice v obrazku (coz se narozdil od 2x double > > vejde s prehledem do 32 bitu). > > Tak jsem to myslel... > > > > Teoreticky min. 8 bajtu/nod, ale je to > > ... ale tady se rozchazime ;-)
Zavisi na velikosti vysledneho obrazku. Pokud generuju neco "rozumne" velikeho, tak se sice do 3 bajtu vejdu, ale zase zadny tribajtovy typ neni (=opruz s posouvanim bitu mezi byte a word = pomale) a 2 bajty jsou malo (256x256 obrazek je moc mrnavy) Nebo kde by se dalo usetrit, krome prime indexace IDckem? zobrazit citaci
> > nejaky overhead u pouzitych datovych struktur. Takze udelat to pro > > planet by asi slo po mensi optimalizaci i na 4gb ram (neco sezere i > > vystupni obrazek, ktery by mel byt pro planet asi velky, aby bylo neco > > videt) > > Moc bitu se uz usetrit neda, pro cely planet a vetsi obrazky se to u > > obou k tem 32 bitm celkem dost blizi (takze 300M nodes=min 2.4gb ram) > > > Vzhledem k tomu, ze set ID je vcelku huste populovany (pokud se bavime > o celem world), nema smysl IDcka drzet a hashovat. ID je samo nejlepsim > "hashem", nody jsou pak jen jednoduchym polem 32bit hodnot prepocitanych souradnic. > Co node, to jeden int. Chci node 227321453, sahnu na [227321453]. > Spotreba 1.2GB RAM. > > Ale je to hack tak na rok, dva, pak uz zase tech nodu asi bude moc....
To je pravda, to by slo. Mohlo by to vydrzet i dele, vzdyt mame 64bit architektury (na rozumne provozovani vice nez 2 gb ram je stejne tech 64bit potreba), proste se dokoupi pamet :) Ted je ale otazkou jestli budou data v OSM rust rychleji, nez budou klesat ceny pameti .... Ale na mensi kusy zase bude lepsi klasicky hash :) Asi to prepisu do C++, tady zacina perl trochu ztracet dech :) Martin

7.10.2008 04:57:14 (#14)
gravatar

BH

<singularita at gmail.com>
306
Tak jsem udelal upravy ve skriptu. Zjistil jsem, ze pokud do jednoho obrazku zakresluji nodes+ways tak je vystup pomerne podobny tomu, kdyz tam zakresluji pouze ways. Asi se obvykle s nodes edituji i ways okolo, byt jsou vyjimky (napr import z UIR-ADR do OSM nacpal velke mnozstvi nodes). nodes a ways se pak uz celkem lisi (clovek upravi maly kus dlouhe cesty, ale v mape vznikne "velka cara") Asi bych do budoucna generoval jenom NODES a pak NODES+WAYS. Zkousel jsem generovat i vice obrazku s ruznym nastavenim hloubky historie or 3 dnu po 3 roky, ty 3 roky jsou skoro homogenni cervena s obcasnym bilym zilkovanim, modra nikde, data nezmenena dele nez cca 1.5 roku asi v OSM v CR nejsou :) -> imho nema smysl generovat vice nez rocni historii. Doba behu na nejnovejsim dumpu: 195 sekund parsovani a zpracovani XML 61 sekund generovani sady obrazku (15 obrazku, 1600x911 kazdy) Bezelo to na C2Q Q6600, 2.4Ghz Skript je v priloze. Trochu jsem ho upravil a okomentoval. Vysledky (s ruznym casovym nastavenim a zobrazovanim nodes/ways/oboji) jsem hodil na http://git.wz.cz/czechia-081007-history.zip Tak se na to mrknete a reknete nazory na upravenou verzi. Ad rozliseni: 1600x900 je akorat? malo? moc? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: osm-age.pl Type: application/octet-stream Size: 7318 bytes Desc: not available URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081007/170db1e8/attachment.obj>

« zpět na výpis měsíce