Re: [Talk-cz] Vizualizace aktivity v OSM
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 osm-age.pl Description: Binary data ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
On 07/10/2008, Petr Nejedly <[EMAIL PROTECTED]> wrote: > 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? > > 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
Ahoj! > 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. ... > 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 ;-). > 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
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 ;-) > 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! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
> 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 >> 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
> 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. > 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. > 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 > 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) > 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 :) > 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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
Tomas Kolda napsal(a): > 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! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
Ahoj, neco podobneho je tady: http://www.itoworld.com/static/osmmapper hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
2008/10/7 Karel Volný <[EMAIL PROTECTED]>: > > 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@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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
Moc libi - pokracovat :) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
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: > 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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Vizualizace aktivity v OSM
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 <[EMAIL PROTECTED]> napsal(a): > 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@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 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Vizualizace aktivity v OSM
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
