pokusny import lesu

140 zpráv
Zpět na přehled

pokusny import lesu

140 zpráv KTPMPJPP 14 účastníků 77 min čtení
  1. Pavel Machek pavel na suse.cz #m5ac5c4
    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
  2. Kubajz kubajz na kbx.cz #ma09f27
    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...
  3. Tomas Kolda kolda na web2net.cz #m97668d
    Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se nasel nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se rekne algoritmus a je to. Staci tedy rict co je treba: 1. Spojit vsechny typy lesu do jednoho typu forest (v nejvetsi presnosti) 2. Udelat generalizaci na potrebnou uroven (Douglas-Plucker neni uplne super na polygony). 3. Rozsekat velke polygony na mensi. 4. Zkontrolovat nekolik uzemi a uploadovat. Ja bych mohl pomoci s nekolika vecma. Jen bych potreboval data. Kdyz da nekdo aktualni link kde jsou, pripadne s nejakym popisem formatu (pokud to neni osm) tak bych to klidne udelal. Podle me dokud nekdo nerekne ja to udelam, tak to neudela nikdo. At tedy nekdo rekne, dostane 14 dni a bude vysledek. Pripadne se muzou zapojit ostatni. Co mam za nebezne algorimy, ktere by se mozna hodily. Uz jsem je dlouho nepouzival, tak by se musely oprasit... - rozpletani polygonu (pokud je jakkoliv slozity self-intersect polygon, umi ho rozmotat). Dobre jako postprocesing polygonove simplifikace - vytvareni polygonu s bodu (vytvori polygon ze site bodu, ktere jsou v polygonu). Napr kdyby byl kazdy strom jeden nod a dal se limit 50 metru tak vytvori obalovy polygon lesa s max. vzdalenosti stromu 50 metru... Umi to i diry. - mergovani polygonu (i protinajicich se), ale tech existuje vice implementaci - simplifikace polygonu s podminkou zvetsovani plochy (zamezuje neduhum Douglas-Plucker) Ted dodelavam prvni public verzi te "navigace", takze nic moc nestiham, ale tak za tyden ci 14 dni bych to mohl zkusit (pokud mi nekdo da data). Kdyz to nekdo dokonci budu mu velmi vdecen, mapicka je pak mnohem krasnejsi.... T
  4. hanoj ehanoj na gmail.com #m1c067f
    Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se nasel nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se rekne algoritmus a je to.
    *** protoze je to tak zasadni rozsireni, kdy je treba najit takovy konsenzus, aby byl optimalizovan prinos pro stavajici i budouci uzivatele geodat osm. Technicky postup a prace je jedna zasluzna cast, dalsi je predhozeni vysledku ku nahledu ostatnim. Historie se nemusi pokazde opakovat. hanoj
  5. Pavel Machek pavel na suse.cz #m6ff303
    Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se nasel nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se rekne algoritmus a je to. Staci tedy rict co je treba: 1. Spojit vsechny typy lesu do jednoho typu forest (v nejvetsi presnosti) 2. Udelat generalizaci na potrebnou uroven (Douglas-Plucker neni uplne super na polygony). 3. Rozsekat velke polygony na mensi. 4. Zkontrolovat nekolik uzemi a uploadovat. Ja bych mohl pomoci s nekolika vecma. Jen bych potreboval data. Kdyz da nekdo aktualni link kde jsou, pripadne s nejakym popisem formatu (pokud to neni osm) tak bych to klidne udelal. Podle me dokud nekdo nerekne ja to udelam, tak to neudela nikdo. At tedy nekdo rekne, dostane 14 dni a bude vysledek. Pripadne se muzou zapojit ostatni.
    Zatim data zda-se jsou na: http://kubajz.kbx.cz/junk/uhul/output/
  6. Pavel Machek pavel na suse.cz #m529fc1
    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
  7. Kubajz kubajz na kbx.cz #m3af829
    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
  8. kolda na web2net.cz kolda na web2net.cz #mf77f9f
    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
  9. Michal Kovar megabordel na seznam.cz #m11c148
    Na traceovani bitmap je spousta kvalitniho softu - bohuzel jsem neprisel na to, jak nacpat EPS nebo DXF do OSM. A pritom by to byla tak jednoducha, pekna a cista prace. Editacni funkce a moznosti JOSM jsou v porovnani s profi grafickym softem hrozne primitivni. Kdybych nebyl grafik, asi by me to netrapilo, ale protoze jsem, tak jsem tim desne frustrovanej :)
  10. Kubajz kubajz na kbx.cz #ma22487
    Ahoj,
    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
  11. kolda na web2net.cz kolda na web2net.cz #m8a675b
    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
  12. Kubajz kubajz na kbx.cz #m7ceea6
    Ahoj,
    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.
  13. kolda na web2net.cz kolda na web2net.cz #m05716b
    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
  14. Kubajz kubajz na kbx.cz #me2b8a3
    Ahoj,
    Tak jo, zkusime tedy ty png. Pokud se tedy do toho nikdo nepusti, tak to klidne nejak zkusim pristi tyden. Jakou budem tahat podrobnost? 1 pixel na
    ja jsem se do toho pustil, tak mi pockej do konce tydne a predam kdyztak vse, co jsem do te doby vytvoril. V sobotu odjizdim na dovolenou, takze pak 14 dni na tom nebudu moci delat ani nahodou.
    5 metru? To by vychazelo tak na priblizne 300x200 tilu po 256x256 pixelu. Poslete mi sem akorat link na ty WMS data at alespon vim odkud pripadne tahat? Muj pripadny postup: 1. Stahnout tiles
    stahuji z WMS po kroku 0.1 stupne v rozliseni 2000x2000 bodu. To dava prijatelnou presnost a neni to prehnane.
    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
    8. Poslat jich par ke kontrole
    urcite :) Spis vsechny. Chyby se projevi casto na specifickych datech a kazdy z nas zkouma trochu jinou oblast CR.
    9. Poslat vse omarkovane do OSM
    asi ano, ale to bych nechal na diskuzi, az to bude hotove.
    10. Smazat pripadne uz nakreslene lesy, ktere nemaji mark (mozna rucne zkontrolovat)
    lesu je ted tak malo, ze je popr. odstranime rucne.
  15. Tomas Kolda kolda na web2net.cz #m3aa4af
    Ahoj,
    ja jsem se do toho pustil, tak mi pockej do konce tydne a predam kdyztak vse, co jsem do te doby vytvoril. V sobotu odjizdim na dovolenou, takze pak 14 dni na tom nebudu moci delat ani nahodou.
    Super! Jasne pockam urcite, prace je dost i jinde. Akorat to nejak pak posli do konference at se na tom da pokracovat.
    Muj pripadny postup: 1. Stahnout tiles
    stahuji z WMS po kroku 0.1 stupne v rozliseni 2000x2000 bodu. To dava prijatelnou presnost a neni to prehnane.
    Pokud dobre pocitam tak to rozliseni vychazi priblizne na tech 5m na pixel, takze ok.
    2. Prevest na jednobitovou bitmapu. Mozna by to slo i cele spojit (asi 500MB) 3. Prohnat potracem
    ale ten vraci krivky. Co s tim dal? Ja bych se klonil k variante bez potrace, pokud neexistuje moznost prehodit ho do rezimu rovnych car. Pokud bychom totiz vzali pouze body a ignorovali ridici body/tecny, tak bychom se dopustili velmi hrube chyby.
    Ja mam zkusenosti s potrace. Je bezproblemovej. Pouzivam binding do pythona, takze se s nim pracuje velmi pohodlne. Krivky se daji bud vypnout nebo je proste zpracovat, to neni problem, protoze simplifikace je vyrusi... Jestli existuje neco lepsiho (lakewalker neznam), tak se holt pouzije neco lepsiho... Pohodlnejsi ale bude zprocesovat to cele jako jedinou obrovskou bitmapu, coz potrace zvladne. Diry samorzejmne umi take.
    4. Vyhodit plochy/diry mensi nez X
    Toto muze byt potreba, protoze vektorizator muze vytvaret malicke polygony jako artefakty
    tech IMO moc neni, ale muze se to udelat.
    5. Provest generalizaci (15m chyba) 6. Opravit polygony (self-intersection)
    z principu nemaji
    Jak uz jsem psal. Vadne polygony vznikaji pri generalizaci. Nastava to malokdy, ale nastava. Napr. generalizovat dobre vltavu v praze pro velka meritka je opravdu orisek, jak je videt na nekterych navigacich.
    7. Rozsekat polygony na mensi (max. Y nodu)
    celkem dobrej napad, na to jsem zatim nepomyslel
    Bud se neco napise nebo se da pouzit CGAL. Ten to nejak ma. Reseni na miru bude mozna lepsi... Zbytek OK. Kdyz budes chtit s necim pomoct, jsem k dispozici. T
  16. Kubajz kubajz na kbx.cz #mf48b49
    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
  17. kolda na web2net.cz kolda na web2net.cz #m3366ac
    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
  18. Kubajz kubajz na kbx.cz #mbb04d6
    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
  19. kolda na web2net.cz kolda na web2net.cz #md1ee7e
    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
  20. Kubajz kubajz na kbx.cz #m3bb325
    Ahoj,
    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
  21. kolda na web2net.cz kolda na web2net.cz #mc58dd3
    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
  22. Kubajz kubajz na kbx.cz #md4e45a
    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...
  23. Tomas Kolda kolda na web2net.cz #mfc3297
    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
  24. Kubajz kubajz na kbx.cz #maddf86
    Ahoj,
    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 :)
  25. kolda na web2net.cz kolda na web2net.cz #m1046e2
    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
  26. Petr Nejedly Petr.Nejedly na Sun.COM #m35e078
    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 ;-)
  27. Kubajz kubajz na kbx.cz #m5c44e0
    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
  28. Vaclav Stepan vaclav.stepan na gmail.com #m78f554
    Ahoj, pokud by se to dalo zahrnout do vyzkumnych veci a bylo by potreba vic pameti, sly by pouzit stroje na Metacentru (nejsem si jist, kolik si muzu narokovat pameti, ale neco jako 5 GB by nemel byt velky problem, aspon pokud potrace jde zkompilovat na SGI). Vasek
  29. Tomas Kolda kolda na web2net.cz #m26d670
    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
  30. Kubajz kubajz na kbx.cz #md66a32
    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
  31. Tomas Kolda kolda na web2net.cz #mfe6cf2
    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
  32. Kubajz kubajz na kbx.cz #m29f165
    V odkazech na konci clanku je jedno pekne url, ktere se zabyva shromazdovanim algoritmu pro geometrii. K
  33. kolda na web2net.cz kolda na web2net.cz #m8122bb
    Vcera jsem dodelal ten algoritmus a s 25metrovou chybou a minimalni velikost plochy 2500 m2 to vychazi cca 1.500.000 nodu a 80.000 polygonu. Polygony vypadaji pomerne pekne. Potrebuju ted vyresit zobacky tech cesticek co rezou lesy nebo naopak couhaji. Napada vas neco? Moje napady: 1. Odstranit hrany polygonu, ktere svirajici uhel < 15 stupnu a zaroven je jejich vzdalenost (v limitu krajnich bodu) mensi nez neco. Pokud neco takoveho nastane, muzu decimovat polygon (rozdelit na polygon + diru, nebo polygon + polygon) 2. Bitmapu preprocesovat nejakym low-pass filterem s dobre nastavenym thresholdem. Tim se zrusi cesticky v lesech, ale zase se nam budou zakulacovat rohy (odstrani generalizace) Napada Vas neco lepsiho, jednodussiho atd.? K jake variante se klonite? T
  34. Pavel Machek pavel na suse.cz #m1529fb
    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.
  35. Petr Nejedly Petr.Nejedly na Sun.COM #m762ced
    Ahoj!
    Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune).
    Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu.... Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu...
    No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa.
    At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany. Na druhou stranu, OSMAPI "takhle" spatne napsany je.... *) http://www.openstreetmap.org/?lat=48.49457&lon=8.2033&zoom=16&layers=B00TTF
  36. Jiri Klement jiri.klement na gmail.com #m7753ea
    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.
  37. Tomas Kolda kolda na web2net.cz #mfe105c
    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
  38. Tomas Kolda kolda na web2net.cz #m4981cb
    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:
  39. Petr Nejedly Petr.Nejedly na Sun.COM #m7e9796
    No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa.
    At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany.
    Myslim ze osmarender to opravdu neresi. Proste renderuje najednou dostatecne velkou dlazdici (+ stahuje o dost vetsi oblast nez chce renderovat) a doufa, ze vetsi les nebude.
    Na druhou stranu, OSMAPI "takhle" spatne napsany je....
    Jak se tohle da resit? Napada me sestavit z ways polygon a u kazdeho polygonu ulozit jeho bounding box. Ale uz jenom vytvareni polygonu bude problem, protoze way muze byt jak hranice polygonu tak jenom cara, v zavislosti na tom, jake ma tagy.
    Ty uvozokvky mely byt spis kolem toho "spatne", ale ono je to jeste horsi nez jsem myslel. OSMAPI dokonce nevrati nic ani v pripade, ze pozadam o bbox protnuty cestou, jejiz vsechny nody jsou vne toho bboxu.
  40. Michal Kovar megabordel na seznam.cz #mfd4034
    Pokud budu mluvit pouze za sebe, tak at uz to tam je. Vypada to vyborne. A pripada mi, ze vic lidi spis upravuje, nez vytvari. Takze jestli nekde nejaka cesta ujizdi, nebo je nejaka jina potiz, tak si to kazdej ve svym znamym okoli popotahne rucne. Ta mapa ted vypada o 1000% lip. Dobra prace!
  41. Michal Kovar megabordel na seznam.cz #m239a0e
    Me ta prohlizecka jede a je ukrutne rychla. Co to chce za knihovnu?
  42. Kubajz kubajz na kbx.cz #m7b9bde
    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?
  43. Kubajz kubajz na kbx.cz #m7e159e
    MSVCR80.dll a MSVCP80.dll ============== fixme:spoolsv:serv_main (0 (nil)) fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 8000000a fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" err:module:import_dll Library MSVCR80.dll (which is needed by L"C:\\windows\\system32\\MSVCP80.dll") not found err:module:import_dll Library MSVCP80.dll (which is needed by L"E:\\Desktop\\viewer\\viewer.exe") not found err:module:import_dll Library MSVCR80.dll (which is needed by L"E:\\Desktop\\viewer\\viewer.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"E:\\Desktop\\viewer\\viewer.exe" failed, status c0000135 =============== K
  44. Tomas Kolda kolda na web2net.cz #m920ae2
    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:
  45. Kubajz kubajz na kbx.cz #m354738
    dik
  46. Michal Kovar megabordel na seznam.cz #mc729f9
    snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80
  47. Kubajz kubajz na kbx.cz #m427f5a
    Tak chytry jsem byl taky, ale porad se tomu nechce.... Neco delam blbe, ale je fakt, ze do wine jsem nikdy poradne nevidel... K
  48. Michal Kovar megabordel na seznam.cz #m58c409
    Kam ty knihovny kopirujes? :)
  49. Kubajz kubajz na kbx.cz #ma9c8f3
    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
  50. Michal Kovar megabordel na seznam.cz #mb199f0
    No rekni, jestli ten spenat mezi silnicema neni sexy! :))
  51. Kubajz kubajz na kbx.cz #m5cfc8e
    Ono nejde o to kam, ale o to, ze kopiruju jen tyhle dve. V tom baliku od M$ je vic souboru, na kterych jsou tyhle dve knihovny zavisle.
  52. Michal Kovar megabordel na seznam.cz #mbd873d
    Toho uz se nekdo rad chopi :)
  53. Kubajz kubajz na kbx.cz #mbf4c24
    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
  54. Kubajz kubajz na kbx.cz #m51027e
    Jeste vecer kdyztak poslu verzi z Mingw, ten ma mnohem mensi zavislosti. Jak
    uz je to OK - vyreseno...
    to tedka prohlizim, moc se mi nelibi prilisna generalizace nejakych mist. Zkusim to s 12metrovou presnosti, a kdyz bude hezci a vetsi treba jen o 25%
    Primlouvam se za ni okamzite... Takhle je to hezke, ale rekl bych, ze bychom si to mohli dovolit.
  55. hanoj ehanoj na gmail.com #m0773ae
    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
  56. Tomas Kolda kolda na web2net.cz #mee13e2
    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
  57. Tomas Kolda kolda na web2net.cz #me4d088
    Ahoj, tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Dik T Tomas Kolda writes:
  58. Pavel Machek pavel na suse.cz #m0ee512
    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
  59. Petr Schonmann PSBOX na seznam.cz #mbb0537
    Tak Hurá do "Aploudu" :)
    ---------------------------------------- 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
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  60. Pavel Machek pavel na suse.cz #m953fa5
    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... Pavel
  61. Pavel Machek pavel na suse.cz #m3c43c7
    Ahoj!
    tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip
    Byl by .osm.bz2?
    Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi?
    Ja jsem silnice importoval normalne josm-kem. Kdyz spadne spojeni, staci znovu zmacknout upload, josm to zvladne. Pruser by asi byl kdyby padl pocitac nebo josm -- coz se mi nastesti neprihodilo. Doporucoval bych velky .OSM rozdelit na takovych 20 dilu, a proste to uploadovat rucne josm...
    Jo... urcite by bylo dobry pridat nejaky znacky... landuse=forest, source=uhul... a asi i neco k bodum. Pavel
  62. hanoj ehanoj na gmail.com #mfbbb6c
    1) generalizace UHUL lesu je pro moje oko vyhovujici. pekna prace. Originaly by mohly byt nekde vystaveny ve vhodnem a jednoduchem souborovem formatu (treba shapefile).
    Shapefile muzu udelat. Diry v nem neumim, ale snad to nekde najdu.
    *** mam pocit, ze nejak to jde, ale asi je to nejake rozsireni ci co. Nebo nejake GML, ale preci jen to jeste neni vsude podporovano, ale ma nadeji. Rozhodne to GISasci oceni.
    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.
    3) co je to za format MXF?
    To je muj format, ktery pouzivam. Nekdy by to mela byt navigace... Aktualne jsem si zaregistroval degu.cz (jako OSMak degu...) Je to v podstate OSM s prostorovym indexem, R/W moznosti a velmi dobrou komprimaci. Nic standardniho...
    *** aha, myslel jsem ze je to neco co neznam ;) ha hanoj
  63. Petr Nejedly Petr.Nejedly na Sun.COM #m5abb49
    Jo... urcite by bylo dobry pridat nejaky znacky... landuse=forest, source=uhul... a asi i neco k bodum.
    Waye maji landuse=forest spravne nastavene, source nebo nejaky jiny identifikator tohoto uploadu by nebyl od veci, ale rozhodne bych netagoval nody, je to drahe a zbytecne....
  64. Petr Nejedly Petr.Nejedly na Sun.COM #m4bc3ca
    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.
  65. Tomas Kolda kolda na web2net.cz #md3587f
    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:
  66. Michal Kovar megabordel na seznam.cz #m786b62
    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"?
    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:
    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.
    __________ 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/
  67. Michal Grézl michal.grezl na gmail.com #m240c2d
    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.
  68. Michal Kovar megabordel na seznam.cz #m5ea38f
    To jsem si myslel :) On Tue, 05 Aug 2008 09:43:15 +0200, Michal Grézl <michal.grezl na gmail.com>
  69. Kubajz kubajz na kbx.cz #m889af1
    Druha se mi zda subjektivne hezci. Jsem pro otagovat to source=uhul:wms Importovat pravdepodobne po nejakych rozumne velkych celcich skrz JOSM. Dobra prace! K
  70. Pavel Machek pavel na suse.cz #mdbc7af
    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 necim o hrane 20km fakt nebude problem. Pavel
  71. Petr Nejedly Petr.Nejedly na Sun.COM #meaaf62
    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...
  72. Pavel Machek pavel na suse.cz #m5a9968
    Ahoj!
    2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi oblasti (napr. okres)?
    Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi.
    *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni efektivne data v CR dale editovat napric platformami. Pokud tato jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha pracovat s ctvercem o hrane 20km neni az tak neprirozena.
    Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s
    Opravdu?
    Jo.
    Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo.
    No, ja u prvniho renderovani nebyl. Kdyz jsem se vratil, bylo hotovo, a prvni operace byla "zoom". Pavel
  73. Kubajz kubajz na kbx.cz #m42426a
    No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani JOSM-ng v jaru? Onehda jsem se to pokousel zbuildovat a nejak mi to neslo... Diky, K
  74. Petr Nejedly Petr.Nejedly na Sun.COM #m501bde
    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.
  75. Petr Nejedly Petr.Nejedly na Sun.COM #m202223
    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...
    Onehda jsem se to pokousel zbuildovat a nejak mi to neslo...
    Hmm, chce to mit pobliz nainstalovane NetBeans a jednou to v nich otevrit. Budu muset ten build script predelat...
  76. hanoj ehanoj na gmail.com #mc316e4
    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
  77. Tomas Kolda kolda na web2net.cz #ma98a35
    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:
  78. Petr Nejedly Petr.Nejedly na Sun.COM #me7868e
    Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout.
    No ty cesticky me taky napadly... Vychazi to na cca 2000 zelenych fleku na soubor, to by se dalo rucne zlehka proklepnout ...
  79. Tomas Kolda kolda na web2net.cz #m07fa16
    MXF obsahuje vsechny informace nutne k vykresleni objektu (geometrii, typ (landuse), podtyp(forest), dodatecne atributy k typu/podtypu, ktere typ zna). Nenacitaji se ty informace jimz nerozumi (autor, apod.). Samozrejmne neobsahuje atributy add apod, protoze k tomu neni urcen. Kdyz se ale pridaji nejake modifikatory, tak by to jit melo. Ale jak uz jsem psal drive, neni to moje priorita. Je tam zabudovana moznost editace, ale ne pro OSM. Navrh neni delany na OSM, ale spise na formaty typu GDF. OSM se do GDF da ohnout, takze pro prohlizeni neni zadny problem. Pro JOSM to ale asi pouzitelne neni. Tvoje priorita asi nebude diskovy prostor, takze indexy ci cokoliv muzes udelat i s plejtvanim a vice moznostmi. Multistyly zatim nemam. Resim to skutecne jen zorderem. Napr se nejdrive kresli highway a na ni tram (zorder v OSM posouva vsechny tyto vrstvy najednou). Je to duplicita dat a moznost ke zmenseni, ale videl bych to max 2-3% spis min. Potreboval jsem jednoduchy zpusob jak co nejrychleji dostat objekty daneho typu v danem pohledu a to tento zpusob ulozeni zvlada okamzite. Pote se daji posilat do graficke pipeline velke kusy geometrii a vse se kresli rychleji. T Petr Nejedly writes:
  80. Kubajz kubajz na kbx.cz #m97a8ab
    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
  81. Michal Kovar megabordel na seznam.cz #mfdefb1
    Jih Prahy obyvam, tak budu hezky mlcky sledovat, jak nam to tu roste :)
  82. Michal Kovar megabordel na seznam.cz #mdee8db
    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 :)
  83. Jiri Klement jiri.klement na gmail.com #mcc9670
    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>:
  84. Petr Schonmann PSBOX na seznam.cz #m21b230
    A kdo to přerendruje v T na H :) ?
  85. Pavel Machek pavel na ucw.cz #m40464a
    Ahoj!
    Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout.
    Myslim ze neni duvod tohle delat _pred_ uploadem -- tech zmen nebude tak moc a jediny co takhle vznikne bude velky zmatek. Mnohem jednodussi bude kdyz kazdy po uploadu zkoukne casti ktery ho zajimaji -- az bude mit cas/naladu.
    Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :)
    Uploadit... Pavel
  86. Tomas Kolda kolda na web2net.cz #m8d5df0
    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:
  87. Tomas Kolda kolda na web2net.cz #m53c338
    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:
  88. Jiri Klement jiri.klement na gmail.com #mc2f18a
    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>:
  89. Michal Kovar megabordel na seznam.cz #m9aadf7
    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>
    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 :)
    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
    __________ Informace od NOD32 3301 (20080727) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.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/
  90. Petr Schonmann PSBOX na seznam.cz #m145220
    Jedine souhlas, kontrola by se mela delat za behu, ne tohle "tady to je asi takhle" ale kdo chce,casem si upravi.
    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>
    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 :)
    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
    __________ Informace od NOD32 3301 (20080727) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.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/
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  91. Jiri Klement jiri.klement na gmail.com #m4b3aac
    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>:
  92. Michal Kovar megabordel na seznam.cz #mca731e
    Dopoustis se stejneho zlocinu, jako bys detem odlozil o den Vanoce :) On Tue, 05 Aug 2008 21:33:07 +0200, Jiri Klement <jiri.klement na gmail.com>
    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>
    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 :)
    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
    __________ Informace od NOD32 3301 (20080727) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.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/
    __________ 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/
  93. Pavel Machek pavel na suse.cz #m1186fe
    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
  94. Pavel Machek pavel na suse.cz #mea175a
    Opravdu? Coz o to, "nahrat" to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal.
    *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka.
    Urcite mam jinou versi josm, a urcite nemam mappaint. Pavel
  95. Tomas Kolda kolda na web2net.cz #m5d0d46
    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:
  96. Pavel Machek pavel na suse.cz #md1d806
    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.
    Nebo uplne normalne stahnout ze serveru, ne? Stahovani je normalne dost rychly...
    Muj (jiz neaktualni) send je. lesy_001_send.osm.bz2 Jestli Vas napada lepsi zpusob sem s nim... Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi maximum).
    No... ono se to da ladovat rychleji i z jednoho pocitace, staci pustit vickrat josm. (Je to limitovany latenci, ne bandwidth). Ale jestli je zajem, muzu pustit upload i u sebe, staci rict ktery cisla mam uploadnout... Pres noc to neni problem. Pavel
  97. Petr Nejedly Petr.Nejedly na Sun.COM #mafdb78
    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...
  98. noone02 noone02 na centrum.cz #mb07ced
    Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi maximum).
    Vice lidi laduje rychleji, uz jenom proto, ze si pro sebe utrhnou vetsi cast (vic kousku) sdileneho zdroje (OSM databaze), ale take proto, ze kazdy ma cas jine 3 hodiny ;-) Beru si za ukol 015 a cpu to tam...
    Pekna prace , beru si na upload dily 006, 007. Diky
  99. Pavel Machek pavel na suse.cz #m94e204
    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. Pavel
  100. Pavel Machek pavel na suse.cz #md34fe1
    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
  101. noone02 noone02 na centrum.cz #m5015f9
    Ahoj! Ok, 001 uz tam je...
    Beru si za ukol 015 a cpu to tam...
    Pekna prace , beru si na upload dily 006, 007. Diky
    ...a ja si vemu 003.
    ...a 004, 3KB/sec je na moji linku malo ;-). Diky! Pavel
    Posilam 008
  102. Kubajz kubajz na kbx.cz #me18cdd
    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
  103. Jiri Klement jiri.klement na gmail.com #m6473bb
    Tak ja se pripojim kouskem 016 uz tam jsou: 001,003,004,006,007,008,015,016 a 032 2008/8/6 Kubajz <kubajz na kbx.cz>:
  104. Michal Grézl michal.grezl na gmail.com #mfb3eef
    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
  105. Pavel Machek pavel na ucw.cz #m90f35f
    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
    Rezervujte mi 2 a 5.
  106. Petr Schonmann PSBOX na seznam.cz #m311b52
    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
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  107. Pavel Machek pavel na ucw.cz #m47005c
    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
  108. Petr Schonmann PSBOX na seznam.cz #m4a9189
    Tu už uploaduju já
    ------------ Pů1vodní zpráva ------------ ----------------------------------------
    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
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  109. hanoj ehanoj na gmail.com #m788376
    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
  110. Jiri Klement jiri.klement na gmail.com #m501519
    API 0.6 asi neni az tak blizko. Jeden a pul mesice na nem nikdo nepracoval. 2008/8/6 hanoj <ehanoj na gmail.com>:
  111. Michal Grézl michal.grezl na gmail.com #m900120
    Tak to mame 1-8, 15-16, 20, 32-33. nekdo psal nekde o 17 tak ja bych uploadnul jeste 18 a 19
  112. Marek Musil wopixe na volny.cz #m7ad335
    Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Mara
  113. Petr Schonmann PSBOX na seznam.cz #m65e9a8
    Dovolil bych si vzit DVE a to 11 a 12 a zprehlednit tabulku :) 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 14 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 22 23 24 25 26 27 28 29 30 31 32 UPLOADED 33 UPLOADED
    ---------------------------------------- Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Mara
    Tak to mame 1-8, 15-16, 20, 32-33. nekdo psal nekde o 17 tak ja bych uploadnul jeste 18 a 19
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  114. noone02 noone02 na centrum.cz #mb466f3
    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
  115. noone02 noone02 na centrum.cz #m2294bc
    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
    ---------------------------------------- Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Mara
    Tak to mame 1-8, 15-16, 20, 32-33. nekdo psal nekde o 17 tak ja bych uploadnul jeste 18 a 19
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
    Byl jsi rychlejsi, beru si tedy 13 a 14
  116. Petr Schonmann PSBOX na seznam.cz #m6a8a55
    vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412
    ----------------------------------------
    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
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  117. Petr Schonmann PSBOX na seznam.cz #m99ed63
    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
    vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od
    serveru ch 412
    ----------------------------------------
    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
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
    ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  118. Kubajz kubajz na kbx.cz #m1ffde2
    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
  119. Michal Grézl michal.grezl na gmail.com #m258507
    2008/8/6 Petr Schonmann <PSBOX na seznam.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;))
  120. noone02 noone02 na centrum.cz #m18dc93
    Tabulku jsem upravil, protoze uploaduji 13 a 14
  121. Kubajz kubajz na kbx.cz #mc1b178
    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
  122. Kubajz kubajz na kbx.cz #m886686
    Ja jsem to zpetne zjistil. Ono neni fer upravovat citovanou cast dopisu - pro me to vypadalo, ze to tam napsal uz Petr Schonmann. Analyzou jeho prispevku jsem pak dorbny rozdil zjistil a uz jsem v klidu. K
  123. Pavel Machek pavel na ucw.cz #m2de275
    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
  124. Kubajz kubajz na kbx.cz #m963323
    Validator v JOSM to najde a umi i opravit... K
  125. Jiri Klement jiri.klement na gmail.com #m072567
    Tak jsem douplodoval, takze si beru dalsi dve 21, 22 Aktualni stav je tedy doufam tento: 001-022, 031-033 2008/8/6 Kubajz <kubajz na kbx.cz>:
  126. Kubajz kubajz na kbx.cz #ma97904
    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
  127. Jiri Klement jiri.klement na gmail.com #me466e9
    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>:
  128. Kubajz kubajz na kbx.cz #me335eb
    A nejen v Osmarenderu. Dokonce i v mapniku uz jsou asi dva pruhy pres CR: http://www.openstreetmap.org/?lat=49.955&lon=14.979&zoom=9&layers=B00FTF K
  129. Petr Schonmann PSBOX na seznam.cz #m57c2fd
    Beru 23 a 24 Stav je tedy následující link - http://www.web2net.cz/osm/lesy_001.osm.bz2 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 UPLOADED 24 UPLOADED 25 26 27 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED
  130. Pavel Machek pavel na suse.cz #m7bed8a
    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
  131. Kubajz kubajz na kbx.cz #m57a9d8
    Radeji to upresnim podle konvence, co drzime od zacatku... Zbyvaji tedy posledni dve - 28 a 29. 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 UPLOADED 24 UPLOADED 25 UPLOADED 26 UPLOADED 27 UPLOADED 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED
  132. Pavel Machek pavel na ucw.cz #m11bdba
    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
  133. Jiri Klement jiri.klement na gmail.com #m5895d4
    Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29. Takze by mely byt vsechny casti rozebrany.
  134. Petr Nejedly Petr.Nejedly na Sun.COM #mbe2ac9
    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?
  135. Tomas Kolda kolda na web2net.cz #md155e7
    Petr Nejedly writes:
    *) sloucit dva polygony: - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way - bud domalovat dve propojovaci waye nebo zmergovat stycne body - join way - spojit dva vysledne skoropolygony - celou dobu davat pozor na relace Neumi to nekdo lepe?
    Nepsal jste uz nekdo plugin do JOSM? Nebo pripadne nekoukal na API? Neprijde mi to jako slozita uloha, pokud je pristup k objektum. Stacilo by udelat nejaky tool... Me delali problem hlavne ty relace. JOSM je pri splitu kopiruje a pak si clovek musi davat pozor jak polygon rozdelil, aby nechal diry ve spravnych outer. Neumite v JOSMu schovat vse krome lesu?
  136. Kubajz kubajz na kbx.cz #m4cafc1
    Ahoj,
    Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29.
    Vy jste teda rychlici. Jestlipak jste se na to po sobe aspon trochu podivali?
    Pred importem jsem vyhazoval cesty z lesu a jine podobne artefakty, co se mi nelibily. Potom odstranuji nektere prebytecne body. Prekvapilo me, ze algoritmus generalizace za sebou zanechal treba tri body v rozmezi 20m na uplne rovne care...
    Ja tu svoji 015 (co byla na serveru na to tata) stale jeste ucesavam... Mel jsem tam nejake prekryvy se stavajicimi lesy a taky rusim "diry na silnici",
    prekryvy se stavajicimi lesy jsou asi to nejhorsi. Vzhledem k nutnemu vypnuti mappaintu je v tech carach dost bordel...
    coz je v JOSM docela pakarna*. Take se nabizi uzasna moznost domalovat ty silnice, co v databazi chybi, ale je na ne "tunel" v lese - takovou silnici podle ortofoto nenamalujete.
    ja rusim akorat cesty v lese, pokud jsou v ramci jednoho lesa. Vic lesu dohromady nespojuji, protoze to je fakt desna pakarna.
    Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa? Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les sdilely nody.... *) sloucit dva polygony: - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way - bud domalovat dve propojovaci waye nebo zmergovat stycne body - join way - spojit dva vysledne skoropolygony - celou dobu davat pozor na relace Neumi to nekdo lepe?
    ja ne
  137. Tomas Kolda kolda na web2net.cz #m72ead6
    Pred importem jsem vyhazoval cesty z lesu a jine podobne artefakty, co se mi nelibily. Potom odstranuji nektere prebytecne body. Prekvapilo me, ze algoritmus generalizace za sebou zanechal treba tri body v rozmezi 20m na uplne rovne care...
    No ten algoritmus ma svoje vyhody (non-intersection), ale i nevyhody. Tyto body za sebou vznikaji tim, ze se nekde zacne (v kazdem polygonu jsou dva bodiky tesne u sebe) a zbytek se dela viditelnosti. Hranice viditelnosti se nesmi menit a je pevna. Potom zustavaji body, ktere by klasickej DP vyhodil. Ale myslim, ze za ty non-intersect to stalo. Diry bohuzel vycouhnout muzou, protoze se delaji zvlast. T
  138. Pavel Machek pavel na ucw.cz #md347d5
    Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa? Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les sdilely nody....
    Prosim ne, minimalne v josm by se to pak dost mizerne editovalo. Jinak moje uploady uz dojeli... Pavel
  139. BH singularita na gmail.com #m1e6e5e
    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>:
  140. Kubajz kubajz na kbx.cz #m942d4c
    Ono to jde, ale je asi stejne zbytecne mapovat vojensky ujezd, kdyz tam vlastne nikdo nesmi. Vyjimkou je zmapovani cest, ktere jsou v Jincich otevreny o vikendech pro turisty na okrajich. Uz jsem zadal pozadavek na renderovani military=danger_area (tmave cervena pruhledna, takze pripadne lesy a vody budou videt) a Jince jsem obtahnul (podle wiki je to z 95% les a kdyz neni v UHULu, tak ho strcim do oblasti a jedu po hrane) Podle mapy otevrenych turistickych cest jsem se tak na 90% trefil do spravneho obrysu. K
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.