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

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 na gmail.com> napsal(a): zobrazit citaci -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub

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

Moc libi - pokracovat :)

zdar, zobrazit citaci pěkné, jenom si myslím, že by to mohlo brát delší časové období ... zobrazit citaci 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.

2008/10/7 Karel Volný <kavol na seznam.cz>: zobrazit citaci 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

Ahoj, neco podobneho je tady: http://www.itoworld.com/static/osmmapper hanoj

Tomas Kolda napsal(a): zobrazit citaci 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!

zobrazit citaci Ne, pokud se hybe nodem tak ne, ale pokud se pridavaji nebo ubiraji nody nebo meni tagy tak jo. zobrazit citaci Kdyz se to pusti jen na nody, tak to "sviti" o neco mene, ale ne zas o moc. zobrazit citaci Mozna bych mohl vygenerovat dva obrazky zvlast, jeden pro nodes, jeden pro ways 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). 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 Pokud se to vejde do pameti, tak to bude asi lepsi nez to mit na disku. Uvidime :) zobrazit citaci 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

zobrazit citaci 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 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

BH napsal(a): zobrazit citaci Tak jsem to myslel... zobrazit citaci ... ale tady se rozchazime ;-) zobrazit citaci 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!

Ahoj! zobrazit citaci ... zobrazit citaci Rozhodne se libi ;-). zobrazit citaci 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

On 07/10/2008, Petr Nejedly <Petr.Nejedly na sun.com> wrote: zobrazit citaci 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 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

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 ------------- další část --------------- A non-text attachment was scrubbed... Name: osm-age.pl Type: application/octet-stream Size: 7319 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081007/170db1e8/attachment.obj>