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

[Talk-cz] pokusny import lesu

Vlákno 12.7. - 22.8.2008, počet zpráv: 160


12.7.2008 11:49:11 (#1)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

13.7.2008 07:00:26 (#2)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > > Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je > malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se > trochu zazelena... Dlazdice jsou vyjmenovany na wiki. > > Pavel >
Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo...

13.7.2008 10:04:08 (#3)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se nasel nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se rekne algoritmus a je to. Staci tedy rict co je treba: 1. Spojit vsechny typy lesu do jednoho typu forest (v nejvetsi presnosti) 2. Udelat generalizaci na potrebnou uroven (Douglas-Plucker neni uplne super na polygony). 3. Rozsekat velke polygony na mensi. 4. Zkontrolovat nekolik uzemi a uploadovat. Ja bych mohl pomoci s nekolika vecma. Jen bych potreboval data. Kdyz da nekdo aktualni link kde jsou, pripadne s nejakym popisem formatu (pokud to neni osm) tak bych to klidne udelal. Podle me dokud nekdo nerekne ja to udelam, tak to neudela nikdo. At tedy nekdo rekne, dostane 14 dni a bude vysledek. Pripadne se muzou zapojit ostatni. Co mam za nebezne algorimy, ktere by se mozna hodily. Uz jsem je dlouho nepouzival, tak by se musely oprasit... - rozpletani polygonu (pokud je jakkoliv slozity self-intersect polygon, umi ho rozmotat). Dobre jako postprocesing polygonove simplifikace - vytvareni polygonu s bodu (vytvori polygon ze site bodu, ktere jsou v polygonu). Napr kdyby byl kazdy strom jeden nod a dal se limit 50 metru tak vytvori obalovy polygon lesa s max. vzdalenosti stromu 50 metru... Umi to i diry. - mergovani polygonu (i protinajicich se), ale tech existuje vice implementaci - simplifikace polygonu s podminkou zvetsovani plochy (zamezuje neduhum Douglas-Plucker) Ted dodelavam prvni public verzi te "navigace", takze nic moc nestiham, ale tak za tyden ci 14 dni bych to mohl zkusit (pokud mi nekdo da data). Kdyz to nekdo dokonci budu mu velmi vdecen, mapicka je pak mnohem krasnejsi.... T Kubajz napsal(a): zobrazit citaci
> Pavel Machek napsal(a): > >> Ahoj! >> >> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je >> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >> >> Pavel >> >> > Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta > data pro jistotu smazu, aby to nekoho nelakalo... > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080713/258ea6ec/attachment.html>

14.7.2008 09:05:46 (#4)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
> Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se nasel > nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se rekne > algoritmus a je to.
*** protoze je to tak zasadni rozsireni, kdy je treba najit takovy konsenzus, aby byl optimalizovan prinos pro stavajici i budouci uzivatele geodat osm. Technicky postup a prace je jedna zasluzna cast, dalsi je predhozeni vysledku ku nahledu ostatnim. Historie se nemusi pokazde opakovat. hanoj

14.7.2008 09:41:59 (#5)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Sun 2008-07-13 22:04:08, Tomas Kolda wrote: zobrazit citaci
> Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se > nasel nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se > rekne algoritmus a je to. > Staci tedy rict co je treba: > 1. Spojit vsechny typy lesu do jednoho typu forest (v nejvetsi > presnosti) > 2. Udelat generalizaci na potrebnou uroven (Douglas-Plucker neni uplne > super na polygony). > 3. Rozsekat velke polygony na mensi. > 4. Zkontrolovat nekolik uzemi a uploadovat. > Ja bych mohl pomoci s nekolika vecma. Jen bych potreboval data. Kdyz da > nekdo aktualni link kde jsou, pripadne s nejakym popisem formatu (pokud > to neni osm) tak bych to klidne udelal. Podle me dokud nekdo nerekne ja > to udelam, tak to neudela nikdo. At tedy nekdo rekne, dostane 14 dni a > bude vysledek. Pripadne se muzou zapojit ostatni.
Zatim data zda-se jsou na: http://kubajz.kbx.cz/junk/uhul/output/ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

14.7.2008 09:43:48 (#6)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Sun 2008-07-13 19:00:26, Kubajz wrote: zobrazit citaci
> Pavel Machek napsal(a): > > Ahoj! > > > > Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je > > malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se > > trochu zazelena... Dlazdice jsou vyjmenovany na wiki. > >
zobrazit citaci
> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta > data pro jistotu smazu, aby to nekoho nelakalo...
Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to byla vetsina) v tomto pripade znamena "nemapovat lesy". A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

14.7.2008 09:50:38 (#7)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): zobrazit citaci
> On Sun 2008-07-13 19:00:26, Kubajz wrote: > >> Pavel Machek napsal(a): >> >>> Ahoj! >>> >>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je >>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>> >>> > > >> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta >> data pro jistotu smazu, aby to nekoho nelakalo... >> > > Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to > byla vetsina) v tomto pripade znamena "nemapovat lesy". > > A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v > Dejvicich, a pak v ni jaksi chybi Sarecky les. > > Pavel >

14.7.2008 10:49:11 (#8)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? T zobrazit citaci
> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem > stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim > poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se > muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou > dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne > s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej > nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze > takhle les zobrazil ve dvou dlazdicich. > > K > > Pavel Machek napsal(a): >> On Sun 2008-07-13 19:00:26, Kubajz wrote: >> >>> Pavel Machek napsal(a): >>> >>>> Ahoj! >>>> >>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je >>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>> >>>> >> >> >>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta >>> data pro jistotu smazu, aby to nekoho nelakalo... >>> >> >> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >> byla vetsina) v tomto pripade znamena "nemapovat lesy". >> >> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >> Dejvicich, a pak v ni jaksi chybi Sarecky les. >> >> Pavel >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

14.7.2008 10:57:57 (#9)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Na traceovani bitmap je spousta kvalitniho softu - bohuzel jsem neprisel na to, jak nacpat EPS nebo DXF do OSM. A pritom by to byla tak jednoducha, pekna a cista prace. Editacni funkce a moznosti JOSM jsou v porovnani s profi grafickym softem hrozne primitivni. Kdybych nebyl grafik, asi by me to netrapilo, ale protoze jsem, tak jsem tim desne frustrovanej :) On Mon, 14 Jul 2008 10:49:11 +0200, <kolda at web2net.cz> wrote: zobrazit citaci
> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m > chybu > v Douglas-Pluckeru. > > Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat > nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor > jiz na UHUL neni. > > Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem > vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal > pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal > potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako > rucni > vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem > adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a > simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v > predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi > nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho > vzniklo... > > Jaky je tedy navrh? XML nebo bitmapa? > > T > > >> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se >> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou >> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne >> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >> takhle les zobrazil ve dvou dlazdicich. >> >> K >> >> Pavel Machek napsal(a): >>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>> >>>> Pavel Machek napsal(a): >>>> >>>>> Ahoj! >>>>> >>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je >>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>> >>>>> >>> >>> >>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta >>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>> >>> >>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>> >>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>> >>> Pavel >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > __________ Informace od NOD32 3263 (20080711) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

14.7.2008 01:35:48 (#10)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ahoj, kolda at web2net.cz napsal(a): zobrazit citaci
> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu > v Douglas-Pluckeru. >
diky za podporu :) zobrazit citaci
> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat > nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor > jiz na UHUL neni. >
ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. zobrazit citaci
> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >
na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? zobrazit citaci
> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal > pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal > potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni > vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem > adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a > simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v > predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi > nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho > vzniklo... > > Jaky je tedy navrh? XML nebo bitmapa? >
bitmapa zobrazit citaci
> T > > > >> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se >> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou >> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne >> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >> takhle les zobrazil ve dvou dlazdicich. >> >> K >> >> Pavel Machek napsal(a): >> >>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>> >>> >>>> Pavel Machek napsal(a): >>>> >>>> >>>>> Ahoj! >>>>> >>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je >>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>> >>>>> >>>>> >>> >>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta >>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>> >>>> >>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>> >>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>> >>> Pavel >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

14.7.2008 02:11:18 (#11)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
No dobra muzeme bitmapu. Ono obecne duplicity nevadi, to odstrani mergovani a simplifikace, ale chybejici data by mohl byt problem. Jen mi prijde skoda tahat takovou spoustu dat (bitmapy nejsou zrovna nejuspornejsi). Opravdu jsou ty data tak strasne nepouzitelny? Nezna nekdo nekoho v UHULu, aby se zeptal jak se dostat na ten WFS? Vektor je vektor... Bitmapa nam pridava krok 0, zbytek je stejny. T zobrazit citaci
> Ahoj, > > kolda at web2net.cz napsal(a): >> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >> chybu >> v Douglas-Pluckeru. >> > diky za podporu :) >> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat >> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor >> jiz na UHUL neni. >> > ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi > spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich > vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky > problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. > Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >> > na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na > obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto > toho to udelal z usecek (hranate)? >> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >> udelal >> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal >> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >> rucni >> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi >> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >> vzniklo... >> >> Jaky je tedy navrh? XML nebo bitmapa? >> > bitmapa >> T >> >> >> >>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se >>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou >>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne >>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >>> takhle les zobrazil ve dvou dlazdicich. >>> >>> K >>> >>> Pavel Machek napsal(a): >>> >>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>> >>>> >>>>> Pavel Machek napsal(a): >>>>> >>>>> >>>>>> Ahoj! >>>>>> >>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech >>>>>> je >>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>> >>>>>> >>>>>> >>>> >>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta >>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>> >>>>> >>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>> >>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>> >>>> Pavel >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

14.7.2008 02:22:16 (#12)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ahoj, kolda at web2net.cz napsal(a): zobrazit citaci
> No dobra muzeme bitmapu. Ono obecne duplicity nevadi, to odstrani > mergovani a simplifikace, ale chybejici data by mohl byt problem. Jen mi > prijde skoda tahat takovou spoustu dat (bitmapy nejsou zrovna > nejuspornejsi).
PNG ma mene nez rozbalene XML, ktere leze z WFS, tudiz nemohu souhlasit... zobrazit citaci
> Opravdu jsou ty data tak strasne nepouzitelny? Nezna nekdo >
Ano jsou. Zrovna jsem se dival na cast Krcskeho lesa, kterou importoval Pavel a krome toho, ze lezi v Polabi ma prazvlastni tvar. Se starym WFS byl ten problem, ze daval data pouze v JTSK a musely se prevadet do wgs84, coz pridavalo dalsi stupen mozne chyby, protoze Krovak nebyl v libproj zrovna spolehlive implementovan - lisil se verzi od verze. zobrazit citaci
> nekoho v UHULu, aby se zeptal jak se dostat na ten WFS? Vektor je > vektor... Bitmapa nam pridava krok 0, zbytek je stejny. >
Rekl bych ze naopak. Parsovani a tahani nekomprimovaneho XML, prevod do jineho typu souradnic, mergovani je prace navic. Podle meho nazoru ta bitmapa spoustu veci resi elegantnim zpusobem (mergovani, prevod souradnic a prvotni simplifikaci). Navic pro praci se bitmapa snadno vizualizuje, na XML je potreba osmarender, ktery je dost pomaly. zobrazit citaci
> T > > >> Ahoj, >> >> kolda at web2net.cz napsal(a): >> >>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >>> chybu >>> v Douglas-Pluckeru. >>> >>> >> diky za podporu :) >> >>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat >>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor >>> jiz na UHUL neni. >>> >>> >> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky >> problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. >> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >> >>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>> >>> >> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na >> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto >> toho to udelal z usecek (hranate)? >> >>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>> udelal >>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal >>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >>> rucni >>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi >>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>> vzniklo... >>> >>> Jaky je tedy navrh? XML nebo bitmapa? >>> >>> >> bitmapa >> >>> T >>> >>> >>> >>> >>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se >>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou >>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne >>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >>>> takhle les zobrazil ve dvou dlazdicich. >>>> >>>> K >>>> >>>> Pavel Machek napsal(a): >>>> >>>> >>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>> >>>>> >>>>> >>>>>> Pavel Machek napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> Ahoj! >>>>>>> >>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech >>>>>>> je >>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta >>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>> >>>>>> >>>>>> >>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>> >>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>> >>>>> Pavel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

14.7.2008 03:41:25 (#13)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
Tak jo, zkusime tedy ty png. Pokud se tedy do toho nikdo nepusti, tak to klidne nejak zkusim pristi tyden. Jakou budem tahat podrobnost? 1 pixel na 5 metru? To by vychazelo tak na priblizne 300x200 tilu po 256x256 pixelu. Poslete mi sem akorat link na ty WMS data at alespon vim odkud pripadne tahat? Muj pripadny postup: 1. Stahnout tiles 2. Prevest na jednobitovou bitmapu. Mozna by to slo i cele spojit (asi 500MB) 3. Prohnat potracem 4. Vyhodit plochy/diry mensi nez X 5. Provest generalizaci (15m chyba) 6. Opravit polygony (self-intersection) 7. Rozsekat polygony na mensi (max. Y nodu) 8. Poslat jich par ke kontrole 9. Poslat vse omarkovane do OSM 10. Smazat pripadne uz nakreslene lesy, ktere nemaji mark (mozna rucne zkontrolovat) Dik T zobrazit citaci
> Ahoj, > > kolda at web2net.cz napsal(a): >> No dobra muzeme bitmapu. Ono obecne duplicity nevadi, to odstrani >> mergovani a simplifikace, ale chybejici data by mohl byt problem. Jen mi >> prijde skoda tahat takovou spoustu dat (bitmapy nejsou zrovna >> nejuspornejsi). > PNG ma mene nez rozbalene XML, ktere leze z WFS, tudiz nemohu souhlasit... >> Opravdu jsou ty data tak strasne nepouzitelny? Nezna nekdo >> > Ano jsou. Zrovna jsem se dival na cast Krcskeho lesa, kterou importoval > Pavel a krome toho, ze lezi v Polabi ma prazvlastni tvar. Se starym WFS > byl ten problem, ze daval data pouze v JTSK a musely se prevadet do > wgs84, coz pridavalo dalsi stupen mozne chyby, protoze Krovak nebyl v > libproj zrovna spolehlive implementovan - lisil se verzi od verze. >> nekoho v UHULu, aby se zeptal jak se dostat na ten WFS? Vektor je >> vektor... Bitmapa nam pridava krok 0, zbytek je stejny. >> > Rekl bych ze naopak. Parsovani a tahani nekomprimovaneho XML, prevod do > jineho typu souradnic, mergovani je prace navic. Podle meho nazoru ta > bitmapa spoustu veci resi elegantnim zpusobem (mergovani, prevod > souradnic a prvotni simplifikaci). Navic pro praci se bitmapa snadno > vizualizuje, na XML je potreba osmarender, ktery je dost pomaly. >> T >> >> >>> Ahoj, >>> >>> kolda at web2net.cz napsal(a): >>> >>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >>>> chybu >>>> v Douglas-Pluckeru. >>>> >>>> >>> diky za podporu :) >>> >>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>> rozpoznat >>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>> vektor >>>> jiz na UHUL neni. >>>> >>>> >>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky >>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>> stahnout. >>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>> >>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>> >>>> >>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na >>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>> misto >>> toho to udelal z usecek (hranate)? >>> >>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>> udelal >>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>> prohnal >>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >>>> rucni >>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>> asi >>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>> vzniklo... >>>> >>>> Jaky je tedy navrh? XML nebo bitmapa? >>>> >>>> >>> bitmapa >>> >>>> T >>>> >>>> >>>> >>>> >>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze >>>>> se >>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>> budou >>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>> zvlastne >>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >>>>> takhle les zobrazil ve dvou dlazdicich. >>>>> >>>>> K >>>>> >>>>> Pavel Machek napsal(a): >>>>> >>>>> >>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Pavel Machek napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Ahoj! >>>>>>>> >>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech >>>>>>>> je >>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha >>>>>>>> se >>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. >>>>>>> Ta >>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>> >>>>>>> >>>>>>> >>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>> >>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>> >>>>>> Pavel >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

14.7.2008 04:28:30 (#14)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ahoj, kolda at web2net.cz napsal(a): zobrazit citaci
> Tak jo, zkusime tedy ty png. Pokud se tedy do toho nikdo nepusti, tak to > klidne nejak zkusim pristi tyden. Jakou budem tahat podrobnost? 1 pixel na >
ja jsem se do toho pustil, tak mi pockej do konce tydne a predam kdyztak vse, co jsem do te doby vytvoril. V sobotu odjizdim na dovolenou, takze pak 14 dni na tom nebudu moci delat ani nahodou. zobrazit citaci
> 5 metru? To by vychazelo tak na priblizne 300x200 tilu po 256x256 pixelu. > > Poslete mi sem akorat link na ty WMS data at alespon vim odkud pripadne > tahat? > > Muj pripadny postup: > 1. Stahnout tiles >
stahuji z WMS po kroku 0.1 stupne v rozliseni 2000x2000 bodu. To dava prijatelnou presnost a neni to prehnane. zobrazit citaci
> 2. Prevest na jednobitovou bitmapu. Mozna by to slo i cele spojit (asi 500MB) > 3. Prohnat potracem >
ale ten vraci krivky. Co s tim dal? Ja bych se klonil k variante bez potrace, pokud neexistuje moznost prehodit ho do rezimu rovnych car. Pokud bychom totiz vzali pouze body a ignorovali ridici body/tecny, tak bychom se dopustili velmi hrube chyby. zobrazit citaci
> 4. Vyhodit plochy/diry mensi nez X >
tech IMO moc neni, ale muze se to udelat. zobrazit citaci
> 5. Provest generalizaci (15m chyba) > 6. Opravit polygony (self-intersection) >
z principu nemaji zobrazit citaci
> 7. Rozsekat polygony na mensi (max. Y nodu) >
celkem dobrej napad, na to jsem zatim nepomyslel zobrazit citaci
> 8. Poslat jich par ke kontrole >
urcite :) Spis vsechny. Chyby se projevi casto na specifickych datech a kazdy z nas zkouma trochu jinou oblast CR. zobrazit citaci
> 9. Poslat vse omarkovane do OSM >
asi ano, ale to bych nechal na diskuzi, az to bude hotove. zobrazit citaci
> 10. Smazat pripadne uz nakreslene lesy, ktere nemaji mark (mozna rucne > zkontrolovat) >
lesu je ted tak malo, ze je popr. odstranime rucne. zobrazit citaci
> Dik T > > >> Ahoj, >> >> kolda at web2net.cz napsal(a): >> >>> No dobra muzeme bitmapu. Ono obecne duplicity nevadi, to odstrani >>> mergovani a simplifikace, ale chybejici data by mohl byt problem. Jen mi >>> prijde skoda tahat takovou spoustu dat (bitmapy nejsou zrovna >>> nejuspornejsi). >>> >> PNG ma mene nez rozbalene XML, ktere leze z WFS, tudiz nemohu souhlasit... >> >>> Opravdu jsou ty data tak strasne nepouzitelny? Nezna nekdo >>> >>> >> Ano jsou. Zrovna jsem se dival na cast Krcskeho lesa, kterou importoval >> Pavel a krome toho, ze lezi v Polabi ma prazvlastni tvar. Se starym WFS >> byl ten problem, ze daval data pouze v JTSK a musely se prevadet do >> wgs84, coz pridavalo dalsi stupen mozne chyby, protoze Krovak nebyl v >> libproj zrovna spolehlive implementovan - lisil se verzi od verze. >> >>> nekoho v UHULu, aby se zeptal jak se dostat na ten WFS? Vektor je >>> vektor... Bitmapa nam pridava krok 0, zbytek je stejny. >>> >>> >> Rekl bych ze naopak. Parsovani a tahani nekomprimovaneho XML, prevod do >> jineho typu souradnic, mergovani je prace navic. Podle meho nazoru ta >> bitmapa spoustu veci resi elegantnim zpusobem (mergovani, prevod >> souradnic a prvotni simplifikaci). Navic pro praci se bitmapa snadno >> vizualizuje, na XML je potreba osmarender, ktery je dost pomaly. >> >>> T >>> >>> >>> >>>> Ahoj, >>>> >>>> kolda at web2net.cz napsal(a): >>>> >>>> >>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >>>>> chybu >>>>> v Douglas-Pluckeru. >>>>> >>>>> >>>>> >>>> diky za podporu :) >>>> >>>> >>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>> rozpoznat >>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>>> vektor >>>>> jiz na UHUL neni. >>>>> >>>>> >>>>> >>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky >>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>> stahnout. >>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>>> >>>> >>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>>> >>>>> >>>>> >>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na >>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>>> misto >>>> toho to udelal z usecek (hranate)? >>>> >>>> >>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>>> udelal >>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>>> prohnal >>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >>>>> rucni >>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >>>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>>> asi >>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>>> vzniklo... >>>>> >>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>> >>>>> >>>>> >>>> bitmapa >>>> >>>> >>>>> T >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze >>>>>> se >>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>>> budou >>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>> zvlastne >>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>> >>>>>> K >>>>>> >>>>>> Pavel Machek napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Pavel Machek napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Ahoj! >>>>>>>>> >>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech >>>>>>>>> je >>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha >>>>>>>>> se >>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. >>>>>>>> Ta >>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>> >>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>> >>>>>>> Pavel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

14.7.2008 07:53:51 (#15)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Ahoj, Kubajz napsal(a): zobrazit citaci
> ja jsem se do toho pustil, tak mi pockej do konce tydne a predam kdyztak > vse, co jsem do te doby vytvoril. V sobotu odjizdim na dovolenou, takze > pak 14 dni na tom nebudu moci delat ani nahodou. >
Super! Jasne pockam urcite, prace je dost i jinde. Akorat to nejak pak posli do konference at se na tom da pokracovat. zobrazit citaci
>> Muj pripadny postup: >> 1. Stahnout tiles >> > stahuji z WMS po kroku 0.1 stupne v rozliseni 2000x2000 bodu. To dava > prijatelnou presnost a neni to prehnane. >
Pokud dobre pocitam tak to rozliseni vychazi priblizne na tech 5m na pixel, takze ok. zobrazit citaci
>> 2. Prevest na jednobitovou bitmapu. Mozna by to slo i cele spojit (asi 500MB) >> 3. Prohnat potracem >> > ale ten vraci krivky. Co s tim dal? Ja bych se klonil k variante bez > potrace, pokud neexistuje moznost prehodit ho do rezimu rovnych car. > Pokud bychom totiz vzali pouze body a ignorovali ridici body/tecny, tak > bychom se dopustili velmi hrube chyby. >
Ja mam zkusenosti s potrace. Je bezproblemovej. Pouzivam binding do pythona, takze se s nim pracuje velmi pohodlne. Krivky se daji bud vypnout nebo je proste zpracovat, to neni problem, protoze simplifikace je vyrusi... Jestli existuje neco lepsiho (lakewalker neznam), tak se holt pouzije neco lepsiho... Pohodlnejsi ale bude zprocesovat to cele jako jedinou obrovskou bitmapu, coz potrace zvladne. Diry samorzejmne umi take. zobrazit citaci
>> 4. Vyhodit plochy/diry mensi nez X >>
Toto muze byt potreba, protoze vektorizator muze vytvaret malicke polygony jako artefakty zobrazit citaci
> tech IMO moc neni, ale muze se to udelat. > >> 5. Provest generalizaci (15m chyba) >> 6. Opravit polygony (self-intersection) >> > z principu nemaji >
Jak uz jsem psal. Vadne polygony vznikaji pri generalizaci. Nastava to malokdy, ale nastava. Napr. generalizovat dobre vltavu v praze pro velka meritka je opravdu orisek, jak je videt na nekterych navigacich. zobrazit citaci
>> 7. Rozsekat polygony na mensi (max. Y nodu) >> >> > celkem dobrej napad, na to jsem zatim nepomyslel >
Bud se neco napise nebo se da pouzit CGAL. Ten to nejak ma. Reseni na miru bude mozna lepsi... Zbytek OK. Kdyz budes chtit s necim pomoct, jsem k dispozici. T -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080714/9fee88b3/attachment.html>

16.7.2008 11:20:30 (#16)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby to generovalo malo bodu a bude to. K Kubajz napsal(a): zobrazit citaci
> Ahoj, > > kolda at web2net.cz napsal(a): > >> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu >> v Douglas-Pluckeru. >> >> > diky za podporu :) > >> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat >> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor >> jiz na UHUL neni. >> >> > ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi > spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich > vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky > problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. > Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. > >> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >> >> > na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na > obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto > toho to udelal z usecek (hranate)? > >> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal >> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal >> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni >> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi >> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >> vzniklo... >> >> Jaky je tedy navrh? XML nebo bitmapa? >> >> > bitmapa > >> T >> >> >> >> >>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se >>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou >>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne >>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >>> takhle les zobrazil ve dvou dlazdicich. >>> >>> K >>> >>> Pavel Machek napsal(a): >>> >>> >>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>> >>>> >>>> >>>>> Pavel Machek napsal(a): >>>>> >>>>> >>>>> >>>>>> Ahoj! >>>>>> >>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je >>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se >>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta >>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>> >>>>> >>>>> >>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>> >>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>> >>>> Pavel >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

16.7.2008 01:35:56 (#17)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
Ahoj, to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o pocet bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy algoritmus. Jestli chces muzu poskytnout python binding na potrace vcetne douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym kodem se pak prozene cela CR a bude hotovo. Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim totiz odpada problem se spojovanim podel tilu apod.... T zobrazit citaci
> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz > tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to > generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby > to generovalo malo bodu a bude to. > > K > > Kubajz napsal(a): >> Ahoj, >> >> kolda at web2net.cz napsal(a): >> >>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >>> chybu >>> v Douglas-Pluckeru. >>> >>> >> diky za podporu :) >> >>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat >>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor >>> jiz na UHUL neni. >>> >>> >> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky >> problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. >> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >> >>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>> >>> >> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na >> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto >> toho to udelal z usecek (hranate)? >> >>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>> udelal >>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>> prohnal >>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >>> rucni >>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi >>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>> vzniklo... >>> >>> Jaky je tedy navrh? XML nebo bitmapa? >>> >>> >> bitmapa >> >>> T >>> >>> >>> >>> >>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze >>>> se >>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>> budou >>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>> zvlastne >>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >>>> takhle les zobrazil ve dvou dlazdicich. >>>> >>>> K >>>> >>>> Pavel Machek napsal(a): >>>> >>>> >>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>> >>>>> >>>>> >>>>>> Pavel Machek napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> Ahoj! >>>>>>> >>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech >>>>>>> je >>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha >>>>>>> se >>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. >>>>>> Ta >>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>> >>>>>> >>>>>> >>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>> >>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>> >>>>> Pavel >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

16.7.2008 02:01:02 (#18)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom zapoti... Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :) K kolda at web2net.cz napsal(a): zobrazit citaci
> Ahoj, > > to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o pocet > bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. > Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy algoritmus. > Jestli chces muzu poskytnout python binding na potrace vcetne > douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu > (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym > kodem se pak prozene cela CR a bude hotovo. > > Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim > totiz odpada problem se spojovanim podel tilu apod.... > > T > > > >> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz >> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to >> generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby >> to generovalo malo bodu a bude to. >> >> K >> >> Kubajz napsal(a): >> >>> Ahoj, >>> >>> kolda at web2net.cz napsal(a): >>> >>> >>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >>>> chybu >>>> v Douglas-Pluckeru. >>>> >>>> >>>> >>> diky za podporu :) >>> >>> >>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat >>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor >>>> jiz na UHUL neni. >>>> >>>> >>>> >>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky >>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. >>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>> >>> >>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>> >>>> >>>> >>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na >>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto >>> toho to udelal z usecek (hranate)? >>> >>> >>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>> udelal >>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>> prohnal >>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >>>> rucni >>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi >>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>> vzniklo... >>>> >>>> Jaky je tedy navrh? XML nebo bitmapa? >>>> >>>> >>>> >>> bitmapa >>> >>> >>>> T >>>> >>>> >>>> >>>> >>>> >>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze >>>>> se >>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>> budou >>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>> zvlastne >>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze >>>>> takhle les zobrazil ve dvou dlazdicich. >>>>> >>>>> K >>>>> >>>>> Pavel Machek napsal(a): >>>>> >>>>> >>>>> >>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Pavel Machek napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Ahoj! >>>>>>>> >>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech >>>>>>>> je >>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha >>>>>>>> se >>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. >>>>>>> Ta >>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>> >>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>> >>>>>> Pavel >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

16.7.2008 02:31:40 (#19)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
zobrazit citaci
> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. > Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty > dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude > strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom > zapoti... >
Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si klidne bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... zobrazit citaci
> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali > body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal > podel tech dlazdic (duvody uz jsem psal minule - treba takove > krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na > kousek ulice v Beroune).
Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... zobrazit citaci
> > Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni > aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak > zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim > formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :)
No jak myslis. Ja preferuji na tyto prace python, protoze ho precte skoro kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis samozrejmne dal praci studovanim SVG...) Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel alespon o cem mluvim? Dik T zobrazit citaci
> > K > > kolda at web2net.cz napsal(a): >> Ahoj, >> >> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o >> pocet >> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. >> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >> algoritmus. >> Jestli chces muzu poskytnout python binding na potrace vcetne >> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym >> kodem se pak prozene cela CR a bude hotovo. >> >> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim >> totiz odpada problem se spojovanim podel tilu apod.... >> >> T >> >> >> >>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted >>> uz >>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to >>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby >>> to generovalo malo bodu a bude to. >>> >>> K >>> >>> Kubajz napsal(a): >>> >>>> Ahoj, >>>> >>>> kolda at web2net.cz napsal(a): >>>> >>>> >>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >>>>> chybu >>>>> v Douglas-Pluckeru. >>>>> >>>>> >>>>> >>>> diky za podporu :) >>>> >>>> >>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>> rozpoznat >>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>>> vektor >>>>> jiz na UHUL neni. >>>>> >>>>> >>>>> >>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>> nejaky >>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>> stahnout. >>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>>> >>>> >>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>>> >>>>> >>>>> >>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede >>>> na >>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>>> misto >>>> toho to udelal z usecek (hranate)? >>>> >>>> >>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>>> udelal >>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>>> prohnal >>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >>>>> rucni >>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >>>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>>> asi >>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>>> vzniklo... >>>>> >>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>> >>>>> >>>>> >>>> bitmapa >>>> >>>> >>>>> T >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze >>>>>> se >>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>>> budou >>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>> zvlastne >>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, >>>>>> ze >>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>> >>>>>> K >>>>>> >>>>>> Pavel Machek napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Pavel Machek napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Ahoj! >>>>>>>>> >>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>> oblastech >>>>>>>>> je >>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha >>>>>>>>> se >>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. >>>>>>>> Ta >>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>> >>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>> >>>>>>> Pavel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

16.7.2008 02:40:28 (#20)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Tak je to zalozeny - zainteresovani, necht si zaznamenaji: http://www.nyx.cz/index.php?l=topic;id=14933

16.7.2008 02:48:28 (#21)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ahoj, kolda at web2net.cz napsal(a): zobrazit citaci
>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty >> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >> zapoti... >> >> > > Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim > jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny > tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace > (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >
to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec e-mailu. zobrazit citaci
> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. > Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si klidne > bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >
tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase rozdelovat, ale byly rozdeleny nejak predem. zobrazit citaci
> >> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >> podel tech dlazdic (duvody uz jsem psal minule - treba takove >> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >> kousek ulice v Beroune). >> > > Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak > to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze > je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak > budou vznika usekle vycnelky z tilu... >
zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. zobrazit citaci
> >> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak >> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim >> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :) >> > > No jak myslis. Ja preferuji na tyto prace python, protoze ho precte skoro > kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je > pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi > mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas > moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis > samozrejmne dal praci studovanim SVG...) >
ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak se s tim dela, tak to mam jinde hotove... zobrazit citaci
> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel > alespon o cem mluvim? >
stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a sirku a vysku obrazku si nechej 2000 http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 zobrazit citaci
> Dik T > >
neni zac K zobrazit citaci
>> K >> >> kolda at web2net.cz napsal(a): >> >>> Ahoj, >>> >>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o >>> pocet >>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. >>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>> algoritmus. >>> Jestli chces muzu poskytnout python binding na potrace vcetne >>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym >>> kodem se pak prozene cela CR a bude hotovo. >>> >>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim >>> totiz odpada problem se spojovanim podel tilu apod.... >>> >>> T >>> >>> >>> >>> >>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted >>>> uz >>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to >>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby >>>> to generovalo malo bodu a bude to. >>>> >>>> K >>>> >>>> Kubajz napsal(a): >>>> >>>> >>>>> Ahoj, >>>>> >>>>> kolda at web2net.cz napsal(a): >>>>> >>>>> >>>>> >>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m >>>>>> chybu >>>>>> v Douglas-Pluckeru. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> diky za podporu :) >>>>> >>>>> >>>>> >>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>> rozpoznat >>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>>>> vektor >>>>>> jiz na UHUL neni. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>> nejaky >>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>> stahnout. >>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>>>> >>>>> >>>>> >>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>>>> >>>>>> >>>>>> >>>>>> >>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede >>>>> na >>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>>>> misto >>>>> toho to udelal z usecek (hranate)? >>>>> >>>>> >>>>> >>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>>>> udelal >>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>>>> prohnal >>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako >>>>>> rucni >>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem >>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v >>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>>>> asi >>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>>>> vzniklo... >>>>>> >>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> bitmapa >>>>> >>>>> >>>>> >>>>>> T >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem >>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze >>>>>>> se >>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>>>> budou >>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>> zvlastne >>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, >>>>>>> ze >>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>> >>>>>>> K >>>>>>> >>>>>>> Pavel Machek napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Pavel Machek napsal(a): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Ahoj! >>>>>>>>>> >>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>> oblastech >>>>>>>>>> je >>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha >>>>>>>>>> se >>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. >>>>>>>>> Ta >>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze to >>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>> >>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>> >>>>>>>> Pavel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

16.7.2008 03:08:51 (#22)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne neni o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna neni zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se zbytecne rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma jen 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 bodu. V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. T zobrazit citaci
> Ahoj, > > kolda at web2net.cz napsal(a): >>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >>> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty >>> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >>> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >>> zapoti... >>> >>> >> >> Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim >> jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny >> tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace >> (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >> > to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne > zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes > chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec > e-mailu. >> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. >> Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si >> klidne >> bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >> > tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne > nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni > velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal > nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout > malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion > bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. > Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase > rozdelovat, ale byly rozdeleny nejak predem. >> >>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>> kousek ulice v Beroune). >>> >> >> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >> tak >> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >> ze >> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >> budou vznika usekle vycnelky z tilu... >> > zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o > uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. >> >>> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >>> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak >>> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim >>> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji >>> :) >>> >> >> No jak myslis. Ja preferuji na tyto prace python, protoze ho precte >> skoro >> kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je >> pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi >> mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas >> moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis >> samozrejmne dal praci studovanim SVG...) >> > ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak > se s tim dela, tak to mam jinde hotove... >> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel >> alespon o cem mluvim? >> > stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a > sirku a vysku obrazku si nechej 2000 > > http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 > >> Dik T >> >> > neni zac K >>> K >>> >>> kolda at web2net.cz napsal(a): >>> >>>> Ahoj, >>>> >>>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o >>>> pocet >>>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. >>>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>>> algoritmus. >>>> Jestli chces muzu poskytnout python binding na potrace vcetne >>>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. >>>> Vyslednym >>>> kodem se pak prozene cela CR a bude hotovo. >>>> >>>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim >>>> totiz odpada problem se spojovanim podel tilu apod.... >>>> >>>> T >>>> >>>> >>>> >>>> >>>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted >>>>> uz >>>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to >>>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, >>>>> aby >>>>> to generovalo malo bodu a bude to. >>>>> >>>>> K >>>>> >>>>> Kubajz napsal(a): >>>>> >>>>> >>>>>> Ahoj, >>>>>> >>>>>> kolda at web2net.cz napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. >>>>>>> 15m >>>>>>> chybu >>>>>>> v Douglas-Pluckeru. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> diky za podporu :) >>>>>> >>>>>> >>>>>> >>>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>>> rozpoznat >>>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>>>>> vektor >>>>>>> jiz na UHUL neni. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>>> nejaky >>>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>>> stahnout. >>>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>>>>> >>>>>> >>>>>> >>>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede >>>>>> na >>>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>>>>> misto >>>>>> toho to udelal z usecek (hranate)? >>>>>> >>>>>> >>>>>> >>>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>>>>> udelal >>>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>>>>> prohnal >>>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik >>>>>>> jako >>>>>>> rucni >>>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit >>>>>>> kolem >>>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane >>>>>>> v >>>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>>>>> asi >>>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>>>>> vzniklo... >>>>>>> >>>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> bitmapa >>>>>> >>>>>> >>>>>> >>>>>>> T >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve >>>>>>>> zjednodusenem >>>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, >>>>>>>> ze >>>>>>>> se >>>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>>>>> budou >>>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>>> zvlastne >>>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, >>>>>>>> ze >>>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>>> >>>>>>>> K >>>>>>>> >>>>>>>> Pavel Machek napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Ahoj! >>>>>>>>>>> >>>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>>> oblastech >>>>>>>>>>> je >>>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a >>>>>>>>>>> Praha >>>>>>>>>>> se >>>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na >>>>>>>>>> konferenci. >>>>>>>>>> Ta >>>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze >>>>>>>>> to >>>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>>> >>>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>>> >>>>>>>>> Pavel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

16.7.2008 03:28:36 (#23)
gravatar

Kubajz

<kubajz at kbx.cz>
614
kolda at web2net.cz napsal(a): zobrazit citaci
> Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne neni > o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna neni > zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se zbytecne > rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma jen > 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 bodu. >
50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu bude ale problem s dirama. Pokud ma polygon diru, musi se rozseknout sikovne. Coz uz je aspon pro me trochu vyssi divci... zobrazit citaci
> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po > ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a > kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky > preprocesing vubec. >
jo to je mozny. To nevim... zobrazit citaci
> T > > >> Ahoj, >> >> kolda at web2net.cz napsal(a): >> >>>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >>>> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty >>>> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >>>> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >>>> zapoti... >>>> >>>> >>>> >>> Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim >>> jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny >>> tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace >>> (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >>> >>> >> to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne >> zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes >> chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec >> e-mailu. >> >>> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. >>> Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si >>> klidne >>> bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >>> >>> >> tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne >> nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni >> velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal >> nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout >> malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion >> bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. >> Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase >> rozdelovat, ale byly rozdeleny nejak predem. >> >>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>> kousek ulice v Beroune). >>>> >>>> >>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>> tak >>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>> ze >>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>> budou vznika usekle vycnelky z tilu... >>> >>> >> zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o >> uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. >> >>>> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >>>> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak >>>> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim >>>> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji >>>> :) >>>> >>>> >>> No jak myslis. Ja preferuji na tyto prace python, protoze ho precte >>> skoro >>> kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je >>> pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi >>> mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas >>> moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis >>> samozrejmne dal praci studovanim SVG...) >>> >>> >> ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak >> se s tim dela, tak to mam jinde hotove... >> >>> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel >>> alespon o cem mluvim? >>> >>> >> stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a >> sirku a vysku obrazku si nechej 2000 >> >> http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 >> >> >>> Dik T >>> >>> >>> >> neni zac K >> >>>> K >>>> >>>> kolda at web2net.cz napsal(a): >>>> >>>> >>>>> Ahoj, >>>>> >>>>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o >>>>> pocet >>>>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. >>>>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>>>> algoritmus. >>>>> Jestli chces muzu poskytnout python binding na potrace vcetne >>>>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>>>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. >>>>> Vyslednym >>>>> kodem se pak prozene cela CR a bude hotovo. >>>>> >>>>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim >>>>> totiz odpada problem se spojovanim podel tilu apod.... >>>>> >>>>> T >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted >>>>>> uz >>>>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to >>>>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, >>>>>> aby >>>>>> to generovalo malo bodu a bude to. >>>>>> >>>>>> K >>>>>> >>>>>> Kubajz napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> Ahoj, >>>>>>> >>>>>>> kolda at web2net.cz napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. >>>>>>>> 15m >>>>>>>> chybu >>>>>>>> v Douglas-Pluckeru. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> diky za podporu :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>>>> rozpoznat >>>>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>>>>>> vektor >>>>>>>> jiz na UHUL neni. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>>>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>>>> nejaky >>>>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>>>> stahnout. >>>>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede >>>>>>> na >>>>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>>>>>> misto >>>>>>> toho to udelal z usecek (hranate)? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>>>>>> udelal >>>>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>>>>>> prohnal >>>>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik >>>>>>>> jako >>>>>>>> rucni >>>>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit >>>>>>>> kolem >>>>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane >>>>>>>> v >>>>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>>>>>> asi >>>>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>>>>>> vzniklo... >>>>>>>> >>>>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> bitmapa >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> T >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve >>>>>>>>> zjednodusenem >>>>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, >>>>>>>>> ze >>>>>>>>> se >>>>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>>>>>> budou >>>>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>>>> zvlastne >>>>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, >>>>>>>>> ze >>>>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>>>> >>>>>>>>> K >>>>>>>>> >>>>>>>>> Pavel Machek napsal(a): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Ahoj! >>>>>>>>>>>> >>>>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>>>> oblastech >>>>>>>>>>>> je >>>>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a >>>>>>>>>>>> Praha >>>>>>>>>>>> se >>>>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na >>>>>>>>>>> konferenci. >>>>>>>>>>> Ta >>>>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze >>>>>>>>>> to >>>>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>>>> >>>>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>>>> >>>>>>>>>> Pavel >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

17.7.2008 08:00:17 (#24)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Tak jsem vcera ze srandy zkusil, potracnout celou cr. Akorat jsem blbe pocital, takze cela CR ma 1GB. Potrace si dela vnitrne kopii, takze nez neco zacne pocitat uz je na dvou. Nakonec velmi neusporne uklada vysledne vektory (dostane se tak na 4-5GB RAM). Doma mam bohuzel jen 32 bit stroj, takze koncim tak na max. 1/4 republiky. Zkusim to dneska pustit na 64bit, mozna to nejak procesne. Jako nejvetsi problem asi vidim ty cesticky v lesich. To bude nejvetsi problem pro generalizaci. Polygony se budou muset pospojovat a cesticky nejak odstranit. Je jich docela dost a vektor vypada blbe. T Kubajz napsal(a): zobrazit citaci
> kolda at web2net.cz napsal(a): > >> Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne neni >> o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna neni >> zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se zbytecne >> rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma jen >> 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 bodu. >> >> > 50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu bude > ale problem s dirama. Pokud ma polygon diru, musi se rozseknout sikovne. > Coz uz je aspon pro me trochu vyssi divci... > >> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >> preprocesing vubec. >> >> > jo to je mozny. To nevim... > >> T >> >> >> >>> Ahoj, >>> >>> kolda at web2net.cz napsal(a): >>> >>> >>>>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >>>>> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty >>>>> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >>>>> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >>>>> zapoti... >>>>> >>>>> >>>>> >>>>> >>>> Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim >>>> jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny >>>> tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace >>>> (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >>>> >>>> >>>> >>> to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne >>> zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes >>> chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec >>> e-mailu. >>> >>> >>>> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. >>>> Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si >>>> klidne >>>> bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >>>> >>>> >>>> >>> tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne >>> nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni >>> velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal >>> nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout >>> malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion >>> bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. >>> Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase >>> rozdelovat, ale byly rozdeleny nejak predem. >>> >>> >>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>>> kousek ulice v Beroune). >>>>> >>>>> >>>>> >>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>>> tak >>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>>> ze >>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>>> budou vznika usekle vycnelky z tilu... >>>> >>>> >>>> >>> zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o >>> uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. >>> >>> >>>>> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >>>>> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak >>>>> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim >>>>> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji >>>>> :) >>>>> >>>>> >>>>> >>>> No jak myslis. Ja preferuji na tyto prace python, protoze ho precte >>>> skoro >>>> kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je >>>> pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi >>>> mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas >>>> moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis >>>> samozrejmne dal praci studovanim SVG...) >>>> >>>> >>>> >>> ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak >>> se s tim dela, tak to mam jinde hotove... >>> >>> >>>> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel >>>> alespon o cem mluvim? >>>> >>>> >>>> >>> stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a >>> sirku a vysku obrazku si nechej 2000 >>> >>> http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 >>> >>> >>> >>>> Dik T >>>> >>>> >>>> >>>> >>> neni zac K >>> >>> >>>>> K >>>>> >>>>> kolda at web2net.cz napsal(a): >>>>> >>>>> >>>>> >>>>>> Ahoj, >>>>>> >>>>>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o >>>>>> pocet >>>>>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. >>>>>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>>>>> algoritmus. >>>>>> Jestli chces muzu poskytnout python binding na potrace vcetne >>>>>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>>>>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. >>>>>> Vyslednym >>>>>> kodem se pak prozene cela CR a bude hotovo. >>>>>> >>>>>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim >>>>>> totiz odpada problem se spojovanim podel tilu apod.... >>>>>> >>>>>> T >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted >>>>>>> uz >>>>>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to >>>>>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, >>>>>>> aby >>>>>>> to generovalo malo bodu a bude to. >>>>>>> >>>>>>> K >>>>>>> >>>>>>> Kubajz napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Ahoj, >>>>>>>> >>>>>>>> kolda at web2net.cz napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. >>>>>>>>> 15m >>>>>>>>> chybu >>>>>>>>> v Douglas-Pluckeru. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> diky za podporu :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>>>>> rozpoznat >>>>>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>>>>>>> vektor >>>>>>>>> jiz na UHUL neni. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>>>>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>>>>> nejaky >>>>>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>>>>> stahnout. >>>>>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede >>>>>>>> na >>>>>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>>>>>>> misto >>>>>>>> toho to udelal z usecek (hranate)? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>>>>>>> udelal >>>>>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>>>>>>> prohnal >>>>>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik >>>>>>>>> jako >>>>>>>>> rucni >>>>>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit >>>>>>>>> kolem >>>>>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>>>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane >>>>>>>>> v >>>>>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>>>>>>> asi >>>>>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>>>>>>> vzniklo... >>>>>>>>> >>>>>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> bitmapa >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> T >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve >>>>>>>>>> zjednodusenem >>>>>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, >>>>>>>>>> ze >>>>>>>>>> se >>>>>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>>>>>>> budou >>>>>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>>>>> zvlastne >>>>>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, >>>>>>>>>> ze >>>>>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>>>>> >>>>>>>>>> K >>>>>>>>>> >>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Ahoj! >>>>>>>>>>>>> >>>>>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>>>>> oblastech >>>>>>>>>>>>> je >>>>>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a >>>>>>>>>>>>> Praha >>>>>>>>>>>>> se >>>>>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na >>>>>>>>>>>> konferenci. >>>>>>>>>>>> Ta >>>>>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze >>>>>>>>>>> to >>>>>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>>>>> >>>>>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>>>>> >>>>>>>>>>> Pavel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080717/35e7c2de/attachment.html>

17.7.2008 08:39:27 (#25)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ahoj, Tomas Kolda napsal(a): zobrazit citaci
> Tak jsem vcera ze srandy zkusil, potracnout celou cr. Akorat jsem blbe > pocital, takze cela CR ma 1GB. Potrace si dela vnitrne kopii, takze > nez neco zacne pocitat uz je na dvou. Nakonec velmi neusporne uklada > vysledne vektory (dostane se tak na 4-5GB RAM). Doma mam bohuzel jen > 32 bit stroj, takze koncim tak na max. 1/4 republiky. Zkusim to dneska > pustit na 64bit,
ja jsem si to myslel, ale nechtel jsem to rozmlouvat... zobrazit citaci
> mozna to nejak procesne. Jako nejvetsi problem asi vidim ty cesticky v > lesich. To bude nejvetsi problem pro generalizaci.
Co zkusit sloucit body, ktere jsou od sebe vzdaleny mene nez xxx? Nepomohlo by to? Popripade by se i rucne nechala upravit ta bitmapa - stetcem v gimpu to bude mozna rychlejsi :) zobrazit citaci
> Polygony se budou muset pospojovat a cesticky nejak odstranit. Je jich > docela dost a vektor vypada blbe.
zobrazit citaci
> > T > > Kubajz napsal(a): >> kolda at web2net.cz napsal(a): >> >>> Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne neni >>> o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna neni >>> zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se zbytecne >>> rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma jen >>> 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 bodu. >>> >>> >> 50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu bude >> ale problem s dirama. Pokud ma polygon diru, musi se rozseknout sikovne. >> Coz uz je aspon pro me trochu vyssi divci... >> >>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>> preprocesing vubec. >>> >>> >> jo to je mozny. To nevim... >> >>> T >>> >>> >>> >>>> Ahoj, >>>> >>>> kolda at web2net.cz napsal(a): >>>> >>>> >>>>>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >>>>>> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty >>>>>> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >>>>>> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >>>>>> zapoti... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim >>>>> jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny >>>>> tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace >>>>> (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >>>>> >>>>> >>>>> >>>> to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne >>>> zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes >>>> chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec >>>> e-mailu. >>>> >>>> >>>>> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. >>>>> Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si >>>>> klidne >>>>> bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >>>>> >>>>> >>>>> >>>> tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne >>>> nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni >>>> velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal >>>> nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout >>>> malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion >>>> bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. >>>> Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase >>>> rozdelovat, ale byly rozdeleny nejak predem. >>>> >>>> >>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>>>> kousek ulice v Beroune). >>>>>> >>>>>> >>>>>> >>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>>>> tak >>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>>>> ze >>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>>>> budou vznika usekle vycnelky z tilu... >>>>> >>>>> >>>>> >>>> zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o >>>> uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. >>>> >>>> >>>>>> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >>>>>> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak >>>>>> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim >>>>>> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji >>>>>> :) >>>>>> >>>>>> >>>>>> >>>>> No jak myslis. Ja preferuji na tyto prace python, protoze ho precte >>>>> skoro >>>>> kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je >>>>> pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi >>>>> mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas >>>>> moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis >>>>> samozrejmne dal praci studovanim SVG...) >>>>> >>>>> >>>>> >>>> ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak >>>> se s tim dela, tak to mam jinde hotove... >>>> >>>> >>>>> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel >>>>> alespon o cem mluvim? >>>>> >>>>> >>>>> >>>> stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a >>>> sirku a vysku obrazku si nechej 2000 >>>> >>>> http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 >>>> >>>> >>>> >>>>> Dik T >>>>> >>>>> >>>>> >>>>> >>>> neni zac K >>>> >>>> >>>>>> K >>>>>> >>>>>> kolda at web2net.cz napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> Ahoj, >>>>>>> >>>>>>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o >>>>>>> pocet >>>>>>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. >>>>>>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>>>>>> algoritmus. >>>>>>> Jestli chces muzu poskytnout python binding na potrace vcetne >>>>>>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>>>>>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. >>>>>>> Vyslednym >>>>>>> kodem se pak prozene cela CR a bude hotovo. >>>>>>> >>>>>>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim >>>>>>> totiz odpada problem se spojovanim podel tilu apod.... >>>>>>> >>>>>>> T >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted >>>>>>>> uz >>>>>>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to >>>>>>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, >>>>>>>> aby >>>>>>>> to generovalo malo bodu a bude to. >>>>>>>> >>>>>>>> K >>>>>>>> >>>>>>>> Kubajz napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Ahoj, >>>>>>>>> >>>>>>>>> kolda at web2net.cz napsal(a): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. >>>>>>>>>> 15m >>>>>>>>>> chybu >>>>>>>>>> v Douglas-Pluckeru. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> diky za podporu :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>>>>>> rozpoznat >>>>>>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten >>>>>>>>>> vektor >>>>>>>>>> jiz na UHUL neni. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>>>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich >>>>>>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>>>>>> nejaky >>>>>>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>>>>>> stahnout. >>>>>>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede >>>>>>>>> na >>>>>>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a >>>>>>>>> misto >>>>>>>>> toho to udelal z usecek (hranate)? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu >>>>>>>>>> udelal >>>>>>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se >>>>>>>>>> prohnal >>>>>>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik >>>>>>>>>> jako >>>>>>>>>> rucni >>>>>>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit >>>>>>>>>> kolem >>>>>>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a >>>>>>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane >>>>>>>>>> v >>>>>>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel >>>>>>>>>> asi >>>>>>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho >>>>>>>>>> vzniklo... >>>>>>>>>> >>>>>>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> bitmapa >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> T >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve >>>>>>>>>>> zjednodusenem >>>>>>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim >>>>>>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, >>>>>>>>>>> ze >>>>>>>>>>> se >>>>>>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy tam >>>>>>>>>>> budou >>>>>>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>>>>>> zvlastne >>>>>>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, >>>>>>>>>>> ze >>>>>>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>>>>>> >>>>>>>>>>> K >>>>>>>>>>> >>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Ahoj! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>>>>>> oblastech >>>>>>>>>>>>>> je >>>>>>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a >>>>>>>>>>>>>> Praha >>>>>>>>>>>>>> se >>>>>>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na >>>>>>>>>>>>> konferenci. >>>>>>>>>>>>> Ta >>>>>>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim ze >>>>>>>>>>>> to >>>>>>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>>>>>> >>>>>>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v >>>>>>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>>>>>> >>>>>>>>>>>> Pavel >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

17.7.2008 09:26:33 (#26)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
Koukal jsem do zdrojaku potrace a kdyz mi neprojde ten 64bit tak to trosku hacknu a vysledky se budou ukladat do mezisouboru. Az konecne budu mit vektorovy dump tak to poslu a muze si pripadne kdokoliv pohrat s generalizaci. Jeste se tedy nevzdavam :) S tou generalizaci jsem neco podobneho resil s tema adresama na built-up area tak to s tim zkusim prohnat, ale zatim nevim lec nemam vsechny vektory. Postup byl tusim takovy, ze nasel vsechny vzdalenosti bodu v polygonu a kratsi nez neco se spojily. Tim se zaceluji uzke ulicky a vznikaji diry. Dira se, ale postupne zmensovala a decimovala az zmizela... Pokud byla vetsi nez limit tak zustala. No chtel bych to udelat poradne, protoze presne to same potrebuji pro generalizaci velkych zoomu do navigace. Takze tim ztratim ted cas, ale pak treba bude super rychla mapka i pro velke zoomy. T zobrazit citaci
> Ahoj, > > Tomas Kolda napsal(a): >> Tak jsem vcera ze srandy zkusil, potracnout celou cr. Akorat jsem blbe >> pocital, takze cela CR ma 1GB. Potrace si dela vnitrne kopii, takze >> nez neco zacne pocitat uz je na dvou. Nakonec velmi neusporne uklada >> vysledne vektory (dostane se tak na 4-5GB RAM). Doma mam bohuzel jen >> 32 bit stroj, takze koncim tak na max. 1/4 republiky. Zkusim to dneska >> pustit na 64bit, > ja jsem si to myslel, ale nechtel jsem to rozmlouvat... >> mozna to nejak procesne. Jako nejvetsi problem asi vidim ty cesticky v >> lesich. To bude nejvetsi problem pro generalizaci. > Co zkusit sloucit body, ktere jsou od sebe vzdaleny mene nez xxx? > Nepomohlo by to? Popripade by se i rucne nechala upravit ta bitmapa - > stetcem v gimpu to bude mozna rychlejsi :) >> Polygony se budou muset pospojovat a cesticky nejak odstranit. Je jich >> docela dost a vektor vypada blbe. > >> >> T >> >> Kubajz napsal(a): >>> kolda at web2net.cz napsal(a): >>> >>>> Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne >>>> neni >>>> o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna >>>> neni >>>> zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se >>>> zbytecne >>>> rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma >>>> jen >>>> 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 >>>> bodu. >>>> >>>> >>> 50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu >>> bude >>> ale problem s dirama. Pokud ma polygon diru, musi se rozseknout >>> sikovne. >>> Coz uz je aspon pro me trochu vyssi divci... >>> >>>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>>> preprocesing vubec. >>>> >>>> >>> jo to je mozny. To nevim... >>> >>>> T >>>> >>>> >>>> >>>>> Ahoj, >>>>> >>>>> kolda at web2net.cz napsal(a): >>>>> >>>>> >>>>>>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >>>>>>> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a >>>>>>> lepit ty >>>>>>> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >>>>>>> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >>>>>>> zapoti... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim >>>>>> jednobitovou bitmapu (nemusim ji generovat). Proste se nactou >>>>>> vsechny >>>>>> tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi >>>>>> potrace >>>>>> (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >>>>>> >>>>>> >>>>>> >>>>> to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne >>>>> zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud >>>>> budes >>>>> chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz >>>>> konec >>>>> e-mailu. >>>>> >>>>> >>>>>> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. >>>>>> Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si >>>>>> klidne >>>>>> bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >>>>>> >>>>>> >>>>>> >>>>> tady by vicemene problemy se spojovanim nevznikaly, protoze me >>>>> primarne >>>>> nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby >>>>> maximalni >>>>> velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle >>>>> strihal >>>>> nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout >>>>> malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion >>>>> bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. >>>>> Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase >>>>> rozdelovat, ale byly rozdeleny nejak predem. >>>>> >>>>> >>>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom >>>>>>> slucovali >>>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak >>>>>>> nechal >>>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival >>>>>>> na >>>>>>> kousek ulice v Beroune). >>>>>>> >>>>>>> >>>>>>> >>>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle >>>>>> dlazdic, >>>>>> tak >>>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani >>>>>> nevadi, >>>>>> ze >>>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti >>>>>> naopak >>>>>> budou vznika usekle vycnelky z tilu... >>>>>> >>>>>> >>>>>> >>>>> zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o >>>>> uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. >>>>> >>>>> >>>>>>> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >>>>>>> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka >>>>>>> pak >>>>>>> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil >>>>>>> studovanim >>>>>>> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr >>>>>>> znamenaji >>>>>>> :) >>>>>>> >>>>>>> >>>>>>> >>>>>> No jak myslis. Ja preferuji na tyto prace python, protoze ho precte >>>>>> skoro >>>>>> kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java >>>>>> je >>>>>> pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy >>>>>> dalsi >>>>>> mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz >>>>>> mas >>>>>> moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis >>>>>> samozrejmne dal praci studovanim SVG...) >>>>>> >>>>>> >>>>>> >>>>> ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, >>>>> jak >>>>> se s tim dela, tak to mam jinde hotove... >>>>> >>>>> >>>>>> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a >>>>>> vedel >>>>>> alespon o cem mluvim? >>>>>> >>>>>> >>>>>> >>>>> stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a >>>>> sirku a vysku obrazku si nechej 2000 >>>>> >>>>> http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 >>>>> >>>>> >>>>> >>>>>> Dik T >>>>>> >>>>>> >>>>>> >>>>>> >>>>> neni zac K >>>>> >>>>> >>>>>>> K >>>>>>> >>>>>>> kolda at web2net.cz napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Ahoj, >>>>>>>> >>>>>>>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral >>>>>>>> o >>>>>>>> pocet >>>>>>>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod >>>>>>>> kontrolou. >>>>>>>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>>>>>>> algoritmus. >>>>>>>> Jestli chces muzu poskytnout python binding na potrace vcetne >>>>>>>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>>>>>>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. >>>>>>>> Vyslednym >>>>>>>> kodem se pak prozene cela CR a bude hotovo. >>>>>>>> >>>>>>>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? >>>>>>>> Tim >>>>>>>> totiz odpada problem se spojovanim podel tilu apod.... >>>>>>>> >>>>>>>> T >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. >>>>>>>>> Ted >>>>>>>>> uz >>>>>>>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze >>>>>>>>> to >>>>>>>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim >>>>>>>>> parametru, >>>>>>>>> aby >>>>>>>>> to generovalo malo bodu a bude to. >>>>>>>>> >>>>>>>>> K >>>>>>>>> >>>>>>>>> Kubajz napsal(a): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Ahoj, >>>>>>>>>> >>>>>>>>>> kolda at web2net.cz napsal(a): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na >>>>>>>>>>> napr. >>>>>>>>>>> 15m >>>>>>>>>>> chybu >>>>>>>>>>> v Douglas-Pluckeru. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> diky za podporu :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>>>>>>> rozpoznat >>>>>>>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze >>>>>>>>>>> ten >>>>>>>>>>> vektor >>>>>>>>>>> jiz na UHUL neni. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>>>>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z >>>>>>>>>> nich >>>>>>>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>>>>>>> nejaky >>>>>>>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>>>>>>> stahnout. >>>>>>>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem >>>>>>>>>> rozliseni. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel >>>>>>>>>>> jsem >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to >>>>>>>>>> provede >>>>>>>>>> na >>>>>>>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky >>>>>>>>>> a >>>>>>>>>> misto >>>>>>>>>> toho to udelal z usecek (hranate)? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou >>>>>>>>>>> adresu >>>>>>>>>>> udelal >>>>>>>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek >>>>>>>>>>> se >>>>>>>>>>> prohnal >>>>>>>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik >>>>>>>>>>> jako >>>>>>>>>>> rucni >>>>>>>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit >>>>>>>>>>> kolem >>>>>>>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove >>>>>>>>>>> zmergovat a >>>>>>>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy >>>>>>>>>>> popsane >>>>>>>>>>> v >>>>>>>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. >>>>>>>>>>> Bohuzel >>>>>>>>>>> asi >>>>>>>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco >>>>>>>>>>> pekneho >>>>>>>>>>> vzniklo... >>>>>>>>>>> >>>>>>>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> bitmapa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> T >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve >>>>>>>>>>>> zjednodusenem >>>>>>>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s >>>>>>>>>>>> rozlisenim >>>>>>>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni >>>>>>>>>>>> implementaci, >>>>>>>>>>>> ze >>>>>>>>>>>> se >>>>>>>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy >>>>>>>>>>>> tam >>>>>>>>>>>> budou >>>>>>>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>>>>>>> zvlastne >>>>>>>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se >>>>>>>>>>>> stat, >>>>>>>>>>>> ze >>>>>>>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>>>>>>> >>>>>>>>>>>> K >>>>>>>>>>>> >>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ahoj! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>>>>>>> oblastech >>>>>>>>>>>>>>> je >>>>>>>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a >>>>>>>>>>>>>>> Praha >>>>>>>>>>>>>>> se >>>>>>>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na >>>>>>>>>>>>>> konferenci. >>>>>>>>>>>>>> Ta >>>>>>>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim >>>>>>>>>>>>> ze >>>>>>>>>>>>> to >>>>>>>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>>>>>>> >>>>>>>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy >>>>>>>>>>>>> domky v >>>>>>>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>>>>>>> >>>>>>>>>>>>> Pavel >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

17.7.2008 12:03:59 (#27)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
kolda at web2net.cz napsal(a): zobrazit citaci
> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po > ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a > kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky > preprocesing vubec.
Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. To je zase moje agenda ;-) Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale zeleny ;-) -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

17.7.2008 01:28:48 (#28)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho predesleho pokusu s uhulem. Je to tragedie - duplicitni body, prekryvajici se polygony a tech bodu... K Petr Nejedly napsal(a): zobrazit citaci
> kolda at web2net.cz napsal(a): > > >> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >> preprocesing vubec. >> > > Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi > polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. > > A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. > To je zase moje agenda ;-) > Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty > pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). > A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale > zeleny ;-) > >

17.7.2008 03:17:40 (#29)
gravatar

Vaclav Stepan

<vaclav.stepan at gmail.com>
27
Ahoj, pokud by se to dalo zahrnout do vyzkumnych veci a bylo by potreba vic pameti, sly by pouzit stroje na Metacentru (nejsem si jist, kolik si muzu narokovat pameti, ale neco jako 5 GB by nemel byt velky problem, aspon pokud potrace jde zkompilovat na SGI). Vasek On Thu, Jul 17, 2008 at 9:26 AM, <kolda at web2net.cz> wrote: zobrazit citaci
> Koukal jsem do zdrojaku potrace a kdyz mi neprojde ten 64bit tak to trosku > hacknu a vysledky se budou ukladat do mezisouboru. Az konecne budu mit > vektorovy dump tak to poslu a muze si pripadne kdokoliv pohrat s > generalizaci. Jeste se tedy nevzdavam :) > > S tou generalizaci jsem neco podobneho resil s tema adresama na built-up > area tak to s tim zkusim prohnat, ale zatim nevim lec nemam vsechny > vektory. > > Postup byl tusim takovy, ze nasel vsechny vzdalenosti bodu v polygonu a > kratsi nez neco se spojily. Tim se zaceluji uzke ulicky a vznikaji diry. > Dira se, ale postupne zmensovala a decimovala az zmizela... Pokud byla > vetsi nez limit tak zustala. No chtel bych to udelat poradne, protoze > presne to same potrebuji pro generalizaci velkych zoomu do navigace. Takze > tim ztratim ted cas, ale pak treba bude super rychla mapka i pro velke > zoomy. > > T > >> Ahoj, >> >> Tomas Kolda napsal(a): >>> Tak jsem vcera ze srandy zkusil, potracnout celou cr. Akorat jsem blbe >>> pocital, takze cela CR ma 1GB. Potrace si dela vnitrne kopii, takze >>> nez neco zacne pocitat uz je na dvou. Nakonec velmi neusporne uklada >>> vysledne vektory (dostane se tak na 4-5GB RAM). Doma mam bohuzel jen >>> 32 bit stroj, takze koncim tak na max. 1/4 republiky. Zkusim to dneska >>> pustit na 64bit, >> ja jsem si to myslel, ale nechtel jsem to rozmlouvat... >>> mozna to nejak procesne. Jako nejvetsi problem asi vidim ty cesticky v >>> lesich. To bude nejvetsi problem pro generalizaci. >> Co zkusit sloucit body, ktere jsou od sebe vzdaleny mene nez xxx? >> Nepomohlo by to? Popripade by se i rucne nechala upravit ta bitmapa - >> stetcem v gimpu to bude mozna rychlejsi :) >>> Polygony se budou muset pospojovat a cesticky nejak odstranit. Je jich >>> docela dost a vektor vypada blbe. >> >>> >>> T >>> >>> Kubajz napsal(a): >>>> kolda at web2net.cz napsal(a): >>>> >>>>> Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne >>>>> neni >>>>> o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna >>>>> neni >>>>> zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se >>>>> zbytecne >>>>> rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma >>>>> jen >>>>> 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 >>>>> bodu. >>>>> >>>>> >>>> 50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu >>>> bude >>>> ale problem s dirama. Pokud ma polygon diru, musi se rozseknout >>>> sikovne. >>>> Coz uz je aspon pro me trochu vyssi divci... >>>> >>>>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>>>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>>>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>>>> preprocesing vubec. >>>>> >>>>> >>>> jo to je mozny. To nevim... >>>> >>>>> T >>>>> >>>>> >>>>> >>>>>> Ahoj, >>>>>> >>>>>> kolda at web2net.cz napsal(a): >>>>>> >>>>>> >>>>>>>> Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. >>>>>>>> Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a >>>>>>>> lepit ty >>>>>>>> dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude >>>>>>>> strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom >>>>>>>> zapoti... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim >>>>>>> jednobitovou bitmapu (nemusim ji generovat). Proste se nactou >>>>>>> vsechny >>>>>>> tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi >>>>>>> potrace >>>>>>> (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim >>>>>>> >>>>>>> >>>>>>> >>>>>> to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne >>>>>> zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud >>>>>> budes >>>>>> chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz >>>>>> konec >>>>>> e-mailu. >>>>>> >>>>>> >>>>>>> jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. >>>>>>> Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si >>>>>>> klidne >>>>>>> bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... >>>>>>> >>>>>>> >>>>>>> >>>>>> tady by vicemene problemy se spojovanim nevznikaly, protoze me >>>>>> primarne >>>>>> nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby >>>>>> maximalni >>>>>> velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle >>>>>> strihal >>>>>> nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout >>>>>> malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion >>>>>> bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. >>>>>> Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase >>>>>> rozdelovat, ale byly rozdeleny nejak predem. >>>>>> >>>>>> >>>>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom >>>>>>>> slucovali >>>>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak >>>>>>>> nechal >>>>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival >>>>>>>> na >>>>>>>> kousek ulice v Beroune). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle >>>>>>> dlazdic, >>>>>>> tak >>>>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani >>>>>>> nevadi, >>>>>>> ze >>>>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti >>>>>>> naopak >>>>>>> budou vznika usekle vycnelky z tilu... >>>>>>> >>>>>>> >>>>>>> >>>>>> zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o >>>>>> uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. >>>>>> >>>>>> >>>>>>>> Binding do pythona nepotrebuji - cas behu potrace >>> cas spusteni >>>>>>>> aplikace, takze to prozenu normalne pres prikazovej radek a svgcka >>>>>>>> pak >>>>>>>> zpracuju jednoduchym parserem v jave. Dnesek jsem stravil >>>>>>>> studovanim >>>>>>>> formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr >>>>>>>> znamenaji >>>>>>>> :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> No jak myslis. Ja preferuji na tyto prace python, protoze ho precte >>>>>>> skoro >>>>>>> kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java >>>>>>> je >>>>>>> pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy >>>>>>> dalsi >>>>>>> mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz >>>>>>> mas >>>>>>> moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis >>>>>>> samozrejmne dal praci studovanim SVG...) >>>>>>> >>>>>>> >>>>>>> >>>>>> ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, >>>>>> jak >>>>>> se s tim dela, tak to mam jinde hotove... >>>>>> >>>>>> >>>>>>> Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a >>>>>>> vedel >>>>>>> alespon o cem mluvim? >>>>>>> >>>>>>> >>>>>>> >>>>>> stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a >>>>>> sirku a vysku obrazku si nechej 2000 >>>>>> >>>>>> http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=2000 >>>>>> >>>>>> >>>>>> >>>>>>> Dik T >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> neni zac K >>>>>> >>>>>> >>>>>>>> K >>>>>>>> >>>>>>>> kolda at web2net.cz napsal(a): >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Ahoj, >>>>>>>>> >>>>>>>>> to je super zprava, ze na tom delas. Mozna bych se vubec nestaral >>>>>>>>> o >>>>>>>>> pocet >>>>>>>>> bodu. Ty se odstrani generalizaci, kde je budes mit vic pod >>>>>>>>> kontrolou. >>>>>>>>> Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy >>>>>>>>> algoritmus. >>>>>>>>> Jestli chces muzu poskytnout python binding na potrace vcetne >>>>>>>>> douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu >>>>>>>>> (30x30km) a na te zdrojaky odladit ku oblibe cele konference. >>>>>>>>> Vyslednym >>>>>>>>> kodem se pak prozene cela CR a bude hotovo. >>>>>>>>> >>>>>>>>> Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? >>>>>>>>> Tim >>>>>>>>> totiz odpada problem se spojovanim podel tilu apod.... >>>>>>>>> >>>>>>>>> T >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Tak jsem prisel na to, jak se v potracu vypina generovani krivek. >>>>>>>>>> Ted >>>>>>>>>> uz >>>>>>>>>> tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze >>>>>>>>>> to >>>>>>>>>> generuje moc hezke obrazky. Jeste si pohraju s vyladenim >>>>>>>>>> parametru, >>>>>>>>>> aby >>>>>>>>>> to generovalo malo bodu a bude to. >>>>>>>>>> >>>>>>>>>> K >>>>>>>>>> >>>>>>>>>> Kubajz napsal(a): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Ahoj, >>>>>>>>>>> >>>>>>>>>>> kolda at web2net.cz napsal(a): >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> S tim naprosto souhlasim. Sjednocene typy a zjednodusit na >>>>>>>>>>>> napr. >>>>>>>>>>>> 15m >>>>>>>>>>>> chybu >>>>>>>>>>>> v Douglas-Pluckeru. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> diky za podporu :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi >>>>>>>>>>>> rozpoznat >>>>>>>>>>>> nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze >>>>>>>>>>>> ten >>>>>>>>>>>> vektor >>>>>>>>>>>> jiz na UHUL neni. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi >>>>>>>>>>> spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z >>>>>>>>>>> nich >>>>>>>>>>> vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma >>>>>>>>>>> nejaky >>>>>>>>>>> problem v nastaveni WFS serveru, takze vktorova data jiz nelze >>>>>>>>>>> stahnout. >>>>>>>>>>> Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem >>>>>>>>>>> rozliseni. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Na vektorizaci jsem pouzival potrace na buildup area. Zkousel >>>>>>>>>>>> jsem >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to >>>>>>>>>>> provede >>>>>>>>>>> na >>>>>>>>>>> obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky >>>>>>>>>>> a >>>>>>>>>>> misto >>>>>>>>>>> toho to udelal z usecek (hranate)? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou >>>>>>>>>>>> adresu >>>>>>>>>>>> udelal >>>>>>>>>>>> pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek >>>>>>>>>>>> se >>>>>>>>>>>> prohnal >>>>>>>>>>>> potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik >>>>>>>>>>>> jako >>>>>>>>>>>> rucni >>>>>>>>>>>> vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit >>>>>>>>>>>> kolem >>>>>>>>>>>> adresy sestiuhelnik o nejake plose a polygony vektorove >>>>>>>>>>>> zmergovat a >>>>>>>>>>>> simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy >>>>>>>>>>>> popsane >>>>>>>>>>>> v >>>>>>>>>>>> predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. >>>>>>>>>>>> Bohuzel >>>>>>>>>>>> asi >>>>>>>>>>>> nejde pouzit kvuli licenci. Ale z UIR by take mozna neco >>>>>>>>>>>> pekneho >>>>>>>>>>>> vzniklo... >>>>>>>>>>>> >>>>>>>>>>>> Jaky je tedy navrh? XML nebo bitmapa? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> bitmapa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> T >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Pokud si to dobre pamatuji, tak nazor byl ano, ale ve >>>>>>>>>>>>> zjednodusenem >>>>>>>>>>>>> stavu. Preci neni mozne mit tam lesy v rozliseni 5m s >>>>>>>>>>>>> rozlisenim >>>>>>>>>>>>> poddruhu lesu. Navic jsem zjistil i chybu v puvodni >>>>>>>>>>>>> implementaci, >>>>>>>>>>>>> ze >>>>>>>>>>>>> se >>>>>>>>>>>>> muze stat, ze nektere lesy nebudou importovany a nektere lesy >>>>>>>>>>>>> tam >>>>>>>>>>>>> budou >>>>>>>>>>>>> dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu >>>>>>>>>>>>> zvlastne >>>>>>>>>>>>> s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej >>>>>>>>>>>>> nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se >>>>>>>>>>>>> stat, >>>>>>>>>>>>> ze >>>>>>>>>>>>> takhle les zobrazil ve dvou dlazdicich. >>>>>>>>>>>>> >>>>>>>>>>>>> K >>>>>>>>>>>>> >>>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun 2008-07-13 19:00:26, Kubajz wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Pavel Machek napsal(a): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ahoj! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Importoval jsem okoli klanovic a kus vychodni Prahy... v >>>>>>>>>>>>>>>> oblastech >>>>>>>>>>>>>>>> je >>>>>>>>>>>>>>>> malo lesu a dost jinych dat, takze tech dat nebylo tolik, a >>>>>>>>>>>>>>>> Praha >>>>>>>>>>>>>>>> se >>>>>>>>>>>>>>>> trochu zazelena... Dlazdice jsou vyjmenovany na wiki. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hm - bylo by celkem dobre respektovat nazor vetsiny na >>>>>>>>>>>>>>> konferenci. >>>>>>>>>>>>>>> Ta >>>>>>>>>>>>>>> data pro jistotu smazu, aby to nekoho nelakalo... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Bohuzel "respektovat nazor vetsiny na konferenci" (a nemyslim >>>>>>>>>>>>>> ze >>>>>>>>>>>>>> to >>>>>>>>>>>>>> byla vetsina) v tomto pripade znamena "nemapovat lesy". >>>>>>>>>>>>>> >>>>>>>>>>>>>> A je dost smutny kdyz v praze jsou nakresleny jednotlivy >>>>>>>>>>>>>> domky v >>>>>>>>>>>>>> Dejvicich, a pak v ni jaksi chybi Sarecky les. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Pavel >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

17.7.2008 11:51:50 (#30)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. http://www.web2net.cz/osm/lesy.7z po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri vyrabeni jinych polygonu. Mejte se T Kubajz napsal(a): zobrazit citaci
> Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se > uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho > predesleho pokusu s uhulem. Je to tragedie - duplicitni body, > prekryvajici se polygony a tech bodu... > > K > > Petr Nejedly napsal(a): > >> kolda at web2net.cz napsal(a): >> >> >> >>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>> preprocesing vubec. >>> >>> >> Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi >> polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. >> >> A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. >> To je zase moje agenda ;-) >> Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty >> pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). >> A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale >> zeleny ;-) >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080717/98e7ab1d/attachment.html>

18.7.2008 02:20:12 (#31)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ahoj, aplikoal bych vertex reduction jako soucast DP a DP bych zkusil obohatit o napady z tohoto paperu: http://www.dca.fee.unicamp.br/~ting/Publications/P2001-2005/wu-roci-2003-rfm.pdf coz by znamenalo sehnat jeste jeden, dva algoritmy v pythonu nebo je napsat/konvertovat z jineho jazyka. Slozitost by se vicemene nezvysila a meli bychom jistotu, ze mame neprotinajici se polygony. K Tomas Kolda napsal(a): zobrazit citaci
> Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. > > http://www.web2net.cz/osm/lesy.7z > > po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi > 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez > uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. > Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo > jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci > vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. > > Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri > vyrabeni jinych polygonu. > > Mejte se > > T > > > > Kubajz napsal(a): >> Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se >> uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho >> predesleho pokusu s uhulem. Je to tragedie - duplicitni body, >> prekryvajici se polygony a tech bodu... >> >> K >> >> Petr Nejedly napsal(a): >> >>> kolda at web2net.cz napsal(a): >>> >>> >>> >>>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>>> preprocesing vubec. >>>> >>>> >>> Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi >>> polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. >>> >>> A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. >>> To je zase moje agenda ;-) >>> Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty >>> pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). >>> A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale >>> zeleny ;-) >>> >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

18.7.2008 07:23:47 (#32)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Paradni publikace, diky za tip. Zkusim to naimplementovat a pak poslu vysledek. Jinak geometricke algoritmy se vzdy hodi, tak jestli znas nejake pekne misto, kde jsou po kupe, dej vedet. T Kubajz napsal(a): zobrazit citaci
> Ahoj, > > aplikoal bych vertex reduction jako soucast DP a DP bych zkusil obohatit > o napady z tohoto paperu: > > http://www.dca.fee.unicamp.br/~ting/Publications/P2001-2005/wu-roci-2003-rfm.pdf > > coz by znamenalo sehnat jeste jeden, dva algoritmy v pythonu nebo je > napsat/konvertovat z jineho jazyka. Slozitost by se vicemene nezvysila a > meli bychom jistotu, ze mame neprotinajici se polygony. > > K > > Tomas Kolda napsal(a): > >> Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. >> >> http://www.web2net.cz/osm/lesy.7z >> >> po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi >> 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez >> uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. >> Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo >> jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci >> vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. >> >> Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri >> vyrabeni jinych polygonu. >> >> Mejte se >> >> T >> >> >> >> Kubajz napsal(a): >> >>> Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se >>> uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho >>> predesleho pokusu s uhulem. Je to tragedie - duplicitni body, >>> prekryvajici se polygony a tech bodu... >>> >>> K >>> >>> Petr Nejedly napsal(a): >>> >>> >>>> kolda at web2net.cz napsal(a): >>>> >>>> >>>> >>>> >>>>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>>>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>>>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>>>> preprocesing vubec. >>>>> >>>>> >>>>> >>>> Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi >>>> polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. >>>> >>>> A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. >>>> To je zase moje agenda ;-) >>>> Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty >>>> pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). >>>> A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale >>>> zeleny ;-) >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080718/fbca70ba/attachment.html>

18.7.2008 07:57:37 (#33)
gravatar

Kubajz

<kubajz at kbx.cz>
614
V odkazech na konci clanku je jedno pekne url, ktere se zabyva shromazdovanim algoritmu pro geometrii. K Tomas Kolda napsal(a): zobrazit citaci
> Paradni publikace, diky za tip. Zkusim to naimplementovat a pak poslu > vysledek. > > Jinak geometricke algoritmy se vzdy hodi, tak jestli znas nejake pekne > misto, kde jsou po kupe, dej vedet. > > T > > > Kubajz napsal(a): >> Ahoj, >> >> aplikoal bych vertex reduction jako soucast DP a DP bych zkusil obohatit >> o napady z tohoto paperu: >> >> http://www.dca.fee.unicamp.br/~ting/Publications/P2001-2005/wu-roci-2003-rfm.pdf >> >> coz by znamenalo sehnat jeste jeden, dva algoritmy v pythonu nebo je >> napsat/konvertovat z jineho jazyka. Slozitost by se vicemene nezvysila a >> meli bychom jistotu, ze mame neprotinajici se polygony. >> >> K >> >> Tomas Kolda napsal(a): >> >>> Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. >>> >>> http://www.web2net.cz/osm/lesy.7z >>> >>> po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi >>> 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez >>> uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. >>> Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo >>> jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci >>> vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. >>> >>> Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri >>> vyrabeni jinych polygonu. >>> >>> Mejte se >>> >>> T >>> >>> >>> >>> Kubajz napsal(a): >>> >>>> Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se >>>> uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho >>>> predesleho pokusu s uhulem. Je to tragedie - duplicitni body, >>>> prekryvajici se polygony a tech bodu... >>>> >>>> K >>>> >>>> Petr Nejedly napsal(a): >>>> >>>> >>>>> kolda at web2net.cz napsal(a): >>>>> >>>>> >>>>> >>>>> >>>>>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po >>>>>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me "navigace" a >>>>>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky >>>>>> preprocesing vubec. >>>>>> >>>>>> >>>>>> >>>>> Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi >>>>> polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. >>>>> >>>>> A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. >>>>> To je zase moje agenda ;-) >>>>> Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty >>>>> pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). >>>>> A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale >>>>> zeleny ;-) >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

23.7.2008 06:30:05 (#34)
gravatar

kolda at web2net.cz

<kolda at web2net.cz>
133
Vcera jsem dodelal ten algoritmus a s 25metrovou chybou a minimalni velikost plochy 2500 m2 to vychazi cca 1.500.000 nodu a 80.000 polygonu. Polygony vypadaji pomerne pekne. Potrebuju ted vyresit zobacky tech cesticek co rezou lesy nebo naopak couhaji. Napada vas neco? Moje napady: 1. Odstranit hrany polygonu, ktere svirajici uhel < 15 stupnu a zaroven je jejich vzdalenost (v limitu krajnich bodu) mensi nez neco. Pokud neco takoveho nastane, muzu decimovat polygon (rozdelit na polygon + diru, nebo polygon + polygon) 2. Bitmapu preprocesovat nejakym low-pass filterem s dobre nastavenym thresholdem. Tim se zrusi cesticky v lesech, ale zase se nam budou zakulacovat rohy (odstrani generalizace) Napada Vas neco lepsiho, jednodussiho atd.? K jake variante se klonite? T zobrazit citaci
> V odkazech na konci clanku je jedno pekne url, ktere se zabyva > shromazdovanim algoritmu pro geometrii. > > K > > Tomas Kolda napsal(a): >> Paradni publikace, diky za tip. Zkusim to naimplementovat a pak poslu >> vysledek. >> >> Jinak geometricke algoritmy se vzdy hodi, tak jestli znas nejake pekne >> misto, kde jsou po kupe, dej vedet. >> >> T >> >> >> Kubajz napsal(a): >>> Ahoj, >>> >>> aplikoal bych vertex reduction jako soucast DP a DP bych zkusil >>> obohatit >>> o napady z tohoto paperu: >>> >>> http://www.dca.fee.unicamp.br/~ting/Publications/P2001-2005/wu-roci-2003-rfm.pdf >>> >>> coz by znamenalo sehnat jeste jeden, dva algoritmy v pythonu nebo je >>> napsat/konvertovat z jineho jazyka. Slozitost by se vicemene nezvysila >>> a >>> meli bychom jistotu, ze mame neprotinajici se polygony. >>> >>> K >>> >>> Tomas Kolda napsal(a): >>> >>>> Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. >>>> >>>> http://www.web2net.cz/osm/lesy.7z >>>> >>>> po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi >>>> 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez >>>> uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. >>>> Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo >>>> jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci >>>> vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. >>>> >>>> Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri >>>> vyrabeni jinych polygonu. >>>> >>>> Mejte se >>>> >>>> T >>>> >>>> >>>> >>>> Kubajz napsal(a): >>>> >>>>> Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se >>>>> uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu >>>>> meho >>>>> predesleho pokusu s uhulem. Je to tragedie - duplicitni body, >>>>> prekryvajici se polygony a tech bodu... >>>>> >>>>> K >>>>> >>>>> Petr Nejedly napsal(a): >>>>> >>>>> >>>>>> kolda at web2net.cz napsal(a): >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani >>>>>>> po >>>>>>> ctvercich. Je to asi dane tim, ze pak data pouzivam do me >>>>>>> "navigace" a >>>>>>> kazdy zbytecny zasah do polygonu zvetsuje databazi, index a >>>>>>> graficky >>>>>>> preprocesing vubec. >>>>>>> >>>>>>> >>>>>>> >>>>>> Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, >>>>>> nejvetsi >>>>>> polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas >>>>>> tak strasne. >>>>>> >>>>>> A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez >>>>>> 2-3km. >>>>>> To je zase moje agenda ;-) >>>>>> Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju >>>>>> objekty >>>>>> pod 3px (catecne na urovni datovych struktur, zbytek pred >>>>>> renderovanim). >>>>>> A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste >>>>>> stale >>>>>> zeleny ;-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

3.8.2008 06:19:00 (#35)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> > Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali > > body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal > > podel tech dlazdic (duvody uz jsem psal minule - treba takove > > krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na > > kousek ulice v Beroune). > > Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak > to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze > je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak > budou vznika usekle vycnelky z tilu...
No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

3.8.2008 10:26:17 (#36)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > >>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>> kousek ulice v Beroune). >> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak >> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze >> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >> budou vznika usekle vycnelky z tilu... > > No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze > rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je > cela uprostred lesa. >
At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany. Na druhou stranu, OSMAPI "takhle" spatne napsany je.... *) http://www.openstreetmap.org/?lat=48.49457&lon=8.2033&zoom=16&layers=B00TTF -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

3.8.2008 11:35:05 (#37)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
zobrazit citaci
>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >> cela uprostred lesa. >> > > At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany.
Myslim ze osmarender to opravdu neresi. Proste renderuje najednou dostatecne velkou dlazdici (+ stahuje o dost vetsi oblast nez chce renderovat) a doufa, ze vetsi les nebude. zobrazit citaci
> Na druhou stranu, OSMAPI "takhle" spatne napsany je....
Jak se tohle da resit? Napada me sestavit z ways polygon a u kazdeho polygonu ulozit jeho bounding box. Ale uz jenom vytvareni polygonu bude problem, protoze way muze byt jak hranice polygonu tak jenom cara, v zavislosti na tom, jake ma tagy.

4.8.2008 03:38:55 (#38)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi neverim.... Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod 1.5mil bodu s chybou 25 metru se asi nedostanem... T Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > > >>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>> kousek ulice v Beroune). >>> >> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak >> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze >> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >> budou vznika usekle vycnelky z tilu... >> > > No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze > rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je > cela uprostred lesa. > >
-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstreetmap.org/pipermail/talk-cz/attachments/20080804/fb008490/attachment.html>

4.8.2008 07:29:16 (#39)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Ahoj, takze generalizovane lesy jsou zde: http://www.web2net.cz/osm/lesy.osm.bz2 naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... http://www.web2net.cz/osm/viewer_080803.zip Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. Statistika: 2.761 multipolygonu 82.160 polygonu 1.605.820 nodu Tak nekdo pls zkouknete a muzem to zacit soupat do osm. T Tomas Kolda writes: zobrazit citaci
> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi > neverim.... > > Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod > 1.5mil bodu s chybou 25 metru se asi nedostanem... > > T > > Pavel Machek napsal(a): >> Ahoj! >> >> >>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>> kousek ulice v Beroune). >>>> >>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>> tak >>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>> ze >>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>> budou vznika usekle vycnelky z tilu... >>> >> >> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >> cela uprostred lesa. >> >> >

4.8.2008 10:03:33 (#40)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Jiri Klement napsal(a): zobrazit citaci
>>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>> cela uprostred lesa. >>> >> At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany. > > Myslim ze osmarender to opravdu neresi. Proste renderuje najednou > dostatecne velkou dlazdici (+ stahuje o dost vetsi oblast nez chce > renderovat) a doufa, ze vetsi les nebude. > >> Na druhou stranu, OSMAPI "takhle" spatne napsany je.... > Jak se tohle da resit? Napada me sestavit z ways polygon a u kazdeho > polygonu ulozit jeho bounding box. Ale uz jenom vytvareni polygonu > bude problem, protoze way muze byt jak hranice polygonu tak jenom > cara, v zavislosti na tom, jake ma tagy.
Ty uvozokvky mely byt spis kolem toho "spatne", ale ono je to jeste horsi nez jsem myslel. OSMAPI dokonce nevrati nic ani v pripade, ze pozadam o bbox protnuty cestou, jejiz vsechny nody jsou vne toho bboxu. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

4.8.2008 11:50:35 (#41)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Pokud budu mluvit pouze za sebe, tak at uz to tam je. Vypada to vyborne. A pripada mi, ze vic lidi spis upravuje, nez vytvari. Takze jestli nekde nejaka cesta ujizdi, nebo je nejaka jina potiz, tak si to kazdej ve svym znamym okoli popotahne rucne. Ta mapa ted vypada o 1000% lip. Dobra prace! On Mon, 04 Aug 2008 07:29:16 +0200, Tomas Kolda <kolda at web2net.cz> wrote: zobrazit citaci
> Ahoj, > > takze generalizovane lesy jsou zde: > > http://www.web2net.cz/osm/lesy.osm.bz2 > > naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve > vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... > > http://www.web2net.cz/osm/viewer_080803.zip > > Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. > Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy > pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. > > Statistika: > > 2.761 multipolygonu > 82.160 polygonu > 1.605.820 nodu > > Tak nekdo pls zkouknete a muzem to zacit soupat do osm. > > T > > Tomas Kolda writes: > >> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi >> neverim.... >> >> Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. >> Pod >> 1.5mil bodu s chybou 25 metru se asi nedostanem... >> >> T >> >> Pavel Machek napsal(a): >>> Ahoj! >>> >>> >>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival >>>>> na >>>>> kousek ulice v Beroune). >>>>> >>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>>> tak >>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>>> ze >>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>>> budou vznika usekle vycnelky z tilu... >>>> >>> >>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>> cela uprostred lesa. >>> >>> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4.8.2008 11:57:48 (#42)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Me ta prohlizecka jede a je ukrutne rychla. Co to chce za knihovnu? On Mon, 04 Aug 2008 11:59:14 +0200, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale > souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo > upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. > > K > > P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade > pro algoritmus? > > Tomas Kolda napsal(a): >> Ahoj, >> >> takze generalizovane lesy jsou zde: >> >> http://www.web2net.cz/osm/lesy.osm.bz2 >> >> naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve >> vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... >> >> http://www.web2net.cz/osm/viewer_080803.zip >> >> Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas >> chyby. >> Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to >> tedy >> pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. >> >> Statistika: >> >> 2.761 multipolygonu >> 82.160 polygonu >> 1.605.820 nodu >> >> Tak nekdo pls zkouknete a muzem to zacit soupat do osm. >> >> T >> >> Tomas Kolda writes: >> >> >>> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi >>> neverim.... >>> >>> Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. >>> Pod >>> 1.5mil bodu s chybou 25 metru se asi nedostanem... >>> >>> T >>> >>> Pavel Machek napsal(a): >>> >>>> Ahoj! >>>> >>>> >>>> >>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom >>>>>> slucovali >>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival >>>>>> na >>>>>> kousek ulice v Beroune). >>>>>> >>>>>> >>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle >>>>> dlazdic, >>>>> tak >>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani >>>>> nevadi, >>>>> ze >>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti >>>>> naopak >>>>> budou vznika usekle vycnelky z tilu... >>>>> >>>>> >>>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>>> cela uprostred lesa. >>>> >>>> >>>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4.8.2008 11:59:14 (#43)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. K P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade pro algoritmus? Tomas Kolda napsal(a): zobrazit citaci
> Ahoj, > > takze generalizovane lesy jsou zde: > > http://www.web2net.cz/osm/lesy.osm.bz2 > > naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve > vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... > > http://www.web2net.cz/osm/viewer_080803.zip > > Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. > Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy > pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. > > Statistika: > > 2.761 multipolygonu > 82.160 polygonu > 1.605.820 nodu > > Tak nekdo pls zkouknete a muzem to zacit soupat do osm. > > T > > Tomas Kolda writes: > > >> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi >> neverim.... >> >> Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod >> 1.5mil bodu s chybou 25 metru se asi nedostanem... >> >> T >> >> Pavel Machek napsal(a): >> >>> Ahoj! >>> >>> >>> >>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>>> kousek ulice v Beroune). >>>>> >>>>> >>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>>> tak >>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>>> ze >>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>>> budou vznika usekle vycnelky z tilu... >>>> >>>> >>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>> cela uprostred lesa. >>> >>> >>> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

4.8.2008 12:16:37 (#44)
gravatar

Kubajz

<kubajz at kbx.cz>
614
MSVCR80.dll a MSVCP80.dll ============== fixme:spoolsv:serv_main (0 (nil)) fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8000000a fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" err:module:import_dll Library MSVCR80.dll (which is needed by L"C:\\windows\\system32\\MSVCP80.dll") not found err:module:import_dll Library MSVCP80.dll (which is needed by L"E:\\Desktop\\viewer\\viewer.exe") not found err:module:import_dll Library MSVCR80.dll (which is needed by L"E:\\Desktop\\viewer\\viewer.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"E:\\Desktop\\viewer\\viewer.exe" failed, status c0000135 =============== K Michal Kovar napsal(a): zobrazit citaci
> Me ta prohlizecka jede a je ukrutne rychla. Co to chce za knihovnu? > > On Mon, 04 Aug 2008 11:59:14 +0200, Kubajz <kubajz at kbx.cz> wrote: > > >> Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale >> souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo >> upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. >> >> K >> >> P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade >> pro algoritmus? >> >> Tomas Kolda napsal(a): >> >>> Ahoj, >>> >>> takze generalizovane lesy jsou zde: >>> >>> http://www.web2net.cz/osm/lesy.osm.bz2 >>> >>> naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve >>> vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... >>> >>> http://www.web2net.cz/osm/viewer_080803.zip >>> >>> Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas >>> chyby. >>> Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to >>> tedy >>> pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. >>> >>> Statistika: >>> >>> 2.761 multipolygonu >>> 82.160 polygonu >>> 1.605.820 nodu >>> >>> Tak nekdo pls zkouknete a muzem to zacit soupat do osm. >>> >>> T >>> >>> Tomas Kolda writes: >>> >>> >>> >>>> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi >>>> neverim.... >>>> >>>> Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. >>>> Pod >>>> 1.5mil bodu s chybou 25 metru se asi nedostanem... >>>> >>>> T >>>> >>>> Pavel Machek napsal(a): >>>> >>>> >>>>> Ahoj! >>>>> >>>>> >>>>> >>>>> >>>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom >>>>>>> slucovali >>>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival >>>>>>> na >>>>>>> kousek ulice v Beroune). >>>>>>> >>>>>>> >>>>>>> >>>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle >>>>>> dlazdic, >>>>>> tak >>>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani >>>>>> nevadi, >>>>>> ze >>>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti >>>>>> naopak >>>>>> budou vznika usekle vycnelky z tilu... >>>>>> >>>>>> >>>>>> >>>>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>>>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>>>> cela uprostred lesa. >>>>> >>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> __________ Informace od NOD32 3301 (20080727) __________ >> >> Tato zprava byla proverena antivirovym systemem NOD32. >> http://www.nod32.cz >> >> >> > > > >

4.8.2008 12:16:38 (#45)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Jeste vecer kdyztak poslu verzi z Mingw, ten ma mnohem mensi zavislosti. Jak to tedka prohlizim, moc se mi nelibi prilisna generalizace nejakych mist. Zkusim to s 12metrovou presnosti, a kdyz bude hezci a vetsi treba jen o 25% tak bych se za ni primluvil... Algoritmus jsem nakonec naimplementoval. Ma slozitost (m*n) a tak i po slusne optimalizaci pocita CR 2 hodiny. T Kubajz writes: zobrazit citaci
> Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale > souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo > upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. > > K > > P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade > pro algoritmus? > > Tomas Kolda napsal(a): >> Ahoj, >> >> takze generalizovane lesy jsou zde: >> >> http://www.web2net.cz/osm/lesy.osm.bz2 >> >> naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve >> vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... >> >> http://www.web2net.cz/osm/viewer_080803.zip >> >> Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. >> Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy >> pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. >> >> Statistika: >> >> 2.761 multipolygonu >> 82.160 polygonu >> 1.605.820 nodu >> >> Tak nekdo pls zkouknete a muzem to zacit soupat do osm. >> >> T >> >> Tomas Kolda writes: >> >> >>> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi >>> neverim.... >>> >>> Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod >>> 1.5mil bodu s chybou 25 metru se asi nedostanem... >>> >>> T >>> >>> Pavel Machek napsal(a): >>> >>>> Ahoj! >>>> >>>> >>>> >>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>>>> kousek ulice v Beroune). >>>>>> >>>>>> >>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>>>> tak >>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>>>> ze >>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>>>> budou vznika usekle vycnelky z tilu... >>>>> >>>>> >>>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>>> cela uprostred lesa. >>>> >>>> >>>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

4.8.2008 12:20:49 (#46)
gravatar

Kubajz

<kubajz at kbx.cz>
614
dik Tomas Kolda napsal(a): zobrazit citaci
> Jeste vecer kdyztak poslu verzi z Mingw, ten ma mnohem mensi zavislosti. Jak > to tedka prohlizim, moc se mi nelibi prilisna generalizace nejakych mist. > Zkusim to s 12metrovou presnosti, a kdyz bude hezci a vetsi treba jen o 25% > tak bych se za ni primluvil... > > Algoritmus jsem nakonec naimplementoval. Ma slozitost (m*n) a tak i po > slusne optimalizaci pocita CR 2 hodiny. > > T > > Kubajz writes: > > >> Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale >> souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo >> upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. >> >> K >> >> P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade >> pro algoritmus? >> >> Tomas Kolda napsal(a): >> >>> Ahoj, >>> >>> takze generalizovane lesy jsou zde: >>> >>> http://www.web2net.cz/osm/lesy.osm.bz2 >>> >>> naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve >>> vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... >>> >>> http://www.web2net.cz/osm/viewer_080803.zip >>> >>> Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. >>> Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy >>> pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. >>> >>> Statistika: >>> >>> 2.761 multipolygonu >>> 82.160 polygonu >>> 1.605.820 nodu >>> >>> Tak nekdo pls zkouknete a muzem to zacit soupat do osm. >>> >>> T >>> >>> Tomas Kolda writes: >>> >>> >>> >>>> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi >>>> neverim.... >>>> >>>> Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod >>>> 1.5mil bodu s chybou 25 metru se asi nedostanem... >>>> >>>> T >>>> >>>> Pavel Machek napsal(a): >>>> >>>> >>>>> Ahoj! >>>>> >>>>> >>>>> >>>>> >>>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>>>>> kousek ulice v Beroune). >>>>>>> >>>>>>> >>>>>>> >>>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>>>>> tak >>>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>>>>> ze >>>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>>>>> budou vznika usekle vycnelky z tilu... >>>>>> >>>>>> >>>>>> >>>>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>>>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>>>> cela uprostred lesa. >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

4.8.2008 12:27:48 (#47)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> MSVCR80.dll
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4.8.2008 12:55:56 (#48)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Tak chytry jsem byl taky, ale porad se tomu nechce.... Neco delam blbe, ale je fakt, ze do wine jsem nikdy poradne nevidel... K Michal Kovar napsal(a): zobrazit citaci
> snadna pomoc > > http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 > http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 > > On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: > > >> MSVCR80.dll >> > > > >

4.8.2008 01:05:53 (#49)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Kam ty knihovny kopirujes? :) On Mon, 04 Aug 2008 12:55:56 +0200, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> Tak chytry jsem byl taky, ale porad se tomu nechce.... Neco delam blbe, > ale je fakt, ze do wine jsem nikdy poradne nevidel... > > K > > Michal Kovar napsal(a): >> snadna pomoc >> >> http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 >> http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 >> >> On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: >> >> >>> MSVCR80.dll >>> >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4.8.2008 01:09:49 (#50)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime knihoven a nainstalovani do systemu. K Michal Kovar napsal(a): zobrazit citaci
> snadna pomoc > > http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 > http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 > > On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: > > >> MSVCR80.dll >> > > > >

4.8.2008 01:12:07 (#51)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
No rekni, jestli ten spenat mezi silnicema neni sexy! :)) On Mon, 04 Aug 2008 13:09:49 +0200, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... > > sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime > knihoven a nainstalovani do systemu. > > K > > Michal Kovar napsal(a): >> snadna pomoc >> >> http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 >> http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 >> >> On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: >> >> >>> MSVCR80.dll >>> >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4.8.2008 01:16:52 (#52)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ono nejde o to kam, ale o to, ze kopiruju jen tyhle dve. V tom baliku od M$ je vic souboru, na kterych jsou tyhle dve knihovny zavisle. Michal Kovar napsal(a): zobrazit citaci
> Kam ty knihovny kopirujes? :) > > On Mon, 04 Aug 2008 12:55:56 +0200, Kubajz <kubajz at kbx.cz> wrote: > > >> Tak chytry jsem byl taky, ale porad se tomu nechce.... Neco delam blbe, >> ale je fakt, ze do wine jsem nikdy poradne nevidel... >> >> K >> >> Michal Kovar napsal(a): >> >>> snadna pomoc >>> >>> http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 >>> http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 >>> >>> On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: >>> >>> >>> >>>> MSVCR80.dll >>>> >>>> >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> __________ Informace od NOD32 3301 (20080727) __________ >> >> Tato zprava byla proverena antivirovym systemem NOD32. >> http://www.nod32.cz >> >> >> > > > >

4.8.2008 01:22:01 (#53)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Toho uz se nekdo rad chopi :) On Mon, 04 Aug 2008 13:24:14 +0200, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> Sexy je, ale na muj vkus je moc hrube namletej... Trosku, ale jen > nepatrne bych ho zkusil pojemnit. Misty je to opravdu takove otesane. > A pak je krasny, jak v UHULu nemaji zaneseny lesy ve vojenskych > ujezdech... > > K > > Michal Kovar napsal(a): >> No rekni, jestli ten spenat mezi silnicema neni sexy! :)) >> >> On Mon, 04 Aug 2008 13:09:49 +0200, Kubajz <kubajz at kbx.cz> wrote: >> >> >>> Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... >>> >>> sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime >>> knihoven a nainstalovani do systemu. >>> >>> K >>> >>> Michal Kovar napsal(a): >>> >>>> snadna pomoc >>>> >>>> http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 >>>> http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 >>>> >>>> On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: >>>> >>>> >>>> >>>>> MSVCR80.dll >>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> __________ Informace od NOD32 3301 (20080727) __________ >>> >>> Tato zprava byla proverena antivirovym systemem NOD32. >>> http://www.nod32.cz >>> >>> >>> >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

4.8.2008 01:24:14 (#54)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Sexy je, ale na muj vkus je moc hrube namletej... Trosku, ale jen nepatrne bych ho zkusil pojemnit. Misty je to opravdu takove otesane. A pak je krasny, jak v UHULu nemaji zaneseny lesy ve vojenskych ujezdech... K Michal Kovar napsal(a): zobrazit citaci
> No rekni, jestli ten spenat mezi silnicema neni sexy! :)) > > On Mon, 04 Aug 2008 13:09:49 +0200, Kubajz <kubajz at kbx.cz> wrote: > > >> Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... >> >> sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime >> knihoven a nainstalovani do systemu. >> >> K >> >> Michal Kovar napsal(a): >> >>> snadna pomoc >>> >>> http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 >>> http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 >>> >>> On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz <kubajz at kbx.cz> wrote: >>> >>> >>> >>>> MSVCR80.dll >>>> >>>> >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> __________ Informace od NOD32 3301 (20080727) __________ >> >> Tato zprava byla proverena antivirovym systemem NOD32. >> http://www.nod32.cz >> >> >> > > > >

4.8.2008 01:25:18 (#55)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Tomas Kolda napsal(a): zobrazit citaci
> Jeste vecer kdyztak poslu verzi z Mingw, ten ma mnohem mensi zavislosti. Jak >
uz je to OK - vyreseno... zobrazit citaci
> to tedka prohlizim, moc se mi nelibi prilisna generalizace nejakych mist. > Zkusim to s 12metrovou presnosti, a kdyz bude hezci a vetsi treba jen o 25% >
Primlouvam se za ni okamzite... Takhle je to hezke, ale rekl bych, ze bychom si to mohli dovolit. zobrazit citaci
> tak bych se za ni primluvil... > > Algoritmus jsem nakonec naimplementoval. Ma slozitost (m*n) a tak i po > slusne optimalizaci pocita CR 2 hodiny. > > T > > Kubajz writes: > > >> Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale >> souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo >> upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. >> >> K >> >> P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade >> pro algoritmus? >> >> Tomas Kolda napsal(a): >> >>> Ahoj, >>> >>> takze generalizovane lesy jsou zde: >>> >>> http://www.web2net.cz/osm/lesy.osm.bz2 >>> >>> naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve >>> vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... >>> >>> http://www.web2net.cz/osm/viewer_080803.zip >>> >>> Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. >>> Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy >>> pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. >>> >>> Statistika: >>> >>> 2.761 multipolygonu >>> 82.160 polygonu >>> 1.605.820 nodu >>> >>> Tak nekdo pls zkouknete a muzem to zacit soupat do osm. >>> >>> T >>> >>> Tomas Kolda writes: >>> >>> >>> >>>> Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi >>>> neverim.... >>>> >>>> Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod >>>> 1.5mil bodu s chybou 25 metru se asi nedostanem... >>>> >>>> T >>>> >>>> Pavel Machek napsal(a): >>>> >>>> >>>>> Ahoj! >>>>> >>>>> >>>>> >>>>> >>>>>>> Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali >>>>>>> body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal >>>>>>> podel tech dlazdic (duvody uz jsem psal minule - treba takove >>>>>>> krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na >>>>>>> kousek ulice v Beroune). >>>>>>> >>>>>>> >>>>>>> >>>>>> Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, >>>>>> tak >>>>>> to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, >>>>>> ze >>>>>> je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak >>>>>> budou vznika usekle vycnelky z tilu... >>>>>> >>>>>> >>>>>> >>>>> No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze >>>>> rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je >>>>> cela uprostred lesa. >>>>> >>>>> >>>>> >>>>> >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

4.8.2008 04:07:58 (#56)
gravatar

hanoj

<ehanoj at gmail.com>
713
Ahoj 1) generalizace UHUL lesu je pro moje oko vyhovujici. pekna prace. Originaly by mohly byt nekde vystaveny ve vhodnem a jednoduchem souborovem formatu (treba shapefile). 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi oblasti (napr. okres)? 3) co je to za format MXF? ha hanoj

4.8.2008 04:47:18 (#57)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
hanoj writes: zobrazit citaci
> Ahoj > > 1) generalizace UHUL lesu je pro moje oko vyhovujici. pekna prace. > Originaly by mohly byt nekde vystaveny ve vhodnem a jednoduchem > souborovem formatu (treba shapefile).
Shapefile muzu udelat. Diry v nem neumim, ale snad to nekde najdu. zobrazit citaci
> 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi > oblasti (napr. okres)?
Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. zobrazit citaci
> 3) co je to za format MXF?
To je muj format, ktery pouzivam. Nekdy by to mela byt navigace... Aktualne jsem si zaregistroval degu.cz (jako OSMak degu...) Je to v podstate OSM s prostorovym indexem, R/W moznosti a velmi dobrou komprimaci. Nic standardniho... T zobrazit citaci
> > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

4.8.2008 11:11:39 (#58)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Ahoj, tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Dik T Tomas Kolda writes: zobrazit citaci
> hanoj writes: > >> Ahoj >> >> 1) generalizace UHUL lesu je pro moje oko vyhovujici. pekna prace. >> Originaly by mohly byt nekde vystaveny ve vhodnem a jednoduchem >> souborovem formatu (treba shapefile). > > Shapefile muzu udelat. Diry v nem neumim, ale snad to nekde najdu. > >> 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi >> oblasti (napr. okres)? > > Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. > Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. > >> 3) co je to za format MXF? > > To je muj format, ktery pouzivam. Nekdy by to mela byt navigace... Aktualne > jsem si zaregistroval degu.cz (jako OSMak degu...) Je to v podstate OSM s > prostorovym indexem, R/W moznosti a velmi dobrou komprimaci. Nic > standardniho... > > T > >> >> ha >> hanoj >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

4.8.2008 11:19:17 (#59)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> takze generalizovane lesy jsou zde: > > http://www.web2net.cz/osm/lesy.osm.bz2 > > naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve > vyssich zoomech bez generalizace, takze mozna trochu pomalejsi...
Vypada to pekne. Naimportoval jsem to do josm (coz chvili trvalo), ale po zazoomovani se s tim pracovat da... tj. s jednotlivymi okresy problem urcite nebude. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

4.8.2008 11:22:09 (#60)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
Tak Hur? do "Aploudu" :) zobrazit citaci
> ------------ P?vodn? zpr?va ------------ > Od: Pavel Machek <pavel at suse.cz> > P?edm?t: Re: [Talk-cz] pokusny import lesu > Datum: 04.8.2008 23:18:04 > ---------------------------------------- > Ahoj! > > > takze generalizovane lesy jsou zde: > > > > http://www.web2net.cz/osm/lesy.osm.bz2 > > > > naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve > > vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... > > Vypada to pekne. Naimportoval jsem to do josm (coz chvili trvalo), ale > po zazoomovani se s tim pracovat da... tj. s jednotlivymi okresy > problem urcite nebude. > Pavel > -- > (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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
---- S pozdravem Mail: psbox at seznam.cz http://fatbozz.towerofglass.net

4.8.2008 11:24:25 (#61)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni > ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem > urcil na 60x60metru. > > Jine varianty byly moc bodu... Takto je to: > 2.567 multipolygonu > 75.940 polygonu > 1.747.590 nodu > > Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz > zkompilovane pomoci MINGW, takze snad bez problemu. > > http://www.web2net.cz/osm/viewer_080804.zip
Byl by .osm.bz2? zobrazit citaci
> Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. > Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se > rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit > po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi?
Ja jsem silnice importoval normalne josm-kem. Kdyz spadne spojeni, staci znovu zmacknout upload, josm to zvladne. Pruser by asi byl kdyby padl pocitac nebo josm -- coz se mi nastesti neprihodilo. Doporucoval bych velky .OSM rozdelit na takovych 20 dilu, a proste to uploadovat rucne josm... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

4.8.2008 11:26:42 (#62)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Mon 2008-08-04 23:24:25, Pavel Machek wrote: zobrazit citaci
> Ahoj! > > > tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni > > ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem > > urcil na 60x60metru. > > > > Jine varianty byly moc bodu... Takto je to: > > 2.567 multipolygonu > > 75.940 polygonu > > 1.747.590 nodu > > > > Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz > > zkompilovane pomoci MINGW, takze snad bez problemu. > > > > http://www.web2net.cz/osm/viewer_080804.zip > > Byl by .osm.bz2? > > > Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. > > Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se > > rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit > > po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? > > Ja jsem silnice importoval normalne josm-kem. Kdyz spadne spojeni, > staci znovu zmacknout upload, josm to zvladne. > > Pruser by asi byl kdyby padl pocitac nebo josm -- coz se mi nastesti > neprihodilo. Doporucoval bych velky .OSM rozdelit na takovych 20 dilu, > a proste to uploadovat rucne josm...
Jo... urcite by bylo dobry pridat nejaky znacky... landuse=forest, source=uhul... a asi i neco k bodum. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 12:38:20 (#63)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
>> 1) generalizace UHUL lesu je pro moje oko vyhovujici. pekna prace. >> Originaly by mohly byt nekde vystaveny ve vhodnem a jednoduchem >> souborovem formatu (treba shapefile). > > Shapefile muzu udelat. Diry v nem neumim, ale snad to nekde najdu.
*** mam pocit, ze nejak to jde, ale asi je to nejake rozsireni ci co. Nebo nejake GML, ale preci jen to jeste neni vsude podporovano, ale ma nadeji. Rozhodne to GISasci oceni. zobrazit citaci
>> 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi >> oblasti (napr. okres)? > > Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. > Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi.
*** Nez to uploadnem, mela by existovat jistota, ze budeme schopni efektivne data v CR dale editovat napric platformami. Pokud tato jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha pracovat s ctvercem o hrane 20km neni az tak neprirozena. zobrazit citaci
>> 3) co je to za format MXF? > > To je muj format, ktery pouzivam. Nekdy by to mela byt navigace... Aktualne > jsem si zaregistroval degu.cz (jako OSMak degu...) Je to v podstate OSM s > prostorovym indexem, R/W moznosti a velmi dobrou komprimaci. Nic > standardniho...
*** aha, myslel jsem ze je to neco co neznam ;) ha hanoj

5.8.2008 01:11:42 (#64)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Pavel Machek napsal(a): zobrazit citaci
> Jo... urcite by bylo dobry pridat nejaky znacky... landuse=forest, > source=uhul... a asi i neco k bodum.
Waye maji landuse=forest spravne nastavene, source nebo nejaky jiny identifikator tohoto uploadu by nebyl od veci, ale rozhodne bych netagoval nody, je to drahe a zbytecne.... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.8.2008 01:12:33 (#65)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > >> tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni >> ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem >> urcil na 60x60metru. >> >> Jine varianty byly moc bodu... Takto je to: >> 2.567 multipolygonu >> 75.940 polygonu >> 1.747.590 nodu >> >> Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz >> zkompilovane pomoci MINGW, takze snad bez problemu. >> >> http://www.web2net.cz/osm/viewer_080804.zip > > Byl by .osm.bz2? > >> Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. >> Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se >> rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit >> po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? > > Ja jsem silnice importoval normalne josm-kem.
Coz m.j. znamena generovat zaporna ID. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.8.2008 07:48:32 (#66)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Dik za rady. Zaporne idcka mam, otaguju uhulem. Jen to tedy splitnu a zkusim JOSMem vecer naimportovat prvni dvacetinu co to udela. Mam tedy importovat tu druhou variantu? T Petr Nejedly writes: zobrazit citaci
> Pavel Machek napsal(a): >> Ahoj! >> >>> tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni >>> ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem >>> urcil na 60x60metru. >>> >>> Jine varianty byly moc bodu... Takto je to: >>> 2.567 multipolygonu >>> 75.940 polygonu >>> 1.747.590 nodu >>> >>> Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz >>> zkompilovane pomoci MINGW, takze snad bez problemu. >>> >>> http://www.web2net.cz/osm/viewer_080804.zip >> >> Byl by .osm.bz2? >> >>> Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. >>> Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se >>> rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit >>> po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? >> >> Ja jsem silnice importoval normalne josm-kem. > > Coz m.j. znamena generovat zaporna ID. > > -- > 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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

5.8.2008 09:41:03 (#67)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Ja jsem pro. Uz vcera se mi to libilo a tohle je jeste lepsi. Uz se tesim, az to tam bude :) Jen by me zajimalo, co se stane se stavajicimi lesy, ktere uz na serveru jsou - budou smazany nebo budou "pres sebe"? On Tue, 05 Aug 2008 07:48:32 +0200, Tomas Kolda <kolda at web2net.cz> wrote: zobrazit citaci
> Dik za rady. Zaporne idcka mam, otaguju uhulem. Jen to tedy splitnu a > zkusim > JOSMem vecer naimportovat prvni dvacetinu co to udela. Mam tedy > importovat > tu druhou variantu? > > T > > Petr Nejedly writes: > >> Pavel Machek napsal(a): >>> Ahoj! >>> >>>> tak dnes jeste jednou. Udelal jsem generalizaci na 20metru >>>> + odstraneni >>>> ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu >>>> jsem >>>> urcil na 60x60metru. >>>> >>>> Jine varianty byly moc bodu... Takto je to: >>>> 2.567 multipolygonu >>>> 75.940 polygonu >>>> 1.747.590 nodu >>>> >>>> Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni >>>> jiz >>>> zkompilovane pomoci MINGW, takze snad bez problemu. >>>> >>>> http://www.web2net.cz/osm/viewer_080804.zip >>> >>> Byl by .osm.bz2? >>> >>>> Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi >>>> dat. >>>> Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni >>>> se >>>> rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM >>>> rozdelit >>>> po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? >>> >>> Ja jsem silnice importoval normalne josm-kem. >> >> Coz m.j. znamena generovat zaporna ID. >> >> -- >> 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

5.8.2008 09:43:15 (#68)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2008/8/5 Michal Kovar <megabordel at seznam.cz>: zobrazit citaci
> Ja jsem pro. Uz vcera se mi to libilo a tohle je jeste lepsi. Uz se tesim, > az to tam bude :) Jen by me zajimalo, co se stane se stavajicimi lesy, > ktere uz na serveru jsou - budou smazany nebo budou "pres sebe"? >
Stavajici lesy nijak nemenit!!! Je jich tam tak malo, ze se lehce opravi rucne. -- Michal Gr?zl http://walley.org

5.8.2008 09:46:27 (#69)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
To jsem si myslel :) On Tue, 05 Aug 2008 09:43:15 +0200, Michal Gr?zl <michal.grezl at gmail.com> wrote: zobrazit citaci
> 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >> Ja jsem pro. Uz vcera se mi to libilo a tohle je jeste lepsi. Uz se >> tesim, >> az to tam bude :) Jen by me zajimalo, co se stane se stavajicimi lesy, >> ktere uz na serveru jsou - budou smazany nebo budou "pres sebe"? >> > Stavajici lesy nijak nemenit!!! > Je jich tam tak malo, ze se lehce opravi rucne. > > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

5.8.2008 10:05:20 (#70)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Druha se mi zda subjektivne hezci. Jsem pro otagovat to source=uhul:wms Importovat pravdepodobne po nejakych rozumne velkych celcich skrz JOSM. Dobra prace! K Tomas Kolda napsal(a): zobrazit citaci
> Dik za rady. Zaporne idcka mam, otaguju uhulem. Jen to tedy splitnu a zkusim > JOSMem vecer naimportovat prvni dvacetinu co to udela. Mam tedy importovat > tu druhou variantu? > > T > > Petr Nejedly writes: > > >> Pavel Machek napsal(a): >> >>> Ahoj! >>> >>> >>>> tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni >>>> ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem >>>> urcil na 60x60metru. >>>> >>>> Jine varianty byly moc bodu... Takto je to: >>>> 2.567 multipolygonu >>>> 75.940 polygonu >>>> 1.747.590 nodu >>>> >>>> Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz >>>> zkompilovane pomoci MINGW, takze snad bez problemu. >>>> >>>> http://www.web2net.cz/osm/viewer_080804.zip >>>> >>> Byl by .osm.bz2? >>> >>> >>>> Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. >>>> Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se >>>> rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit >>>> po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? >>>> >>> Ja jsem silnice importoval normalne josm-kem. >>> >> Coz m.j. znamena generovat zaporna ID. >> >> -- >> 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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

5.8.2008 10:20:59 (#71)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> >> 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi > >> oblasti (napr. okres)? > > > > Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. > > Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. > *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni > efektivne data v CR dale editovat napric platformami. Pokud tato > jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha > pracovat s ctvercem o hrane 20km neni az tak neprirozena.
Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s necim o hrane 20km fakt nebude problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 10:59:41 (#72)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > >>>> 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi >>>> oblasti (napr. okres)? >>> Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. >>> Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. >> *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni >> efektivne data v CR dale editovat napric platformami. Pokud tato >> jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha >> pracovat s ctvercem o hrane 20km neni az tak neprirozena. > > Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s
Opravdu? Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. BTW: josm-ng nahral vpohode, celou CR vyrendroval za ~300ms a moje lokalni, necommitnuta verze maluje i diry v multipolygonech... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.8.2008 11:29:20 (#73)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Tue 2008-08-05 10:59:41, Petr Nejedly wrote: zobrazit citaci
> Pavel Machek napsal(a): > > Ahoj! > > > >>>> 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi > >>>> oblasti (napr. okres)? > >>> Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. > >>> Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. > >> *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni > >> efektivne data v CR dale editovat napric platformami. Pokud tato > >> jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha > >> pracovat s ctvercem o hrane 20km neni az tak neprirozena. > > > > Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s > > Opravdu?
Jo. zobrazit citaci
> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset > zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, > pocitac funel a funel a stale nebylo hotovo.
No, ja u prvniho renderovani nebyl. Kdyz jsem se vratil, bylo hotovo, a prvni operace byla "zoom". Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 11:31:26 (#74)
gravatar

Kubajz

<kubajz at kbx.cz>
614
No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani JOSM-ng v jaru? Onehda jsem se to pokousel zbuildovat a nejak mi to neslo... Diky, K Petr Nejedly napsal(a): zobrazit citaci
> Pavel Machek napsal(a): > >> Ahoj! >> >> >>>>> 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi >>>>> oblasti (napr. okres)? >>>>> >>>> Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. >>>> Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. >>>> >>> *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni >>> efektivne data v CR dale editovat napric platformami. Pokud tato >>> jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha >>> pracovat s ctvercem o hrane 20km neni az tak neprirozena. >>> >> Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s >> > > Opravdu? > Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset > zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, > pocitac funel a funel a stale nebylo hotovo. > Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu > velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. > > BTW: josm-ng nahral vpohode, celou CR vyrendroval za ~300ms a moje lokalni, necommitnuta verze > maluje i diry v multipolygonech... >

5.8.2008 12:15:51 (#75)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
>> 3) co je to za format MXF? > > To je muj format, ktery pouzivam. Nekdy by to mela byt navigace... Aktualne > jsem si zaregistroval degu.cz (jako OSMak degu...) Je to v podstate OSM s > prostorovym indexem, R/W moznosti a velmi dobrou komprimaci. Nic > standardniho... >
Jak na to tak koukam, stale resime podobne problemy (josm-ng a viewer). Pro ladeni josm-ng pouzivam takovy jednoduchy binarni format (nema index), ktery (bez dalsi komprese) je jen o trochu vetsi nez .osm.bz2 a po gzip kompresi je dokonce mensi, a hlavne, ktery nactu 10x rychleji nez parsovat to XMLko. A je ekvivalentem toho "extended" .osm formatu, cili obsahuje vsechny informace, vcetne action=add, modified flagu a podobne. Opravdu MXF pokryva komplet data z OSM? To by me zajimalo. Ja v soucasne dobe prostorovy index a detail level resim v RAM, ale API DataSetu mam trochu pripravene na to, ze by sam mohl resit index. Checkbox "quality rendering" planuju uz od te doby, co jsem antialiasing natvrdo vypnul ;-) Ted mam rozdelane multistyly - vic malovacich pravidel pro jednu entitu, skladane podle ruznych tagu, jako ze napriklad ulice s tramvaji tam ma ty cary obe, kulatak je malovany podle typu silnice, ale zaroven zelene vyplneny a tak. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.8.2008 12:20:46 (#76)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Kubajz napsal(a): zobrazit citaci
> No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani > JOSM-ng v jaru?
http://shell.sh.cvut.cz/~nenik/josmng.html Ted jsem to zkousel a je tam jeste ten styl, co "doprostred" lesniho polygonu namaluje stromecek, coz ted pri pohledu na CR vypada vskutku zabavne... zobrazit citaci
> Onehda jsem se to pokousel zbuildovat a nejak mi to neslo...
Hmm, chce to mit pobliz nainstalovane NetBeans a jednou to v nich otevrit. Budu muset ten build script predelat... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.8.2008 01:03:30 (#77)
gravatar

hanoj

<ehanoj at gmail.com>
713
zobrazit citaci
> Opravdu? > Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset > zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, > pocitac funel a funel a stale nebylo hotovo. > Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu > velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal.
*** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. hanoj

5.8.2008 05:00:50 (#78)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout. Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) T hanoj writes: zobrazit citaci
>> Opravdu? >> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset >> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, >> pocitac funel a funel a stale nebylo hotovo. >> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu >> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. > *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto > asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu > 7.10, java 1.5. > *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. > > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

5.8.2008 05:05:37 (#79)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. > Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit > zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by > si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), > vycistit ho a pak uploadnout.
No ty cesticky me taky napadly... Vychazi to na cca 2000 zelenych fleku na soubor, to by se dalo rucne zlehka proklepnout ... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.8.2008 05:16:03 (#80)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
MXF obsahuje vsechny informace nutne k vykresleni objektu (geometrii, typ (landuse), podtyp(forest), dodatecne atributy k typu/podtypu, ktere typ zna). Nenacitaji se ty informace jimz nerozumi (autor, apod.). Samozrejmne neobsahuje atributy add apod, protoze k tomu neni urcen. Kdyz se ale pridaji nejake modifikatory, tak by to jit melo. Ale jak uz jsem psal drive, neni to moje priorita. Je tam zabudovana moznost editace, ale ne pro OSM. Navrh neni delany na OSM, ale spise na formaty typu GDF. OSM se do GDF da ohnout, takze pro prohlizeni neni zadny problem. Pro JOSM to ale asi pouzitelne neni. Tvoje priorita asi nebude diskovy prostor, takze indexy ci cokoliv muzes udelat i s plejtvanim a vice moznostmi. Multistyly zatim nemam. Resim to skutecne jen zorderem. Napr se nejdrive kresli highway a na ni tram (zorder v OSM posouva vsechny tyto vrstvy najednou). Je to duplicita dat a moznost ke zmenseni, ale videl bych to max 2-3% spis min. Potreboval jsem jednoduchy zpusob jak co nejrychleji dostat objekty daneho typu v danem pohledu a to tento zpusob ulozeni zvlada okamzite. Pote se daji posilat do graficke pipeline velke kusy geometrii a vse se kresli rychleji. T Petr Nejedly writes: zobrazit citaci
> Tomas Kolda napsal(a): >>> 3) co je to za format MXF? >> >> To je muj format, ktery pouzivam. Nekdy by to mela byt navigace... Aktualne >> jsem si zaregistroval degu.cz (jako OSMak degu...) Je to v podstate OSM s >> prostorovym indexem, R/W moznosti a velmi dobrou komprimaci. Nic >> standardniho... >> > > Jak na to tak koukam, stale resime podobne problemy (josm-ng a viewer). > Pro ladeni josm-ng pouzivam takovy jednoduchy binarni format (nema index), > ktery (bez dalsi komprese) je jen o trochu vetsi nez .osm.bz2 a po gzip kompresi > je dokonce mensi, a hlavne, ktery nactu 10x rychleji nez parsovat to XMLko. > A je ekvivalentem toho "extended" .osm formatu, cili obsahuje vsechny > informace, vcetne action=add, modified flagu a podobne. > Opravdu MXF pokryva komplet data z OSM? To by me zajimalo. > Ja v soucasne dobe prostorovy index a detail level resim v RAM, ale API > DataSetu mam trochu pripravene na to, ze by sam mohl resit index. > > Checkbox "quality rendering" planuju uz od te doby, co jsem antialiasing > natvrdo vypnul ;-) > > Ted mam rozdelane multistyly - vic malovacich pravidel pro jednu entitu, > skladane podle ruznych tagu, jako ze napriklad ulice s tramvaji tam ma ty cary > obe, kulatak je malovany podle typu silnice, ale zaroven zelene vyplneny a tak. > > > -- > 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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

5.8.2008 06:16:38 (#81)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Neco posli a ja si to opravim. Prednostne se hlasim o krivoklatsko, berounsko, jih prahy, sumavu a zapadni krkonose. Tam to znam zpravidla celkem dobre :) K Tomas Kolda napsal(a): zobrazit citaci
> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. > Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit > zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by > si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), > vycistit ho a pak uploadnout. > > Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) > > T > > hanoj writes: > > >>> Opravdu? >>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset >>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, >>> pocitac funel a funel a stale nebylo hotovo. >>> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu >>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>> >> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >> 7.10, java 1.5. >> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >> >> hanoj >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

5.8.2008 06:21:23 (#82)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Jih Prahy obyvam, tak budu hezky mlcky sledovat, jak nam to tu roste :) On Tue, 05 Aug 2008 18:16:38 +0200, Kubajz <kubajz at kbx.cz> wrote: zobrazit citaci
> Neco posli a ja si to opravim. Prednostne se hlasim o krivoklatsko, > berounsko, jih prahy, sumavu a zapadni krkonose. Tam to znam zpravidla > celkem dobre :) > > K > > Tomas Kolda napsal(a): >> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >> formatu. >> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >> Zrusit >> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >> Kazdy by >> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na >> 23), >> vycistit ho a pak uploadnout. >> >> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) >> >> T >> >> hanoj writes: >> >> >>>> Opravdu? >>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>> vysledny dataset >>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>> wireframe modu, >>>> pocitac funel a funel a stale nebylo hotovo. >>>> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor >>>> sestavuje jednu >>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>> >>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>> 7.10, java 1.5. >>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>> >>> hanoj >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

5.8.2008 06:25:27 (#83)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) zobrazit citaci
> Tomas Kolda napsal(a): >> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >> formatu. >> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >> Zrusit >> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >> Kazdy by >> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na >> 23), >> vycistit ho a pak uploadnout. >> >> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) >> >> T >> >> hanoj writes: >> >> >>>> Opravdu? >>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>> vysledny dataset >>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>> wireframe modu, >>>> pocitac funel a funel a stale nebylo hotovo. >>>> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor >>>> sestavuje jednu >>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>> >>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>> 7.10, java 1.5. >>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>> >>> hanoj >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

5.8.2008 06:40:02 (#84)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se ke svemu vybranemu kousku dopise. Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval kvuli testovani SemanticWiki. Login tam neni nutny. 2008/8/5 Michal Kovar <megabordel at seznam.cz>: zobrazit citaci
> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako > redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak > rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) > >> Tomas Kolda napsal(a): >>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >>> formatu. >>> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >>> Zrusit >>> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >>> Kazdy by >>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na >>> 23), >>> vycistit ho a pak uploadnout. >>> >>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) >>> >>> T >>> >>> hanoj writes: >>> >>> >>>>> Opravdu? >>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>>> vysledny dataset >>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>>> wireframe modu, >>>>> pocitac funel a funel a stale nebylo hotovo. >>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor >>>>> sestavuje jednu >>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>>> >>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>>> 7.10, java 1.5. >>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>>> >>>> hanoj >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> __________ Informace od NOD32 3301 (20080727) __________ >> >> Tato zprava byla proverena antivirovym systemem NOD32. >> http://www.nod32.cz >> >> > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

5.8.2008 07:20:20 (#85)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
A kdo to p?erendruje v T at H :) ?

5.8.2008 07:21:24 (#86)
gravatar

Pavel Machek

<pavel at ucw.cz>
1023 1226
Ahoj! zobrazit citaci
> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. > Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit > zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by > si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), > vycistit ho a pak uploadnout.
Myslim ze neni duvod tohle delat _pred_ uploadem -- tech zmen nebude tak moc a jediny co takhle vznikne bude velky zmatek. Mnohem jednodussi bude kdyz kazdy po uploadu zkoukne casti ktery ho zajimaji -- az bude mit cas/naladu. zobrazit citaci
> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :)
Uploadit... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 07:33:59 (#87)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. Klidne bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. Nasel jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi co napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, hromadne to tam muzu dat vzdy.... http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy T Jiri Klement writes: zobrazit citaci
> Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne > poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se > ke svemu vybranemu kousku dopise. > > Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla > pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval > kvuli testovani SemanticWiki. Login tam neni nutny. > > 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako >> redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak >> rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) >> >>> Tomas Kolda napsal(a): >>>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >>>> formatu. >>>> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >>>> Zrusit >>>> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >>>> Kazdy by >>>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na >>>> 23), >>>> vycistit ho a pak uploadnout. >>>> >>>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) >>>> >>>> T >>>> >>>> hanoj writes: >>>> >>>> >>>>>> Opravdu? >>>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>>>> vysledny dataset >>>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>>>> wireframe modu, >>>>>> pocitac funel a funel a stale nebylo hotovo. >>>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor >>>>>> sestavuje jednu >>>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>>>> >>>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >>>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>>>> 7.10, java 1.5. >>>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>>>> >>>>> hanoj >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> __________ Informace od NOD32 3301 (20080727) __________ >>> >>> Tato zprava byla proverena antivirovym systemem NOD32. >>> http://www.nod32.cz >>> >>> >> >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

5.8.2008 07:43:43 (#88)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, kdyz to tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad opravi... T Tomas Kolda writes: zobrazit citaci
> Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. Klidne > bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat > pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. Nasel > jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi co > napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem > jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, hromadne to > tam muzu dat vzdy.... > > http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy > > T > > Jiri Klement writes: > >> Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne >> poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se >> ke svemu vybranemu kousku dopise. >> >> Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla >> pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval >> kvuli testovani SemanticWiki. Login tam neni nutny. >> >> 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >>> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako >>> redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak >>> rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) >>> >>>> Tomas Kolda napsal(a): >>>>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >>>>> formatu. >>>>> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >>>>> Zrusit >>>>> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >>>>> Kazdy by >>>>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na >>>>> 23), >>>>> vycistit ho a pak uploadnout. >>>>> >>>>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) >>>>> >>>>> T >>>>> >>>>> hanoj writes: >>>>> >>>>> >>>>>>> Opravdu? >>>>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>>>>> vysledny dataset >>>>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>>>>> wireframe modu, >>>>>>> pocitac funel a funel a stale nebylo hotovo. >>>>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor >>>>>>> sestavuje jednu >>>>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>>>>> >>>>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >>>>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>>>>> 7.10, java 1.5. >>>>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>>>>> >>>>>> hanoj >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> __________ Informace od NOD32 3301 (20080727) __________ >>>> >>>> Tato zprava byla proverena antivirovym systemem NOD32. >>>> http://www.nod32.cz >>>> >>>> >>> >>> >>> >>> -- >>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

5.8.2008 08:16:54 (#89)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
Me zase vychazi, ze vetsina lidi pise ze prvne zkontrolovat. Nebo muzeme udelat kompromis, oblasti co si nikdo nevezme za 2 tydny se pak nahraji bez kontroly. 2008/8/5 Tomas Kolda <kolda at web2net.cz>: zobrazit citaci
> Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, kdyz to > tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu > nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad > opravi... > > T > > Tomas Kolda writes: > >> Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. Klidne >> bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat >> pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. Nasel >> jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi co >> napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem >> jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, hromadne to >> tam muzu dat vzdy.... >> >> http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy >> >> T >> >> Jiri Klement writes: >> >>> Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne >>> poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se >>> ke svemu vybranemu kousku dopise. >>> >>> Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla >>> pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval >>> kvuli testovani SemanticWiki. Login tam neni nutny. >>> >>> 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >>>> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako >>>> redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak >>>> rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) >>>> >>>>> Tomas Kolda napsal(a): >>>>>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >>>>>> formatu. >>>>>> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >>>>>> Zrusit >>>>>> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >>>>>> Kazdy by >>>>>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na >>>>>> 23), >>>>>> vycistit ho a pak uploadnout. >>>>>> >>>>>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) >>>>>> >>>>>> T >>>>>> >>>>>> hanoj writes: >>>>>> >>>>>> >>>>>>>> Opravdu? >>>>>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>>>>>> vysledny dataset >>>>>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>>>>>> wireframe modu, >>>>>>>> pocitac funel a funel a stale nebylo hotovo. >>>>>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor >>>>>>>> sestavuje jednu >>>>>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>>>>>> >>>>>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >>>>>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>>>>>> 7.10, java 1.5. >>>>>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>>>>>> >>>>>>> hanoj >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> __________ Informace od NOD32 3301 (20080727) __________ >>>>> >>>>> Tato zprava byla proverena antivirovym systemem NOD32. >>>>> http://www.nod32.cz >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

5.8.2008 08:26:12 (#90)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Unika mi pointa tyhle "prenatalni" kontroly. K cemu to bude? Mista, ktera lidi zajimaji, budou opravena. Mista, na ktere se*e pes muzou zustat tak jak jsou. On Tue, 05 Aug 2008 20:16:54 +0200, Jiri Klement <jiri.klement at gmail.com> wrote: zobrazit citaci
> Me zase vychazi, ze vetsina lidi pise ze prvne zkontrolovat. Nebo > muzeme udelat kompromis, oblasti co si nikdo nevezme za 2 tydny se pak > nahraji bez kontroly. > > 2008/8/5 Tomas Kolda <kolda at web2net.cz>: >> Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, >> kdyz to >> tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu >> nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad >> opravi... >> >> T >> >> Tomas Kolda writes: >> >>> Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. >>> Klidne >>> bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat >>> pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. >>> Nasel >>> jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi >>> co >>> napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem >>> jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, >>> hromadne to >>> tam muzu dat vzdy.... >>> >>> http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy >>> >>> T >>> >>> Jiri Klement writes: >>> >>>> Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne >>>> poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se >>>> ke svemu vybranemu kousku dopise. >>>> >>>> Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla >>>> pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval >>>> kvuli testovani SemanticWiki. Login tam neni nutny. >>>> >>>> 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >>>>> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako >>>>> redneck. Napraskat to na server tak jak to lezi a vcelky delnice si >>>>> to pak >>>>> rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) >>>>> >>>>>> Tomas Kolda napsal(a): >>>>>>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >>>>>>> formatu. >>>>>>> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >>>>>>> Zrusit >>>>>>> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >>>>>>> Kazdy by >>>>>>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat >>>>>>> na >>>>>>> 23), >>>>>>> vycistit ho a pak uploadnout. >>>>>>> >>>>>>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi >>>>>>> :) >>>>>>> >>>>>>> T >>>>>>> >>>>>>> hanoj writes: >>>>>>> >>>>>>> >>>>>>>>> Opravdu? >>>>>>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>>>>>>> vysledny dataset >>>>>>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>>>>>>> wireframe modu, >>>>>>>>> pocitac funel a funel a stale nebylo hotovo. >>>>>>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak >>>>>>>>> SimplePaintVisitor >>>>>>>>> sestavuje jednu >>>>>>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>>>>>>> >>>>>>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale >>>>>>>> trvaloto >>>>>>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>>>>>>> 7.10, java 1.5. >>>>>>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>>>>>>> >>>>>>>> hanoj >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> __________ Informace od NOD32 3301 (20080727) __________ >>>>>> >>>>>> Tato zprava byla proverena antivirovym systemem NOD32. >>>>>> http://www.nod32.cz >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

5.8.2008 08:29:00 (#91)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
Jedine souhlas, kontrola by se mela delat za behu, ne tohle "tady to je asi takhle" ale kdo chce,casem si upravi. zobrazit citaci
> Unika mi pointa tyhle "prenatalni" kontroly. K cemu to bude? Mista, ktera > lidi zajimaji, budou opravena. Mista, na ktere se*e pes muzou zustat tak > jak jsou. > > On Tue, 05 Aug 2008 20:16:54 +0200, Jiri Klement <jiri.klement at gmail.com> > wrote: > > > Me zase vychazi, ze vetsina lidi pise ze prvne zkontrolovat. Nebo > > muzeme udelat kompromis, oblasti co si nikdo nevezme za 2 tydny se pak > > nahraji bez kontroly. > > > > 2008/8/5 Tomas Kolda <kolda at web2net.cz>: > >> Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, > >> kdyz to > >> tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu > >> nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad > >> opravi... > >> > >> T > >> > >> Tomas Kolda writes: > >> > >>> Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. > >>> Klidne > >>> bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat > >>> pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. > >>> Nasel > >>> jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi > >>> co > >>> napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem > >>> jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, > >>> hromadne to > >>> tam muzu dat vzdy.... > >>> > >>> http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy > >>> > >>> T > >>> > >>> Jiri Klement writes: > >>> > >>>> Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne > >>>> poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se > >>>> ke svemu vybranemu kousku dopise. > >>>> > >>>> Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla > >>>> pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval > >>>> kvuli testovani SemanticWiki. Login tam neni nutny. > >>>> > >>>> 2008/8/5 Michal Kovar <megabordel at seznam.cz>: > >>>>> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako > >>>>> redneck. Napraskat to na server tak jak to lezi a vcelky delnice si > >>>>> to pak > >>>>> rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) > >>>>> > >>>>>> Tomas Kolda napsal(a): > >>>>>>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM > >>>>>>> formatu. > >>>>>>> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? > >>>>>>> Zrusit > >>>>>>> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? > >>>>>>> Kazdy by > >>>>>>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat > >>>>>>> na > >>>>>>> 23), > >>>>>>> vycistit ho a pak uploadnout. > >>>>>>> > >>>>>>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi > >>>>>>> :) > >>>>>>> > >>>>>>> T > >>>>>>> > >>>>>>> hanoj writes: > >>>>>>> > >>>>>>> > >>>>>>>>> Opravdu? > >>>>>>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a > >>>>>>>>> vysledny dataset > >>>>>>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve > >>>>>>>>> wireframe modu, > >>>>>>>>> pocitac funel a funel a stale nebylo hotovo. > >>>>>>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak > >>>>>>>>> SimplePaintVisitor > >>>>>>>>> sestavuje jednu > >>>>>>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. > >>>>>>>>> > >>>>>>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale > >>>>>>>> trvaloto > >>>>>>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu > >>>>>>>> 7.10, java 1.5. > >>>>>>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. > >>>>>>>> > >>>>>>>> hanoj > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Talk-cz mailing list > >>>>>>>> Talk-cz at openstreetmap.org > >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Talk-cz mailing list > >>>>>>> Talk-cz at openstreetmap.org > >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Talk-cz mailing list > >>>>>> Talk-cz at openstreetmap.org > >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>> > >>>>>> __________ Informace od NOD32 3301 (20080727) __________ > >>>>>> > >>>>>> Tato zprava byla proverena antivirovym systemem NOD32. > >>>>>> http://www.nod32.cz > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > >>>>> > >>>>> _______________________________________________ > >>>>> Talk-cz mailing list > >>>>> Talk-cz at openstreetmap.org > >>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Talk-cz mailing list > >>>> Talk-cz at openstreetmap.org > >>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>> > >>> > >>> > >>> _______________________________________________ > >>> Talk-cz mailing list > >>> Talk-cz at openstreetmap.org > >>> http://lists.openstreetmap.org/listinfo/talk-cz > >> > >> > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz at openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > __________ Informace od NOD32 3301 (20080727) __________ > > > > Tato zprava byla proverena antivirovym systemem NOD32. > > http://www.nod32.cz > > > > > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
---- S pozdravem Mail: psbox at seznam.cz http://fatbozz.towerofglass.net

5.8.2008 09:33:07 (#92)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake problemy, ktere by se pozdeji hure resily. 2008/8/5 Michal Kovar <megabordel at seznam.cz>: zobrazit citaci
> Unika mi pointa tyhle "prenatalni" kontroly. K cemu to bude? Mista, ktera > lidi zajimaji, budou opravena. Mista, na ktere se*e pes muzou zustat tak > jak jsou. > > On Tue, 05 Aug 2008 20:16:54 +0200, Jiri Klement <jiri.klement at gmail.com> > wrote: > >> Me zase vychazi, ze vetsina lidi pise ze prvne zkontrolovat. Nebo >> muzeme udelat kompromis, oblasti co si nikdo nevezme za 2 tydny se pak >> nahraji bez kontroly. >> >> 2008/8/5 Tomas Kolda <kolda at web2net.cz>: >>> Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, >>> kdyz to >>> tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu >>> nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad >>> opravi... >>> >>> T >>> >>> Tomas Kolda writes: >>> >>>> Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. >>>> Klidne >>>> bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat >>>> pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. >>>> Nasel >>>> jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi >>>> co >>>> napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem >>>> jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, >>>> hromadne to >>>> tam muzu dat vzdy.... >>>> >>>> http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy >>>> >>>> T >>>> >>>> Jiri Klement writes: >>>> >>>>> Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne >>>>> poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se >>>>> ke svemu vybranemu kousku dopise. >>>>> >>>>> Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla >>>>> pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval >>>>> kvuli testovani SemanticWiki. Login tam neni nutny. >>>>> >>>>> 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >>>>>> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako >>>>>> redneck. Napraskat to na server tak jak to lezi a vcelky delnice si >>>>>> to pak >>>>>> rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) >>>>>> >>>>>>> Tomas Kolda napsal(a): >>>>>>>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >>>>>>>> formatu. >>>>>>>> Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? >>>>>>>> Zrusit >>>>>>>> zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? >>>>>>>> Kazdy by >>>>>>>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat >>>>>>>> na >>>>>>>> 23), >>>>>>>> vycistit ho a pak uploadnout. >>>>>>>> >>>>>>>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi >>>>>>>> :) >>>>>>>> >>>>>>>> T >>>>>>>> >>>>>>>> hanoj writes: >>>>>>>> >>>>>>>> >>>>>>>>>> Opravdu? >>>>>>>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>>>>>>>> vysledny dataset >>>>>>>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve >>>>>>>>>> wireframe modu, >>>>>>>>>> pocitac funel a funel a stale nebylo hotovo. >>>>>>>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak >>>>>>>>>> SimplePaintVisitor >>>>>>>>>> sestavuje jednu >>>>>>>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>>>>>>>>> >>>>>>>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale >>>>>>>>> trvaloto >>>>>>>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>>>>>>>> 7.10, java 1.5. >>>>>>>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>>>>>>>> >>>>>>>>> hanoj >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> __________ Informace od NOD32 3301 (20080727) __________ >>>>>>> >>>>>>> Tato zprava byla proverena antivirovym systemem NOD32. >>>>>>> http://www.nod32.cz >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> __________ Informace od NOD32 3301 (20080727) __________ >> >> Tato zprava byla proverena antivirovym systemem NOD32. >> http://www.nod32.cz >> >> > > > > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

5.8.2008 09:47:26 (#93)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Dopoustis se stejneho zlocinu, jako bys detem odlozil o den Vanoce :) On Tue, 05 Aug 2008 21:33:07 +0200, Jiri Klement <jiri.klement at gmail.com> wrote: zobrazit citaci
> Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi > chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz > to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal > alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake > problemy, ktere by se pozdeji hure resily. > > 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >> Unika mi pointa tyhle "prenatalni" kontroly. K cemu to bude? Mista, >> ktera >> lidi zajimaji, budou opravena. Mista, na ktere se*e pes muzou zustat tak >> jak jsou. >> >> On Tue, 05 Aug 2008 20:16:54 +0200, Jiri Klement >> <jiri.klement at gmail.com> >> wrote: >> >>> Me zase vychazi, ze vetsina lidi pise ze prvne zkontrolovat. Nebo >>> muzeme udelat kompromis, oblasti co si nikdo nevezme za 2 tydny se pak >>> nahraji bez kontroly. >>> >>> 2008/8/5 Tomas Kolda <kolda at web2net.cz>: >>>> Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, >>>> kdyz to >>>> tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu >>>> nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad >>>> opravi... >>>> >>>> T >>>> >>>> Tomas Kolda writes: >>>> >>>>> Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. >>>>> Klidne >>>>> bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat >>>>> pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. >>>>> Nasel >>>>> jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo >>>>> vi >>>>> co >>>>> napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude >>>>> mnohem >>>>> jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, >>>>> hromadne to >>>>> tam muzu dat vzdy.... >>>>> >>>>> http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy >>>>> >>>>> T >>>>> >>>>> Jiri Klement writes: >>>>> >>>>>> Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne >>>>>> poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se >>>>>> ke svemu vybranemu kousku dopise. >>>>>> >>>>>> Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla >>>>>> pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera >>>>>> naistaloval >>>>>> kvuli testovani SemanticWiki. Login tam neni nutny. >>>>>> >>>>>> 2008/8/5 Michal Kovar <megabordel at seznam.cz>: >>>>>>> Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil >>>>>>> jako >>>>>>> redneck. Napraskat to na server tak jak to lezi a vcelky delnice si >>>>>>> to pak >>>>>>> rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) >>>>>>> >>>>>>>> Tomas Kolda napsal(a): >>>>>>>>> Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM >>>>>>>>> formatu. >>>>>>>>> Nechceme pred tim nez se vse posle do OSM soubory rucne >>>>>>>>> poopravit? >>>>>>>>> Zrusit >>>>>>>>> zbytecne cesticky v lesich nebo naopak hodne viditelne >>>>>>>>> osklivosti? >>>>>>>>> Kazdy by >>>>>>>>> si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina >>>>>>>>> delat >>>>>>>>> na >>>>>>>>> 23), >>>>>>>>> vycistit ho a pak uploadnout. >>>>>>>>> >>>>>>>>> Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na >>>>>>>>> odpovedi >>>>>>>>> :) >>>>>>>>> >>>>>>>>> T >>>>>>>>> >>>>>>>>> hanoj writes: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Opravdu? >>>>>>>>>>> Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a >>>>>>>>>>> vysledny dataset >>>>>>>>>>> zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani >>>>>>>>>>> ve >>>>>>>>>>> wireframe modu, >>>>>>>>>>> pocitac funel a funel a stale nebylo hotovo. >>>>>>>>>>> Dle stacktrace byl asi nejvetsi problem v tom, jak >>>>>>>>>>> SimplePaintVisitor >>>>>>>>>>> sestavuje jednu >>>>>>>>>>> velikou Path2D. MapPaint to same, vyrenderovani jsem se >>>>>>>>>>> nedockal. >>>>>>>>>>> >>>>>>>>>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale >>>>>>>>>> trvaloto >>>>>>>>>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, >>>>>>>>>> Ubutnu >>>>>>>>>> 7.10, java 1.5. >>>>>>>>>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >>>>>>>>>> >>>>>>>>>> hanoj >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz at openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz at openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>>> __________ Informace od NOD32 3301 (20080727) __________ >>>>>>>> >>>>>>>> Tato zprava byla proverena antivirovym systemem NOD32. >>>>>>>> http://www.nod32.cz >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Using Opera's revolutionary e-mail client: >>>>>>> http://www.opera.com/mail/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> __________ Informace od NOD32 3301 (20080727) __________ >>> >>> Tato zprava byla proverena antivirovym systemem NOD32. >>> http://www.nod32.cz >>> >>> >> >> >> >> -- >> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > __________ Informace od NOD32 3301 (20080727) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

5.8.2008 09:48:59 (#94)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi > chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz > to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal > alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake > problemy, ktere by se pozdeji hure resily.
No, co jsem na to koukal tak upload samotny bude trvat vyrazne vic nez den. Urcite by bylo dobry nekam dat .tar.bz2 s tim co se bude uploadovat, a prvni uploadovat nejaky frekventovany misto a zkouknout... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 09:53:58 (#95)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> > No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani > > JOSM-ng v jaru? > http://shell.sh.cvut.cz/~nenik/josmng.html > Ted jsem to zkousel a je tam jeste ten styl, co "doprostred" lesniho polygonu > namaluje stromecek, coz ted pri pohledu na CR vypada vskutku > > zabavne...
Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl uzitecny, javu v browseru rozjetou nemam :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 09:54:23 (#96)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Tue 2008-08-05 13:03:30, hanoj wrote: zobrazit citaci
> > Opravdu? > > Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset > > zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, > > pocitac funel a funel a stale nebylo hotovo. > > Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu > > velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. > *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto > asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu > 7.10, java 1.5. > *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka.
Urcite mam jinou versi josm, a urcite nemam mappaint. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 10:11:36 (#97)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Tue 2008-08-05 21:53:58, Pavel Machek wrote: zobrazit citaci
> Ahoj! > > > > No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani > > > JOSM-ng v jaru? > > http://shell.sh.cvut.cz/~nenik/josmng.html > > Ted jsem to zkousel a je tam jeste ten styl, co "doprostred" lesniho polygonu > > namaluje stromecek, coz ted pri pohledu na CR vypada vskutku > > > zabavne... > > Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl > uzitecny, javu v browseru rozjetou nemam :-(.
...jinak pouzivat alt-clicky neni na linuxu mozny, zere je window manager :-(. Jinak je to znatellne rychlejsi nez josm, a kresli to hezky... pekne. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 10:14:53 (#98)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Tue 2008-08-05 21:53:58, Pavel Machek wrote: zobrazit citaci
> Ahoj! > > > > No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani > > > JOSM-ng v jaru? > > http://shell.sh.cvut.cz/~nenik/josmng.html > > Ted jsem to zkousel a je tam jeste ten styl, co "doprostred" lesniho polygonu > > namaluje stromecek, coz ted pri pohledu na CR vypada vskutku > > > zabavne... > > Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl > uzitecny, javu v browseru rozjetou nemam :-(.
Odpovim si sam: http://shell.sh.cvut.cz/~nenik/josm-ng.jar ...a zda se ze na linuxu bezi. Mozna bych od nejakeho zoomu schoval ikonky lesu a parkovist... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 10:25:16 (#99)
gravatar

Michal Kovar

<megabordel at seznam.cz>
90
Jo, kresli to moc hezky On Tue, 05 Aug 2008 22:14:53 +0200, Pavel Machek <pavel at suse.cz> wrote: zobrazit citaci
> On Tue 2008-08-05 21:53:58, Pavel Machek wrote: >> Ahoj! >> >> > > No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani >> > > JOSM-ng v jaru? >> > http://shell.sh.cvut.cz/~nenik/josmng.html >> > Ted jsem to zkousel a je tam jeste ten styl, co "doprostred" lesniho >> polygonu >> > namaluje stromecek, coz ted pri pohledu na CR vypada vskutku >> > > zabavne... >> >> Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl >> uzitecny, javu v browseru rozjetou nemam :-(. > > Odpovim si sam: > > http://shell.sh.cvut.cz/~nenik/josm-ng.jar > > ...a zda se ze na linuxu bezi. Mozna bych od nejakeho zoomu schoval > ikonky lesu a parkovist... > > Pavel >
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

5.8.2008 10:29:16 (#100)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
zobrazit citaci
> Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl > uzitecny, javu v browseru rozjetou nemam :-(.
Na Java Web Start javu v browseru nepotrebujes, staci mit asociovanou priponu jnlp s programem javaws.

5.8.2008 11:29:37 (#101)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Ahoj, takze soubory ke koukani/uploadovani jsou: http://www.web2net.cz/osm/lesy_001.osm.bz2 az 033 Dale jsem zkusil uploadnout 001 (takze ten uz v OSM je). Trvalo to asi 3 hodiny. Napadlo me totiz, ze send je vetsina casu. Pote staci z JOSMu ulozit uz aktualizovana IDcka a muze se v pohode editovat bez stahovani dat (vyzkousel jsem). Takze ten kdo uploadne a nechce se mu editovat chyby nejblizsi dobe, tak by mel ulozit aktualni IDcka a poskytnout je k editaci, aby se jednoduseji ihned opravovalo. Asi to jde nejak vypreparovat z planet.osm, ale to ja nevim jak. Tohle jsou krom toho pouze tyto nove lesy. Muj (jiz neaktualni) send je. lesy_001_send.osm.bz2 Jestli Vas napada lepsi zpusob sem s nim... Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi maximum). T Pavel Machek writes: zobrazit citaci
> Ahoj! > >> Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi >> chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz >> to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal >> alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake >> problemy, ktere by se pozdeji hure resily. > > No, co jsem na to koukal tak upload samotny bude trvat vyrazne vic nez > den. > > Urcite by bylo dobry nekam dat .tar.bz2 s tim co se bude uploadovat, a > prvni uploadovat nejaky frekventovany misto a zkouknout... > Pavel > > -- > (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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

5.8.2008 11:48:06 (#102)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Pavel Machek napsal(a): zobrazit citaci
> On Tue 2008-08-05 21:53:58, Pavel Machek wrote: >> Ahoj! >> >>>> No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani >>>> JOSM-ng v jaru? >>> http://shell.sh.cvut.cz/~nenik/josmng.html >>> Ted jsem to zkousel a je tam jeste ten styl, co "doprostred" lesniho polygonu >>> namaluje stromecek, coz ted pri pohledu na CR vypada vskutku >>>> zabavne... >> Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl >> uzitecny, javu v browseru rozjetou nemam :-(. > > ...jinak pouzivat alt-clicky neni na linuxu mozny, zere je window > manager :-(.
MUJ fvwm2 je nezere. OK, point taken, nicmene pouzitelne modifikatory a klavesove zkratky na linuxu jsou pole znacne zaminovane, budu si na to muset dat pozor. Zvlaste proto, ze ani na linuxaka nejsem reprezentativni vzorek. Tak jako tak chci to malovani nodu predelat, drzet pul hodiny Alt pri oklikavani Lipna je kravina, ze? Prvni node nejakym gestem, pak skryty mod jinak modeless UI az do Esc by mohlo byt pruchodne, ale jak uz tu zaznelo, rad bych se napred podival na "opravdovy" GIS. zobrazit citaci
> Jinak je to znatellne rychlejsi nez josm, a kresli to > hezky... pekne.
Dik. A to uz ted (lokalne) umim i tu tramvaj pres residential, k tomu sipecky v jednosmerkach a jeste stylovatelne malovani pro ruzne zoomy. Jo a ta vystavena verze jeste neumela multipolygony... http://shell.sh.cvut.cz/~nenik/josmng-multistyle.png zobrazit citaci
> Mozna bych od nejakeho zoomu schoval ikonky lesu a parkovist...
... viz vyse. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

5.8.2008 11:56:02 (#103)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> takze soubory ke koukani/uploadovani jsou: > > http://www.web2net.cz/osm/lesy_001.osm.bz2 az 033 > > Dale jsem zkusil uploadnout 001 (takze ten uz v OSM je). Trvalo to asi 3 > hodiny. Napadlo me totiz, ze send je vetsina casu. Pote staci z JOSMu ulozit > uz aktualizovana IDcka a muze se v pohode editovat bez stahovani dat > (vyzkousel jsem). Takze ten kdo uploadne a nechce se mu editovat chyby > nejblizsi dobe, tak by mel ulozit aktualni IDcka a poskytnout je k > editaci,
zobrazit citaci
> aby se jednoduseji ihned opravovalo. Asi to jde nejak vypreparovat z > planet.osm, ale to ja nevim jak.
Nebo uplne normalne stahnout ze serveru, ne? Stahovani je normalne dost rychly... zobrazit citaci
> Muj (jiz neaktualni) send je. > > lesy_001_send.osm.bz2 > > Jestli Vas napada lepsi zpusob sem s nim... > > Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na > dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo > rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi > maximum).
No... ono se to da ladovat rychleji i z jednoho pocitace, staci pustit vickrat josm. (Je to limitovany latenci, ne bandwidth). Ale jestli je zajem, muzu pustit upload i u sebe, staci rict ktery cisla mam uploadnout... Pres noc to neni problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

5.8.2008 11:56:56 (#104)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na > dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo > rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi > maximum).
Vice lidi laduje rychleji, uz jenom proto, ze si pro sebe utrhnou vetsi cast (vic kousku) sdileneho zdroje (OSM databaze), ale take proto, ze kazdy ma cas jine 3 hodiny ;-) Beru si za ukol 015 a cpu to tam... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

6.8.2008 12:14:03 (#105)
gravatar

noone02

<noone02 at centrum.cz>
28
Petr Nejedly napsal(a): zobrazit citaci
> Tomas Kolda napsal(a): > >> Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na >> dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo >> rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi >> maximum). >> > > Vice lidi laduje rychleji, uz jenom proto, ze si pro sebe utrhnou vetsi cast > (vic kousku) sdileneho zdroje (OSM databaze), ale take proto, ze kazdy ma cas > jine 3 hodiny ;-) > Beru si za ukol 015 a cpu to tam... > > >
Pekna prace , beru si na upload dily 006, 007. Diky

6.8.2008 12:31:41 (#106)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! Ok, 001 uz tam je... zobrazit citaci
> > Beru si za ukol 015 a cpu to tam...
zobrazit citaci
> Pekna prace , beru si na upload dily 006, 007. Diky
...a ja si vemu 003. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

6.8.2008 12:47:02 (#107)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Wed 2008-08-06 00:31:41, Pavel Machek wrote: zobrazit citaci
> Ahoj! > > Ok, 001 uz tam je... > > > > Beru si za ukol 015 a cpu to tam... > > > Pekna prace , beru si na upload dily 006, 007. Diky > > ...a ja si vemu 003.
...a 004, 3KB/sec je na moji linku malo ;-). Diky! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

6.8.2008 01:18:21 (#108)
gravatar

noone02

<noone02 at centrum.cz>
28
zobrazit citaci
>> >> > Pekna prace , beru si na upload dily 006, 007. Diky >
007 stale bezi (drive 60kb/s, nyni pomalu),pri uploadu 006 mi vyhodil JOSM chybu: java.lang.RuntimeException: 500 Internal Server Error jak "pokracovat" dal ?

6.8.2008 04:14:59 (#109)
gravatar

noone02

<noone02 at centrum.cz>
28
noone02 napsal(a): zobrazit citaci
>>> >>> >>> >> Pekna prace , beru si na upload dily 006, 007. Diky >> >> > 007 stale bezi (drive 60kb/s, nyni pomalu),pri uploadu 006 mi vyhodil > JOSM chybu: > java.lang.RuntimeException: 500 Internal Server Error > jak "pokracovat" dal ? > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
Myslim ze vsechno OK, preruseny upload neposila jiz poslana data (tzn. JOSM si pamatuje co uz poslal)

6.8.2008 04:19:14 (#110)
gravatar

noone02

<noone02 at centrum.cz>
28
zobrazit citaci
>> Ahoj! >> >> Ok, 001 uz tam je... >> >> >>>> Beru si za ukol 015 a cpu to tam... >>>> >>> Pekna prace , beru si na upload dily 006, 007. Diky >>> >> ...a ja si vemu 003. >> > > ...a 004, 3KB/sec je na moji linku malo ;-). Diky! > Pavel >
Posilam 008

6.8.2008 09:22:28 (#111)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Uploaduji kus 32. Pro rekapitulaci by bylo dobre do kazdeho "rezervacniho mailu" napsat jiz vsechny poslane kusy. Proto: uz tam jsou: 001,003,004,006,007,008,015 a 032 K Tomas Kolda napsal(a): zobrazit citaci
> Ahoj, > > takze soubory ke koukani/uploadovani jsou: > > http://www.web2net.cz/osm/lesy_001.osm.bz2 az 033 > > Dale jsem zkusil uploadnout 001 (takze ten uz v OSM je). Trvalo to asi 3 > hodiny. Napadlo me totiz, ze send je vetsina casu. Pote staci z JOSMu ulozit > uz aktualizovana IDcka a muze se v pohode editovat bez stahovani dat > (vyzkousel jsem). Takze ten kdo uploadne a nechce se mu editovat chyby > nejblizsi dobe, tak by mel ulozit aktualni IDcka a poskytnout je k editaci, > aby se jednoduseji ihned opravovalo. Asi to jde nejak vypreparovat z > planet.osm, ale to ja nevim jak. Tohle jsou krom toho pouze tyto nove lesy. > Muj (jiz neaktualni) send je. > > lesy_001_send.osm.bz2 > > Jestli Vas napada lepsi zpusob sem s nim... > > Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na > dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo > rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi > maximum). > > T > > Pavel Machek writes: > > >> Ahoj! >> >> >>> Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi >>> chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz >>> to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal >>> alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake >>> problemy, ktere by se pozdeji hure resily. >>> >> No, co jsem na to koukal tak upload samotny bude trvat vyrazne vic nez >> den. >> >> Urcite by bylo dobry nekam dat .tar.bz2 s tim co se bude uploadovat, a >> prvni uploadovat nejaky frekventovany misto a zkouknout... >> Pavel >> >> -- >> (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 at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 09:34:17 (#112)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
Tak ja se pripojim kouskem 016 uz tam jsou: 001,003,004,006,007,008,015,016 a 032 2008/8/6 Kubajz <kubajz at kbx.cz>: zobrazit citaci
> Uploaduji kus 32. Pro rekapitulaci by bylo dobre do kazdeho > "rezervacniho mailu" napsat jiz vsechny poslane kusy. Proto: > > uz tam jsou: 001,003,004,006,007,008,015 a 032 > > K > > Tomas Kolda napsal(a): >> Ahoj, >> >> takze soubory ke koukani/uploadovani jsou: >> >> http://www.web2net.cz/osm/lesy_001.osm.bz2 az 033 >> >> Dale jsem zkusil uploadnout 001 (takze ten uz v OSM je). Trvalo to asi 3 >> hodiny. Napadlo me totiz, ze send je vetsina casu. Pote staci z JOSMu ulozit >> uz aktualizovana IDcka a muze se v pohode editovat bez stahovani dat >> (vyzkousel jsem). Takze ten kdo uploadne a nechce se mu editovat chyby >> nejblizsi dobe, tak by mel ulozit aktualni IDcka a poskytnout je k editaci, >> aby se jednoduseji ihned opravovalo. Asi to jde nejak vypreparovat z >> planet.osm, ale to ja nevim jak. Tohle jsou krom toho pouze tyto nove lesy. >> Muj (jiz neaktualni) send je. >> >> lesy_001_send.osm.bz2 >> >> Jestli Vas napada lepsi zpusob sem s nim... >> >> Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na >> dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo >> rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi >> maximum). >> >> T >> >> Pavel Machek writes: >> >> >>> Ahoj! >>> >>> >>>> Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi >>>> chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz >>>> to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal >>>> alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake >>>> problemy, ktere by se pozdeji hure resily. >>>> >>> No, co jsem na to koukal tak upload samotny bude trvat vyrazne vic nez >>> den. >>> >>> Urcite by bylo dobry nekam dat .tar.bz2 s tim co se bude uploadovat, a >>> prvni uploadovat nejaky frekventovany misto a zkouknout... >>> Pavel >>> >>> -- >>> (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 at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 09:39:08 (#113)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2008/8/6 Kubajz <kubajz at kbx.cz>: zobrazit citaci
> Uploaduji kus 32. Pro rekapitulaci by bylo dobre do kazdeho > "rezervacniho mailu" napsat jiz vsechny poslane kusy. Proto: > > uz tam jsou: 001,003,004,006,007,008,015 a 032 > > K >
uz tam jsou: 001,003,004,006,007,008,015,016 a 032 uploaduju 20 -- Michal Gr?zl http://walley.org

6.8.2008 10:11:00 (#114)
gravatar

Pavel Machek

<pavel at ucw.cz>
1023 1226
zobrazit citaci
> 2008/8/6 Kubajz <kubajz at kbx.cz>: > > Uploaduji kus 32. Pro rekapitulaci by bylo dobre do kazdeho > > "rezervacniho mailu" napsat jiz vsechny poslane kusy. Proto: > > > > uz tam jsou: 001,003,004,006,007,008,015 a 032 > > > > K > > > uz tam jsou: 001,003,004,006,007,008,015,016 a 032 > > uploaduju 20
Rezervujte mi 2 a 5. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

6.8.2008 10:11:28 (#115)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
Ja uploadnu 33 zobrazit citaci
> > uz tam jsou: 001,003,004,006,007,008,015 a 032 > > > > K > > > uz tam jsou: 001,003,004,006,007,008,015,016 a 032 > > uploaduju 20 > -- > Michal Gr?zl > http://walley.org > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
---- S pozdravem Mail: psbox at seznam.cz http://fatbozz.towerofglass.net

6.8.2008 10:28:02 (#116)
gravatar

Pavel Machek

<pavel at ucw.cz>
1023 1226
zobrazit citaci
> Ja uploadnu 33 > > > > uz tam jsou: 001,003,004,006,007,008,015 a 032 > > > > > > K > > > > > uz tam jsou: 001,003,004,006,007,008,015,016 a 032 > > > > uploaduju 20
Tak to mame 1-8, 15-16, 20, 32-33. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

6.8.2008 10:37:14 (#117)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
Tu u? uploaduju j? zobrazit citaci
> ------------ P?1vodn? zpr?va ------------ > Od: Pavel Machek <pavel at ucw.cz> > P?edm?t: Re: [Talk-cz] pokusny import lesu > Datum: 06.8.2008 10:28:07 > ---------------------------------------- > > Ja uploadnu 33 > > > > > > uz tam jsou: 001,003,004,006,007,008,015 a 032 > > > > > > > > K > > > > > > > uz tam jsou: 001,003,004,006,007,008,015,016 a 032 > > > > > > uploaduju 20 > > Tak to mame > > 1-8, 15-16, 20, 32-33. > Pavel > -- > (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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
---- S pozdravem Mail: psbox at seznam.cz http://fatbozz.towerofglass.net

6.8.2008 11:30:04 (#118)
gravatar

hanoj

<ehanoj at gmail.com>
713
Dne 5. srpen 2008 21:54 Pavel Machek <pavel at suse.cz> napsal(a): zobrazit citaci
> On Tue 2008-08-05 13:03:30, hanoj wrote: >> > Opravdu? >> > Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset >> > zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, >> > pocitac funel a funel a stale nebylo hotovo. >> > Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu >> > velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >> 7.10, java 1.5. >> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. > > Urcite mam jinou versi josm, a urcite nemam mappaint.
*** od blizke API 0.6 si budes muset tu novou verzi stahnout. taktedy na tom budes stejne ;) hanoj

6.8.2008 11:49:30 (#119)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
API 0.6 asi neni az tak blizko. Jeden a pul mesice na nem nikdo nepracoval. 2008/8/6 hanoj <ehanoj at gmail.com>: zobrazit citaci
> Dne 5. srpen 2008 21:54 Pavel Machek <pavel at suse.cz> napsal(a): >> On Tue 2008-08-05 13:03:30, hanoj wrote: >>> > Opravdu? >>> > Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset >>> > zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, >>> > pocitac funel a funel a stale nebylo hotovo. >>> > Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu >>> > velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. >>> *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto >>> asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu >>> 7.10, java 1.5. >>> *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. >> >> Urcite mam jinou versi josm, a urcite nemam mappaint. > *** od blizke API 0.6 si budes muset tu novou verzi stahnout. taktedy > na tom budes stejne ;) > > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 12:00:24 (#120)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
Tak to mame 1-8, 15-16, 20, 32-33. nekdo psal nekde o 17 tak ja bych uploadnul jeste 18 a 19 -- Michal Gr?zl http://walley.org

6.8.2008 12:19:15 (#121)
gravatar

Marek Musil

<wopixe at volny.cz>
18
Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Mara Michal Gr?zl napsal(a): zobrazit citaci
> Tak to mame > > 1-8, 15-16, 20, 32-33. > nekdo psal nekde o 17 > tak ja bych uploadnul jeste 18 a 19 > > >

6.8.2008 12:32:37 (#122)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
Dovolil bych si vzit DVE a to 11 a 12 a zprehlednit tabulku :) 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 14 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 22 23 24 25 26 27 28 29 30 31 32 UPLOADED 33 UPLOADED zobrazit citaci
> ------------ P?vodn? zpr?va ------------ > Od: Marek Musil <wopixe at volny.cz> > P?edm?t: Re: [Talk-cz] pokusny import lesu > Datum: 06.8.2008 12:19:25 > ---------------------------------------- > Pridam se a beru si 009 a 010 > > Tedy obsazene jsou: > > 1-10, 15-20, 32-33 > > > Mara > > > Michal Gr?zl napsal(a): > > Tak to mame > > > > 1-8, 15-16, 20, 32-33. > > nekdo psal nekde o 17 > > tak ja bych uploadnul jeste 18 a 19 > > > > > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
---- S pozdravem Mail: psbox at seznam.cz http://fatbozz.towerofglass.net

6.8.2008 12:40:15 (#123)
gravatar

noone02

<noone02 at centrum.cz>
28
Marek Musil napsal(a): zobrazit citaci
> Pridam se a beru si 009 a 010 > > Tedy obsazene jsou: > > 1-10, 15-20, 32-33 > >
Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033

6.8.2008 12:44:05 (#124)
gravatar

noone02

<noone02 at centrum.cz>
28
Petr Schonmann napsal(a): zobrazit citaci
> Dovolil bych si vzit DVE a to 11 a 12 a zprehlednit tabulku :) > > 1 UPLOADED > 2 UPLOADED > 3 UPLOADED > 4 UPLOADED > 5 UPLOADED > 6 UPLOADED > 7 UPLOADED > 8 UPLOADED > 9 UPLOADED > 10 UPLOADED > 11 UPLOADED > 12 UPLOADED > 13 UPLOADED > 14 UPLOADED > 15 UPLOADED > 16 UPLOADED > 17 UPLOADED > 18 UPLOADED > 19 UPLOADED > 20 UPLOADED > 21 > 22 > 23 > 24 > 25 > 26 > 27 > 28 > 29 > 30 > 31 > 32 UPLOADED > 33 UPLOADED > > > >> ------------ P?vodn? zpr?va ------------ >> Od: Marek Musil <wopixe at volny.cz> >> P?edm?t: Re: [Talk-cz] pokusny import lesu >> Datum: 06.8.2008 12:19:25 >> ---------------------------------------- >> Pridam se a beru si 009 a 010 >> >> Tedy obsazene jsou: >> >> 1-10, 15-20, 32-33 >> >> >> Mara >> >> >> Michal Gr?zl napsal(a): >> >>> Tak to mame >>> >>> 1-8, 15-16, 20, 32-33. >>> nekdo psal nekde o 17 >>> tak ja bych uploadnul jeste 18 a 19 >>> >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > ---- > S pozdravem > Mail: psbox at seznam.cz > http://fatbozz.towerofglass.net > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
Byl jsi rychlejsi, beru si tedy 13 a 14

6.8.2008 01:29:53 (#125)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 zobrazit citaci
> ------------ P?vodn? zpr?va ------------ > Od: noone02 <noone02 at centrum.cz> > P?edm?t: Re: [Talk-cz] pokusny import lesu > Datum: 06.8.2008 13:01:56 > ---------------------------------------- > Marek Musil napsal(a): > > Pridam se a beru si 009 a 010 > > > > Tedy obsazene jsou: > > > > 1-10, 15-20, 32-33 > > > > > > Beru si 011 a 012 > > Obsazene jsou 001-012, 015-020, 032-033 > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
---- S pozdravem Mail: psbox at seznam.cz http://fatbozz.towerofglass.net

6.8.2008 01:33:28 (#126)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
megabordel :) zobrazit citaci
> ------------ P?vodn? zpr?va ------------ > Od: Kubajz <kubajz at kbx.cz> > P?edm?t: Re: [Talk-cz] pokusny import lesu > Datum: 06.8.2008 13:32:36 > ---------------------------------------- > on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak > ty uz tam taky jsou. To je bordel... > > K > > Petr Schonmann napsal(a): > > vzdyt jsem si je bral ja... > > Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od > serveru ch 412 > > > > > >> ------------ P?vodn? zpr?va ------------ > >> Od: noone02 <noone02 at centrum.cz> > >> P?edm?t: Re: [Talk-cz] pokusny import lesu > >> Datum: 06.8.2008 13:01:56 > >> ---------------------------------------- > >> Marek Musil napsal(a): > >> > >>> Pridam se a beru si 009 a 010 > >>> > >>> Tedy obsazene jsou: > >>> > >>> 1-10, 15-20, 32-33 > >>> > >>> > >>> > >> Beru si 011 a 012 > >> > >> Obsazene jsou 001-012, 015-020, 032-033 > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz at openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > >> > >> > >> > > > > ---- > > S pozdravem > > Mail: psbox at seznam.cz > > http://fatbozz.towerofglass.net > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz at openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >
---- S pozdravem Mail: psbox at seznam.cz http://fatbozz.towerofglass.net

6.8.2008 01:35:39 (#127)
gravatar

Kubajz

<kubajz at kbx.cz>
614
on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak ty uz tam taky jsou. To je bordel... K Petr Schonmann napsal(a): zobrazit citaci
> vzdyt jsem si je bral ja... > Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 > > >> ------------ P?vodn? zpr?va ------------ >> Od: noone02 <noone02 at centrum.cz> >> P?edm?t: Re: [Talk-cz] pokusny import lesu >> Datum: 06.8.2008 13:01:56 >> ---------------------------------------- >> Marek Musil napsal(a): >> >>> Pridam se a beru si 009 a 010 >>> >>> Tedy obsazene jsou: >>> >>> 1-10, 15-20, 32-33 >>> >>> >>> >> Beru si 011 a 012 >> >> Obsazene jsou 001-012, 015-020, 032-033 >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > ---- > S pozdravem > Mail: psbox at seznam.cz > http://fatbozz.towerofglass.net > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 01:36:32 (#128)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
2008/8/6 Petr Schonmann <PSBOX at seznam.cz>: zobrazit citaci
> megabordel :) >
navic uplne celej zelenej, doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to pak po sobe muzete zase smazat kdyz to tam bude 2x;)) -- Michal Gr?zl http://walley.org

6.8.2008 01:42:45 (#129)
gravatar

noone02

<noone02 at centrum.cz>
28
Tabulku jsem upravil, protoze uploaduji 13 a 14 Kubajz napsal(a): zobrazit citaci
> on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak > ty uz tam taky jsou. To je bordel... > > K > > Petr Schonmann napsal(a): > >> vzdyt jsem si je bral ja... >> Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 >> >> >> >>> ------------ P?vodn? zpr?va ------------ >>> Od: noone02 <noone02 at centrum.cz> >>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>> Datum: 06.8.2008 13:01:56 >>> ---------------------------------------- >>> Marek Musil napsal(a): >>> >>> >>>> Pridam se a beru si 009 a 010 >>>> >>>> Tedy obsazene jsou: >>>> >>>> 1-10, 15-20, 32-33 >>>> >>>> >>>> >>>> >>> Beru si 011 a 012 >>> >>> Obsazene jsou 001-012, 015-020, 032-033 >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> >>> >> ---- >> S pozdravem >> Mail: psbox at seznam.cz >> http://fatbozz.towerofglass.net >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

6.8.2008 01:45:56 (#130)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Abych se vyhl sprostemu slovu, pouziji terminus technicus - zvysim entropii a obsazuji v tabulce dalsi - tentokrat 31 :) 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 22 23 24 25 26 27 28 29 30 31 UPLOADED 32 UPLOADED 33 UPLOADED Petr Schonmann napsal(a): zobrazit citaci
> megabordel :) > > >> ------------ P?vodn? zpr?va ------------ >> Od: Kubajz <kubajz at kbx.cz> >> P?edm?t: Re: [Talk-cz] pokusny import lesu >> Datum: 06.8.2008 13:32:36 >> ---------------------------------------- >> on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak >> ty uz tam taky jsou. To je bordel... >> >> K >> >> Petr Schonmann napsal(a): >> >>> vzdyt jsem si je bral ja... >>> Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od >>> >> serveru ch 412 >> >>> >>> >>>> ------------ P?vodn? zpr?va ------------ >>>> Od: noone02 <noone02 at centrum.cz> >>>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>>> Datum: 06.8.2008 13:01:56 >>>> ---------------------------------------- >>>> Marek Musil napsal(a): >>>> >>>> >>>>> Pridam se a beru si 009 a 010 >>>>> >>>>> Tedy obsazene jsou: >>>>> >>>>> 1-10, 15-20, 32-33 >>>>> >>>>> >>>>> >>>>> >>>> Beru si 011 a 012 >>>> >>>> Obsazene jsou 001-012, 015-020, 032-033 >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> >>>> >>> ---- >>> S pozdravem >>> Mail: psbox at seznam.cz >>> http://fatbozz.towerofglass.net >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > ---- > S pozdravem > Mail: psbox at seznam.cz > http://fatbozz.towerofglass.net > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 01:48:12 (#131)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ja jsem to zpetne zjistil. Ono neni fer upravovat citovanou cast dopisu - pro me to vypadalo, ze to tam napsal uz Petr Schonmann. Analyzou jeho prispevku jsem pak dorbny rozdil zjistil a uz jsem v klidu. K noone02 napsal(a): zobrazit citaci
> Tabulku jsem upravil, protoze uploaduji 13 a 14 > > Kubajz napsal(a): > >> on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak >> ty uz tam taky jsou. To je bordel... >> >> K >> >> Petr Schonmann napsal(a): >> >> >>> vzdyt jsem si je bral ja... >>> Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 >>> >>> >>> >>> >>>> ------------ P?vodn? zpr?va ------------ >>>> Od: noone02 <noone02 at centrum.cz> >>>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>>> Datum: 06.8.2008 13:01:56 >>>> ---------------------------------------- >>>> Marek Musil napsal(a): >>>> >>>> >>>> >>>>> Pridam se a beru si 009 a 010 >>>>> >>>>> Tedy obsazene jsou: >>>>> >>>>> 1-10, 15-20, 32-33 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> Beru si 011 a 012 >>>> >>>> Obsazene jsou 001-012, 015-020, 032-033 >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> >>>> >>>> >>> ---- >>> S pozdravem >>> Mail: psbox at seznam.cz >>> http://fatbozz.towerofglass.net >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 01:49:08 (#132)
gravatar

Pavel Machek

<pavel at ucw.cz>
1023 1226
Ahoj! zobrazit citaci
> > megabordel :) > > > navic uplne celej zelenej, > doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to > pak po sobe muzete zase smazat kdyz to tam bude 2x;))
No, mel jsem tady neprijemny crash masiny :-(. Takze tam par nodu bude 2x. Doufam ze to chytne nejakej lint... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

6.8.2008 01:54:07 (#133)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Validator v JOSM to najde a umi i opravit... K Pavel Machek napsal(a): zobrazit citaci
> Ahoj! > > >>> megabordel :) >>> >>> >> navic uplne celej zelenej, >> doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to >> pak po sobe muzete zase smazat kdyz to tam bude 2x;)) >> > > No, mel jsem tady neprijemny crash masiny :-(. Takze tam par nodu bude > 2x. Doufam ze to chytne nejakej lint... > > Pavel >

6.8.2008 04:09:19 (#134)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
Tak jsem douplodoval, takze si beru dalsi dve 21, 22 Aktualni stav je tedy doufam tento: 001-022, 031-033 2008/8/6 Kubajz <kubajz at kbx.cz>: zobrazit citaci
> Validator v JOSM to najde a umi i opravit... > > K > > Pavel Machek napsal(a): >> Ahoj! >> >> >>>> megabordel :) >>>> >>>> >>> navic uplne celej zelenej, >>> doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to >>> pak po sobe muzete zase smazat kdyz to tam bude 2x;)) >>> >> >> No, mel jsem tady neprijemny crash masiny :-(. Takze tam par nodu bude >> 2x. Doufam ze to chytne nejakej lint... >> >> Pavel >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 05:44:38 (#135)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Beru 30, takze: 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 26 27 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED Kubajz napsal(a): zobrazit citaci
> Abych se vyhl sprostemu slovu, pouziji terminus technicus - zvysim > entropii a obsazuji v tabulce dalsi - tentokrat 31 :) > > 1 UPLOADED > 2 UPLOADED > 3 UPLOADED > 4 UPLOADED > 5 UPLOADED > 6 UPLOADED > 7 UPLOADED > 8 UPLOADED > 9 UPLOADED > 10 UPLOADED > 11 UPLOADED > 12 UPLOADED > 13 UPLOADED > 14 UPLOADED > 15 UPLOADED > 16 UPLOADED > 17 UPLOADED > 18 UPLOADED > 19 UPLOADED > 20 UPLOADED > 21 > 22 > 23 > 24 > 25 > 26 > 27 > 28 > 29 > 30 > 31 UPLOADED > 32 UPLOADED > 33 UPLOADED > > > Petr Schonmann napsal(a): > >> megabordel :) >> >> >> >>> ------------ P?vodn? zpr?va ------------ >>> Od: Kubajz <kubajz at kbx.cz> >>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>> Datum: 06.8.2008 13:32:36 >>> ---------------------------------------- >>> on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak >>> ty uz tam taky jsou. To je bordel... >>> >>> K >>> >>> Petr Schonmann napsal(a): >>> >>> >>>> vzdyt jsem si je bral ja... >>>> Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od >>>> >>>> >>> serveru ch 412 >>> >>> >>>> >>>> >>>> >>>>> ------------ P?vodn? zpr?va ------------ >>>>> Od: noone02 <noone02 at centrum.cz> >>>>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>>>> Datum: 06.8.2008 13:01:56 >>>>> ---------------------------------------- >>>>> Marek Musil napsal(a): >>>>> >>>>> >>>>> >>>>>> Pridam se a beru si 009 a 010 >>>>>> >>>>>> Tedy obsazene jsou: >>>>>> >>>>>> 1-10, 15-20, 32-33 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Beru si 011 a 012 >>>>> >>>>> Obsazene jsou 001-012, 015-020, 032-033 >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ---- >>>> S pozdravem >>>> Mail: psbox at seznam.cz >>>> http://fatbozz.towerofglass.net >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> >>> >> ---- >> S pozdravem >> Mail: psbox at seznam.cz >> http://fatbozz.towerofglass.net >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 05:58:39 (#136)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
Tak uz se zacinaji objevovat vyrenderovana data. Treba tady: http://www.openstreetmap.org/?lat=49.7497&lon=16.2061&zoom=12&layers=0B0FTF 2008/8/6 Kubajz <kubajz at kbx.cz>: zobrazit citaci
> Beru 30, takze: > > 1 UPLOADED > 2 UPLOADED > 3 UPLOADED > 4 UPLOADED > 5 UPLOADED > 6 UPLOADED > 7 UPLOADED > 8 UPLOADED > 9 UPLOADED > 10 UPLOADED > 11 UPLOADED > 12 UPLOADED > 13 UPLOADED > 14 UPLOADED > 15 UPLOADED > 16 UPLOADED > 17 UPLOADED > 18 UPLOADED > 19 UPLOADED > 20 UPLOADED > 21 UPLOADED > 22 UPLOADED > 23 > 24 > 25 > 26 > 27 > 28 > 29 > 30 UPLOADED > 31 UPLOADED > 32 UPLOADED > 33 UPLOADED > > > > Kubajz napsal(a): >> Abych se vyhl sprostemu slovu, pouziji terminus technicus - zvysim >> entropii a obsazuji v tabulce dalsi - tentokrat 31 :) >> >> 1 UPLOADED >> 2 UPLOADED >> 3 UPLOADED >> 4 UPLOADED >> 5 UPLOADED >> 6 UPLOADED >> 7 UPLOADED >> 8 UPLOADED >> 9 UPLOADED >> 10 UPLOADED >> 11 UPLOADED >> 12 UPLOADED >> 13 UPLOADED >> 14 UPLOADED >> 15 UPLOADED >> 16 UPLOADED >> 17 UPLOADED >> 18 UPLOADED >> 19 UPLOADED >> 20 UPLOADED >> 21 >> 22 >> 23 >> 24 >> 25 >> 26 >> 27 >> 28 >> 29 >> 30 >> 31 UPLOADED >> 32 UPLOADED >> 33 UPLOADED >> >> >> Petr Schonmann napsal(a): >> >>> megabordel :) >>> >>> >>> >>>> ------------ P?vodn? zpr?va ------------ >>>> Od: Kubajz <kubajz at kbx.cz> >>>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>>> Datum: 06.8.2008 13:32:36 >>>> ---------------------------------------- >>>> on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak >>>> ty uz tam taky jsou. To je bordel... >>>> >>>> K >>>> >>>> Petr Schonmann napsal(a): >>>> >>>> >>>>> vzdyt jsem si je bral ja... >>>>> Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od >>>>> >>>>> >>>> serveru ch 412 >>>> >>>> >>>>> >>>>> >>>>> >>>>>> ------------ P?vodn? zpr?va ------------ >>>>>> Od: noone02 <noone02 at centrum.cz> >>>>>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>>>>> Datum: 06.8.2008 13:01:56 >>>>>> ---------------------------------------- >>>>>> Marek Musil napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> Pridam se a beru si 009 a 010 >>>>>>> >>>>>>> Tedy obsazene jsou: >>>>>>> >>>>>>> 1-10, 15-20, 32-33 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Beru si 011 a 012 >>>>>> >>>>>> Obsazene jsou 001-012, 015-020, 032-033 >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ---- >>>>> S pozdravem >>>>> Mail: psbox at seznam.cz >>>>> http://fatbozz.towerofglass.net >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> >>>> >>> ---- >>> S pozdravem >>> Mail: psbox at seznam.cz >>> http://fatbozz.towerofglass.net >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 06:46:46 (#137)
gravatar

Kubajz

<kubajz at kbx.cz>
614
A nejen v Osmarenderu. Dokonce i v mapniku uz jsou asi dva pruhy pres CR: http://www.openstreetmap.org/?lat=49.955&lon=14.979&zoom=9&layers=B00FTF K Jiri Klement napsal(a): zobrazit citaci
> Tak uz se zacinaji objevovat vyrenderovana data. Treba tady: > http://www.openstreetmap.org/?lat=49.7497&lon=16.2061&zoom=12&layers=0B0FTF > > 2008/8/6 Kubajz <kubajz at kbx.cz>: > >> Beru 30, takze: >> >> 1 UPLOADED >> 2 UPLOADED >> 3 UPLOADED >> 4 UPLOADED >> 5 UPLOADED >> 6 UPLOADED >> 7 UPLOADED >> 8 UPLOADED >> 9 UPLOADED >> 10 UPLOADED >> 11 UPLOADED >> 12 UPLOADED >> 13 UPLOADED >> 14 UPLOADED >> 15 UPLOADED >> 16 UPLOADED >> 17 UPLOADED >> 18 UPLOADED >> 19 UPLOADED >> 20 UPLOADED >> 21 UPLOADED >> 22 UPLOADED >> 23 >> 24 >> 25 >> 26 >> 27 >> 28 >> 29 >> 30 UPLOADED >> 31 UPLOADED >> 32 UPLOADED >> 33 UPLOADED >> >> >> >> Kubajz napsal(a): >> >>> Abych se vyhl sprostemu slovu, pouziji terminus technicus - zvysim >>> entropii a obsazuji v tabulce dalsi - tentokrat 31 :) >>> >>> 1 UPLOADED >>> 2 UPLOADED >>> 3 UPLOADED >>> 4 UPLOADED >>> 5 UPLOADED >>> 6 UPLOADED >>> 7 UPLOADED >>> 8 UPLOADED >>> 9 UPLOADED >>> 10 UPLOADED >>> 11 UPLOADED >>> 12 UPLOADED >>> 13 UPLOADED >>> 14 UPLOADED >>> 15 UPLOADED >>> 16 UPLOADED >>> 17 UPLOADED >>> 18 UPLOADED >>> 19 UPLOADED >>> 20 UPLOADED >>> 21 >>> 22 >>> 23 >>> 24 >>> 25 >>> 26 >>> 27 >>> 28 >>> 29 >>> 30 >>> 31 UPLOADED >>> 32 UPLOADED >>> 33 UPLOADED >>> >>> >>> Petr Schonmann napsal(a): >>> >>> >>>> megabordel :) >>>> >>>> >>>> >>>> >>>>> ------------ P?vodn? zpr?va ------------ >>>>> Od: Kubajz <kubajz at kbx.cz> >>>>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>>>> Datum: 06.8.2008 13:32:36 >>>>> ---------------------------------------- >>>>> on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak >>>>> ty uz tam taky jsou. To je bordel... >>>>> >>>>> K >>>>> >>>>> Petr Schonmann napsal(a): >>>>> >>>>> >>>>> >>>>>> vzdyt jsem si je bral ja... >>>>>> Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od >>>>>> >>>>>> >>>>>> >>>>> serveru ch 412 >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> ------------ P?vodn? zpr?va ------------ >>>>>>> Od: noone02 <noone02 at centrum.cz> >>>>>>> P?edm?t: Re: [Talk-cz] pokusny import lesu >>>>>>> Datum: 06.8.2008 13:01:56 >>>>>>> ---------------------------------------- >>>>>>> Marek Musil napsal(a): >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Pridam se a beru si 009 a 010 >>>>>>>> >>>>>>>> Tedy obsazene jsou: >>>>>>>> >>>>>>>> 1-10, 15-20, 32-33 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Beru si 011 a 012 >>>>>>> >>>>>>> Obsazene jsou 001-012, 015-020, 032-033 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz at openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ---- >>>>>> S pozdravem >>>>>> Mail: psbox at seznam.cz >>>>>> http://fatbozz.towerofglass.net >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz at openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz at openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ---- >>>> S pozdravem >>>> Mail: psbox at seznam.cz >>>> http://fatbozz.towerofglass.net >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz at openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz at openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz at openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 07:09:06 (#138)
gravatar

Petr Schonmann

<PSBOX at seznam.cz>
96
Beru 23 a 24 Stav je tedy n?sleduj?c? link - http://www.web2net.cz/osm/lesy_001.osm.bz2 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 UPLOADED 24 UPLOADED 25 26 27 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED

6.8.2008 07:15:52 (#139)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ok, vemu 25-27... 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 UPLOADING 26 UPLOADING 27 UPLOADING 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

6.8.2008 07:23:40 (#140)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Radeji to upresnim podle konvence, co drzime od zacatku... Zbyvaji tedy posledni dve - 28 a 29. 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 UPLOADED 24 UPLOADED 25 UPLOADED 26 UPLOADED 27 UPLOADED 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED Pavel Machek napsal(a): zobrazit citaci
> Ok, vemu 25-27... > > 1 UPLOADED > 2 UPLOADED > 3 UPLOADED > 4 UPLOADED > 5 UPLOADED > 6 UPLOADED > 7 UPLOADED > 8 UPLOADED > 9 UPLOADED > 10 UPLOADED > 11 UPLOADED > 12 UPLOADED > 13 UPLOADED > 14 UPLOADED > 15 UPLOADED > 16 UPLOADED > 17 UPLOADED > 18 UPLOADED > 19 UPLOADED > 20 UPLOADED > 21 UPLOADED > 22 UPLOADED > 23 > 24 > 25 UPLOADING > 26 UPLOADING > 27 UPLOADING > 28 > 29 > 30 UPLOADED > 31 UPLOADED > 32 UPLOADED > 33 UPLOADED > >

6.8.2008 07:27:59 (#141)
gravatar

Pavel Machek

<pavel at ucw.cz>
1023 1226
Ok, vemu 25-27... 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 UPLOADING 26 UPLOADING 27 UPLOADING 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ----- End forwarded message ----- -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

6.8.2008 07:35:31 (#142)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29. Takze by mely byt vsechny casti rozebrany. On Wed, Aug 6, 2008 at 7:27 PM, Pavel Machek <pavel at ucw.cz> wrote: zobrazit citaci
> > Ok, vemu 25-27... > > 1 UPLOADED > 2 UPLOADED > 3 UPLOADED > 4 UPLOADED > 5 UPLOADED > 6 UPLOADED > 7 UPLOADED > 8 UPLOADED > 9 UPLOADED > 10 UPLOADED > 11 UPLOADED > 12 UPLOADED > 13 UPLOADED > 14 UPLOADED > 15 UPLOADED > 16 UPLOADED > 17 UPLOADED > 18 UPLOADED > 19 UPLOADED > 20 UPLOADED > 21 UPLOADED > 22 UPLOADED > 23 > 24 > 25 UPLOADING > 26 UPLOADING > 27 UPLOADING > 28 > 29 > 30 UPLOADED > 31 UPLOADED > 32 UPLOADED > 33 UPLOADED > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > ----- End forwarded message ----- > > -- > (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 at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

6.8.2008 11:12:49 (#143)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Jiri Klement napsal(a): zobrazit citaci
> Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29.
Vy jste teda rychlici. Jestlipak jste se na to po sobe aspon trochu podivali? Ja tu svoji 015 (co byla na serveru na to tata) stale jeste ucesavam... Mel jsem tam nejake prekryvy se stavajicimi lesy a taky rusim "diry na silnici", coz je v JOSM docela pakarna*. Take se nabizi uzasna moznost domalovat ty silnice, co v databazi chybi, ale je na ne "tunel" v lese - takovou silnici podle ortofoto nenamalujete. Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa? Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les sdilely nody.... *) sloucit dva polygony: - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way - bud domalovat dve propojovaci waye nebo zmergovat stycne body - join way - spojit dva vysledne skoropolygony - celou dobu davat pozor na relace Neumi to nekdo lepe? -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

7.8.2008 07:32:14 (#144)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Petr Nejedly writes: zobrazit citaci
> *) sloucit dva polygony: > - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way > - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way > - bud domalovat dve propojovaci waye nebo zmergovat stycne body > - join way - spojit dva vysledne skoropolygony > - celou dobu davat pozor na relace > Neumi to nekdo lepe?
Nepsal jste uz nekdo plugin do JOSM? Nebo pripadne nekoukal na API? Neprijde mi to jako slozita uloha, pokud je pristup k objektum. Stacilo by udelat nejaky tool... Me delali problem hlavne ty relace. JOSM je pri splitu kopiruje a pak si clovek musi davat pozor jak polygon rozdelil, aby nechal diry ve spravnych outer. Neumite v JOSMu schovat vse krome lesu?

7.8.2008 08:46:55 (#145)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ahoj, Petr Nejedly napsal(a): zobrazit citaci
> Jiri Klement napsal(a): > >> Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29. >> > > Vy jste teda rychlici. Jestlipak jste se na to po sobe aspon trochu podivali? >
Pred importem jsem vyhazoval cesty z lesu a jine podobne artefakty, co se mi nelibily. Potom odstranuji nektere prebytecne body. Prekvapilo me, ze algoritmus generalizace za sebou zanechal treba tri body v rozmezi 20m na uplne rovne care... zobrazit citaci
> Ja tu svoji 015 (co byla na serveru na to tata) stale jeste ucesavam... > > Mel jsem tam nejake prekryvy se stavajicimi lesy a taky rusim "diry na silnici", >
prekryvy se stavajicimi lesy jsou asi to nejhorsi. Vzhledem k nutnemu vypnuti mappaintu je v tech carach dost bordel... zobrazit citaci
> coz je v JOSM docela pakarna*. Take se nabizi uzasna moznost domalovat ty silnice, > co v databazi chybi, ale je na ne "tunel" v lese - takovou silnici podle ortofoto > nenamalujete. >
ja rusim akorat cesty v lese, pokud jsou v ramci jednoho lesa. Vic lesu dohromady nespojuji, protoze to je fakt desna pakarna. zobrazit citaci
> Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa? > Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les > sdilely nody.... > > > *) sloucit dva polygony: > - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way > - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way > - bud domalovat dve propojovaci waye nebo zmergovat stycne body > - join way - spojit dva vysledne skoropolygony > - celou dobu davat pozor na relace > Neumi to nekdo lepe? >
ja ne

7.8.2008 09:17:12 (#146)
gravatar

Pavel Machek

<pavel at ucw.cz>
1023 1226
zobrazit citaci
> Pavel Machek napsal(a): > > On Tue 2008-08-05 21:53:58, Pavel Machek wrote: > >> Ahoj! > >> > >>>> No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani > >>>> JOSM-ng v jaru? > >>> http://shell.sh.cvut.cz/~nenik/josmng.html > >>> Ted jsem to zkousel a je tam jeste ten styl, co "doprostred" lesniho polygonu > >>> namaluje stromecek, coz ted pri pohledu na CR vypada vskutku > >>>> zabavne... > >> Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl > >> uzitecny, javu v browseru rozjetou nemam :-(. > > > > ...jinak pouzivat alt-clicky neni na linuxu mozny, zere je window > > manager :-(. > MUJ fvwm2 je nezere. OK, point taken, nicmene pouzitelne modifikatory > a klavesove zkratky na linuxu jsou pole znacne zaminovane, budu si na to > muset dat pozor. Zvlaste proto, ze ani na linuxaka nejsem reprezentativni > vzorek. > > Tak jako tak chci to malovani nodu predelat, drzet pul hodiny Alt pri oklikavani > Lipna je kravina, ze? Prvni node nejakym gestem, pak skryty mod jinak modeless UI > az do Esc by mohlo byt pruchodne, ale jak uz tu zaznelo, rad bych se napred podival > na "opravdovy" GIS.
Jo... kdyby slo nejak zoomovat bez kolecka mysi, bylo by to dost fajn. Nektery notebooky (thinkpad x60) stale kolecko nemaj... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

7.8.2008 09:31:48 (#147)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
zobrazit citaci
> Pred importem jsem vyhazoval cesty z lesu a jine podobne artefakty, co > se mi nelibily. Potom odstranuji nektere prebytecne body. Prekvapilo me, > ze algoritmus generalizace za sebou zanechal treba tri body v rozmezi > 20m na uplne rovne care...
No ten algoritmus ma svoje vyhody (non-intersection), ale i nevyhody. Tyto body za sebou vznikaji tim, ze se nekde zacne (v kazdem polygonu jsou dva bodiky tesne u sebe) a zbytek se dela viditelnosti. Hranice viditelnosti se nesmi menit a je pevna. Potom zustavaji body, ktere by klasickej DP vyhodil. Ale myslim, ze za ty non-intersect to stalo. Diry bohuzel vycouhnout muzou, protoze se delaji zvlast. T

7.8.2008 11:20:07 (#148)
gravatar

Pavel Machek

<pavel at ucw.cz>
1023 1226
zobrazit citaci
> Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa? > Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les > sdilely nody....
Prosim ne, minimalne v josm by se to pak dost mizerne editovalo. Jinak moje uploady uz dojeli... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

11.8.2008 05:31:57 (#149)
gravatar

BH

<singularita at gmail.com>
306
Tak mapping party tam asi tezko pujde usporadat :) Ale z UHUL ortofota by to zmapovat jit melo v pohode, vcetne vsech cest a silnic :) Martin 2008/8/4 Michal Kovar <megabordel at seznam.cz>: zobrazit citaci
> Toho uz se nekdo rad chopi :) > > On Mon, 04 Aug 2008 13:24:14 +0200, Kubajz <kubajz at kbx.cz> wrote: > >> Sexy je, ale na muj vkus je moc hrube namletej... Trosku, ale jen >> nepatrne bych ho zkusil pojemnit. Misty je to opravdu takove otesane. >> A pak je krasny, jak v UHULu nemaji zaneseny lesy ve vojenskych >> ujezdech...

11.8.2008 08:23:11 (#150)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ono to jde, ale je asi stejne zbytecne mapovat vojensky ujezd, kdyz tam vlastne nikdo nesmi. Vyjimkou je zmapovani cest, ktere jsou v Jincich otevreny o vikendech pro turisty na okrajich. Uz jsem zadal pozadavek na renderovani military=danger_area (tmave cervena pruhledna, takze pripadne lesy a vody budou videt) a Jince jsem obtahnul (podle wiki je to z 95% les a kdyz neni v UHULu, tak ho strcim do oblasti a jedu po hrane) Podle mapy otevrenych turistickych cest jsem se tak na 90% trefil do spravneho obrysu. K BH napsal(a): zobrazit citaci
> Tak mapping party tam asi tezko pujde usporadat :) > > Ale z UHUL ortofota by to zmapovat jit melo v pohode, vcetne vsech > cest a silnic :) > > Martin > > 2008/8/4 Michal Kovar <megabordel at seznam.cz>: > >> Toho uz se nekdo rad chopi :) >> >> On Mon, 04 Aug 2008 13:24:14 +0200, Kubajz <kubajz at kbx.cz> wrote: >> >> >>> Sexy je, ale na muj vkus je moc hrube namletej... Trosku, ale jen >>> nepatrne bych ho zkusil pojemnit. Misty je to opravdu takove otesane. >>> A pak je krasny, jak v UHULu nemaji zaneseny lesy ve vojenskych >>> ujezdech... >>> > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

20.8.2008 07:44:11 (#151)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Zamerte svoji pozornost do oblasti cerneho mostu -- rekneme 50.1009, 14.556.. bude potreba josm. Jsou tam pres sebe "prilis podrobny" a "zjednoduseny" import (jeste to prosim chvili nemazte, udelam to, tak v radu tydnu). Jenze se zda ze to ten zjednodusovac misty celkem prehnal -- treba les posunul kousek vedle, nebo zkosil roh kde zkoseny nebyl, pripadne zmenil tvar lesa z konvexniho na konkavni... Hmm, ale ted uz je asi pozde plakat, co? ...no, v silne exponovanych mistech (Brno?) bych se mozna primlouval za importovani originalnich (presnych) dat... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

20.8.2008 08:03:27 (#152)
gravatar

Kubajz

<kubajz at kbx.cz>
614
Ja jsem ve vetsine mist zadne zasadni problemy nepozoroval. Pouzivam ke kontrole vrstvu z wms. Navic mam pocit, ze je lepsi mit ve vetsine mist data generalizovana a tam, kde to bude vadit, tak je zpresnit. K Pavel Machek napsal(a): zobrazit citaci
> Zamerte svoji pozornost do oblasti cerneho mostu -- rekneme 50.1009, > 14.556.. bude potreba josm. Jsou tam pres sebe "prilis podrobny" a > "zjednoduseny" import (jeste to prosim chvili nemazte, udelam to, tak > v radu tydnu). > > Jenze se zda ze to ten zjednodusovac misty celkem prehnal -- treba les > posunul kousek vedle, nebo zkosil roh kde zkoseny nebyl, pripadne > zmenil tvar lesa z konvexniho na konkavni... > > Hmm, ale ted uz je asi pozde plakat, co? ...no, v silne exponovanych > mistech (Brno?) bych se mozna primlouval za importovani originalnich > (presnych) dat... > Pavel >

20.8.2008 08:43:28 (#153)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Wed 2008-08-20 20:03:27, Kubajz wrote: zobrazit citaci
> Ja jsem ve vetsine mist zadne zasadni problemy nepozoroval. Pouzivam ke > kontrole vrstvu z wms. Navic mam pocit, ze je lepsi mit ve vetsine mist > data generalizovana a tam, kde to bude vadit, tak je zpresnit.
Ale jo, urcite je to lepsi nez zadny import, ale ty artefakty jsou divny. Les, na nem maly vycnelek. V "zjednodusenych" datech les, na nem maly vycnelek, ale ty dva se neprekryvaj. Pavel zobrazit citaci
> K > > Pavel Machek napsal(a): > > Zamerte svoji pozornost do oblasti cerneho mostu -- rekneme 50.1009, > > 14.556.. bude potreba josm. Jsou tam pres sebe "prilis podrobny" a > > "zjednoduseny" import (jeste to prosim chvili nemazte, udelam to, tak > > v radu tydnu). > > > > Jenze se zda ze to ten zjednodusovac misty celkem prehnal -- treba les > > posunul kousek vedle, nebo zkosil roh kde zkoseny nebyl, pripadne > > zmenil tvar lesa z konvexniho na konkavni... > > > > Hmm, ale ted uz je asi pozde plakat, co? ...no, v silne exponovanych > > mistech (Brno?) bych se mozna primlouval za importovani originalnich > > (presnych) dat... > > Pavel > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz at openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

20.8.2008 08:52:37 (#154)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> > Zamerte svoji pozornost do oblasti cerneho mostu -- rekneme 50.1009, > > 14.556.. bude potreba josm. Jsou tam pres sebe "prilis podrobny" a > > "zjednoduseny" import (jeste to prosim chvili nemazte, udelam to, tak > > v radu tydnu).
Na nekterych mistech v praze jsem to uz sloucil (odmazl novy import a stary "prilis podrobny" slepil do jednoho kusu, mit oznacene jednotlive druhy lesa je sice pekne, ale je z toho spise gulas, pri editaci je tam spousta "zbytecnych" car ktere matou a yty hranice jsou treba v mapniku i trochu videt), takze to casem zmizi ... ono nekde ten uhul neni moc presny, treba mi z toho vyslo, ze to cele velke kolejiste na depu hostivar (takova velka plocha se spoustou paralelnich koleji) je uplne v lese. Takze vyseknout a nechat jen okoli .... podobnych mensich nepresnosti, kdy i v podrobnych datech z UHULU jsou chyby (les na miste, kde je zarucene jen louka, pole nebo zastavba) je tam relativne dost, takze bych to asi moc nehrotil. Na druhou stranu, u tech podrobnych dat pokud je napr hranice se silnici, tak je tam presna, zatimco u zjednodusenych uz ne - a tam, kde les sdili hranici s necim jinym (silnice, zastavba, rybnik, ...) obvykle ta nepresnost vadi nejvic. Mozna vydat pro zajemce o rucni import presnejsi data pro prahu, brno a par dalsich vetsich mest? Martin zobrazit citaci
> > Jenze se zda ze to ten zjednodusovac misty celkem prehnal -- treba les > > posunul kousek vedle, nebo zkosil roh kde zkoseny nebyl, pripadne > > zmenil tvar lesa z konvexniho na konkavni...
zobrazit citaci
> > Hmm, ale ted uz je asi pozde plakat, co? ...no, v silne exponovanych > > mistech (Brno?) bych se mozna primlouval za importovani originalnich > > (presnych) dat... > > Pavel

20.8.2008 09:27:30 (#155)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
BH napsal(a): zobrazit citaci
> Na druhou stranu, u tech podrobnych dat pokud je napr hranice se > silnici, tak je tam presna, zatimco u zjednodusenych uz ne - a tam, > kde les sdili hranici s necim jinym (silnice, zastavba, rybnik, ...) > obvykle ta nepresnost vadi nejvic.
Kdyz uz jsme u toho (a ja to tu uz jednou zminoval, Pavel byl proti), tak ta hranice by dle best practices (viz wiki:ProjectCzechia) skutecne mela byt sloucena. I na Pavlovu vytku, ze se s tim pak v JOSM dost spatne pracuje uz mam odpoved: UngluePlugin. Takze pro les podel silnice zvesela merguju nody.... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

20.8.2008 09:40:55 (#156)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Wed 2008-08-20 21:27:30, Petr Nejedly wrote: zobrazit citaci
> BH napsal(a): > > Na druhou stranu, u tech podrobnych dat pokud je napr hranice se > > silnici, tak je tam presna, zatimco u zjednodusenych uz ne - a tam, > > kde les sdili hranici s necim jinym (silnice, zastavba, rybnik, ...) > > obvykle ta nepresnost vadi nejvic. > > Kdyz uz jsme u toho (a ja to tu uz jednou zminoval, Pavel byl proti), > tak ta hranice by dle best practices (viz wiki:ProjectCzechia) skutecne > mela byt sloucena.
No, a) to na ty wikine nevidim, a b) tohle by asi melo byt rozhodnuty pro cely osm, ne ze si to nekdo cesky napise na nejou obskurni stranku. zobrazit citaci
> I na Pavlovu vytku, ze se s tim pak v JOSM dost spatne pracuje uz mam odpoved: > UngluePlugin. Takze pro les podel silnice zvesela merguju nody....
No, doufam ze tem co to po Tobe budou opravovat bude taky veselo. Co treba potlach? A je rozumny aby ted unglueplugin byl povinny? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

21.8.2008 09:02:35 (#157)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> > Kdyz uz jsme u toho (a ja to tu uz jednou zminoval, Pavel byl proti), > > tak ta hranice by dle best practices (viz wiki:ProjectCzechia) skutecne > > mela byt sloucena. > > > No, a) to na ty wikine nevidim, a b) tohle by asi melo byt rozhodnuty > pro cely osm, ne ze si to nekdo cesky napise na nejou obskurni stranku. > > > > I na Pavlovu vytku, ze se s tim pak v JOSM dost spatne pracuje uz mam odpoved: > > UngluePlugin. Takze pro les podel silnice zvesela merguju nody.... > > > No, doufam ze tem co to po Tobe budou opravovat bude taky veselo. Co > treba potlach? A je rozumny aby ted unglueplugin byl povinny?
Tak zrovna ungule plugin nefunguje: org.openstreetmap.josm.plugins.PluginException: An error occoured in plugin ungl ueplugin .... Caused by: java.io.IOException: e:\josm\JOSM\plugins\unglueplugin.jar contains n o manifest. at org.openstreetmap.josm.plugins.PluginInformation.<init>(PluginInforma tion.java:70) ... 34 more Zdrojaky ani autora pluginu jsem nenasel, takze asi smula .... Martin

22.8.2008 12:35:25 (#158)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
BH napsal(a): zobrazit citaci
> Tak zrovna ungule plugin nefunguje: > > org.openstreetmap.josm.plugins.PluginException: An error occoured in plugin ungl > ueplugin > .... > Caused by: java.io.IOException: e:\josm\JOSM\plugins\unglueplugin.jar contains n > o manifest. > at org.openstreetmap.josm.plugins.PluginInformation.<init>(PluginInforma > tion.java:70) > ... 34 more > > Zdrojaky ani autora pluginu jsem nenasel, takze asi smula ....
Me funguje, zdrojaky jsou primo v pluginovem jaru.... -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

22.8.2008 12:57:29 (#159)
gravatar

BH

<singularita at gmail.com>
306
Aha ... tak kdyz jsem mrknul na unglueplugin.jar tak jsem tam nasel tohle: -- citace -- I have taken my business elsewhere as I was told on the mailing lists. Goodbye and be miserable. -- konec citace -- Holt autoupdate ... muzete nekdo nekam hodit funkcni verzi? Google nachazi akorat tuhle zmrsenou ... Martin zobrazit citaci
> Me funguje, zdrojaky jsou primo v pluginovem jaru....

22.8.2008 10:10:10 (#160)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
BH napsal(a): zobrazit citaci
> Aha ... tak kdyz jsem mrknul na unglueplugin.jar tak jsem tam nasel tohle: > > -- citace -- > > I have taken my business elsewhere as I was told on the mailing lists. > Goodbye and be miserable.
Hmm, nemyslim si, ze zrovna na Henryho byl nekdo osklivy. Uz vubec ne ve spojeni s unglue pluginem. Teda pokud si nevzal osobne muj prepis proti josm-ng API (vyrazne jednodussi kod, ale to je probem josm, ne ungluepluginu... zobrazit citaci
> Holt autoupdate ... muzete nekdo nekam hodit funkcni verzi? Google > nachazi akorat tuhle zmrsenou ...
http://shell.sh.cvut.cz/~nenik/unglueplugin.jar -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

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