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

> 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 na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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.

> 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.

> 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...

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

> 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 na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ahoj, > > kolda na 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 na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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 > > >> Ahoj, >> >> kolda na 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ahoj, > > kolda na 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 na 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 na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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 > > >> Ahoj, >> >> kolda na 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 na 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 na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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. >

>> 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. >

>> 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. >

>> 4. Vyhodit plochy/diry mensi nez X >>

> tech IMO moc neni, ale muze se to udelat. > >> 5. Provest generalizaci (15m chyba) >> 6. Opravit polygony (self-intersection) >> > z principu nemaji >

>> 7. Rozsekat polygony na mensi (max. Y nodu) >> >> > celkem dobrej napad, na to jsem zatim nepomyslel >

> Ahoj, > > kolda na 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 na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 na 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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 na 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 na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 na 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 na 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 na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

>> 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... >

> >> 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... >

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

>> K >> >> kolda na 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 na 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 na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ahoj, > > kolda na 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 na 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 na 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 na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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 > > >> Ahoj, >> >> kolda na 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 na 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 na 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 na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> kolda na 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 na 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 na 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 na 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 na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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): >> kolda na 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 na 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 na 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 na 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 na openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 na 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 na 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 na 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 na 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 na openstreetmap.org >>>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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.

> kolda na 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 ;-) > >

> 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 na 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 na 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 na 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 na 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 na openstreetmap.org >>>>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Talk-cz mailing list >>>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Talk-cz mailing list >>>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 na 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 na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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 na 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 na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 na 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 na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> 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 na 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 na 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 na openstreetmap.org >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > >

> > 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...

> 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. >

>> 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....

> 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. > >

> 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. >> >> >

>>> 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.

> 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 na 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 > >

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Me ta prohlizecka jede a je ukrutne rychla. Co to chce za knihovnu? > > On Mon, 04 Aug 2008 11:59:14 +0200, Kubajz <kubajz na 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na 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 >> >> >> > > > >

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> MSVCR80.dll

> 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 na kbx.cz> wrote: > > >> MSVCR80.dll >> > > > >

> 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 na kbx.cz> wrote: >> >> >>> MSVCR80.dll >>> >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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 na kbx.cz> wrote: > > >> MSVCR80.dll >> > > > >

> 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 na kbx.cz> wrote: >> >> >>> MSVCR80.dll >>> >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> Kam ty knihovny kopirujes? :) > > On Mon, 04 Aug 2008 12:55:56 +0200, Kubajz <kubajz na 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 na kbx.cz> wrote: >>> >>> >>> >>>> MSVCR80.dll >>>> >>>> >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na 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 >> >> >> > > > >

> 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 na 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 na kbx.cz> wrote: >>>> >>>> >>>> >>>>> MSVCR80.dll >>>>> >>>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na 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 na 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 > >

> No rekni, jestli ten spenat mezi silnicema neni sexy! :)) > > On Mon, 04 Aug 2008 13:09:49 +0200, Kubajz <kubajz na 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 na kbx.cz> wrote: >>> >>> >>> >>>> MSVCR80.dll >>>> >>>> >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na 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 >> >> >> > > > >

> 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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...

> ------------ Původní zpráva ------------ > Od: Pavel Machek <pavel na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> 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?

> 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...

>> 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...

> Jo... urcite by bylo dobry pridat nejaky znacky... landuse=forest, > source=uhul... a asi i neco k bodum.

> 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.

> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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"? >

> 2008/8/5 Michal Kovar <megabordel na 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. > > >

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> >> 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.

> 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

> 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.

> 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... >

>> 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... >

> 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...

> 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.

>> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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.

> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 :)

> 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 na 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 na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 na 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 na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-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 na 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 na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 na 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 na 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 na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na 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 na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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 na 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 na 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 na 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 na openstreetmap.org > >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Talk-cz mailing list > >>>>>>> Talk-cz na openstreetmap.org > >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Talk-cz mailing list > >>>>>> Talk-cz na 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 na openstreetmap.org > >>>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Talk-cz mailing list > >>>> Talk-cz na openstreetmap.org > >>>> http://lists.openstreetmap.org/listinfo/talk-cz > >>> > >>> > >>> > >>> _______________________________________________ > >>> Talk-cz mailing list > >>> Talk-cz na openstreetmap.org > >>> http://lists.openstreetmap.org/listinfo/talk-cz > >> > >> > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz na openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-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 na 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 na 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 na 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 na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na openstreetmap.org >>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Talk-cz mailing list >>>>>>> Talk-cz na 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 na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 na 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 na 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 na 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 na 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 na openstreetmap.org >>>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Talk-cz mailing list >>>>>>>>> Talk-cz na openstreetmap.org >>>>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Talk-cz mailing list >>>>>>>> Talk-cz na 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 na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > _______________________________________________ > Talk-cz mailing list > Talk-cz na 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 > >

> 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 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...

> > 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.

> 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 :-(.

> 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 :-(.

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

> Da se to pustit nejak jinak nez pres web browser? Link na .jar by byl > uzitecny, javu v browseru rozjetou nemam :-(.

> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> 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 :-(.

> Jinak je to znatellne rychlejsi nez josm, a kresli to > hezky... pekne.

> Mozna bych od nejakeho zoomu schoval ikonky lesu a parkovist...

> 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.

> 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).

> 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).

> 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... > > >

> > Beru si za ukol 015 a cpu to tam...

> Pekna prace , beru si na upload dily 006, 007. Diky

> 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.

>> >> > Pekna prace , beru si na upload dily 006, 007. Diky >

>>> >>> >>> >> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

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

> 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-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 > > 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-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 >

> 2008/8/6 Kubajz <kubajz na 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

> > 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> 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

> ------------ Pů1vodní zpráva ------------ > Od: Pavel Machek <pavel na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> 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.

> Dne 5. srpen 2008 21:54 Pavel Machek <pavel na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Tak to mame > > 1-8, 15-16, 20, 32-33. > nekdo psal nekde o 17 > tak ja bych uploadnul jeste 18 a 19 > > >

> ------------ Původní zpráva ------------ > Od: Marek Musil <wopixe na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Pridam se a beru si 009 a 010 > > Tedy obsazene jsou: > > 1-10, 15-20, 32-33 > >

> 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 na 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > ---- > S pozdravem > Mail: psbox na seznam.cz > http://fatbozz.towerofglass.net > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> ------------ Původní zpráva ------------ > Od: noone02 <noone02 na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> ------------ Původní zpráva ------------ > Od: Kubajz <kubajz na 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 na 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 na openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > >> > >> > >> > > > > ---- > > S pozdravem > > Mail: psbox na seznam.cz > > http://fatbozz.towerofglass.net > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> 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 na 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 na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > ---- > S pozdravem > Mail: psbox na seznam.cz > http://fatbozz.towerofglass.net > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> megabordel :) >

> 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 na 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 na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> >>> >> ---- >> S pozdravem >> Mail: psbox na seznam.cz >> http://fatbozz.towerofglass.net >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> megabordel :) > > >> ------------ Původní zpráva ------------ >> Od: Kubajz <kubajz na 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 na 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> >>>> >>> ---- >>> S pozdravem >>> Mail: psbox na seznam.cz >>> http://fatbozz.towerofglass.net >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > ---- > S pozdravem > Mail: psbox na seznam.cz > http://fatbozz.towerofglass.net > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 na 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 na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> >>>> >>>> >>> ---- >>> S pozdravem >>> Mail: psbox na seznam.cz >>> http://fatbozz.towerofglass.net >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> > 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;))

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

> 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 na 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 na 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 na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ---- >>>> S pozdravem >>>> Mail: psbox na seznam.cz >>>> http://fatbozz.towerofglass.net >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >>> >>> >>> >> ---- >> S pozdravem >> Mail: psbox na seznam.cz >> http://fatbozz.towerofglass.net >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-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 na 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 na 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 na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ---- >>>>> S pozdravem >>>>> Mail: psbox na seznam.cz >>>>> http://fatbozz.towerofglass.net >>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>>> >>>> >>> ---- >>> S pozdravem >>> Mail: psbox na seznam.cz >>> http://fatbozz.towerofglass.net >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> 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 na 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 na 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 na 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 na openstreetmap.org >>>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ---- >>>>>> S pozdravem >>>>>> Mail: psbox na seznam.cz >>>>>> http://fatbozz.towerofglass.net >>>>>> >>>>>> _______________________________________________ >>>>>> Talk-cz mailing list >>>>>> Talk-cz na openstreetmap.org >>>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> Talk-cz na openstreetmap.org >>>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ---- >>>> S pozdravem >>>> Mail: psbox na seznam.cz >>>> http://fatbozz.towerofglass.net >>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> Talk-cz na openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-cz >>>> >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

> > 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29.

> *) 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?

> 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? >

> 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? >

> 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.

> 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...

> 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....

> Toho uz se nekdo rad chopi :) > > On Mon, 04 Aug 2008 13:24:14 +0200, Kubajz <kubajz na 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...

> 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 na seznam.cz>: > >> Toho uz se nekdo rad chopi :) >> >> On Mon, 04 Aug 2008 13:24:14 +0200, Kubajz <kubajz na 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

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

> 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): > > 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 na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

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

> 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.

> 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.

> 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....

> > 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 ....

> Me funguje, zdrojaky jsou primo v pluginovem jaru....

> 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.

> Holt autoupdate ... muzete nekdo nekam hodit funkcni verzi? Google > nachazi akorat tuhle zmrsenou ...