> Podle vseho by to mel byt tento: > > x723388_x1059320_x713388_x1049320.xml.gz > > ev. dalsi kolem

> K > > Pavel Machek wrote: > > Ahoj! > > > >> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > >> protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > >> je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > >> > >> Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > >> mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > >> BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > >> prekryvaji). > >> > >> Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > >> Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > >> konkretni soubor/y. Kazdy soubor je 100sqkm. > > > > Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, > > E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... > > Pavel > > -- > Jakub Sýkora > email: kubajz na kbx.cz <') > ICQ: 68976632 ( =- > mobil: +420 777 594 201 '' > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Ahoj, > > skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na > > http://kubajz.kbx.cz/junk/uhul/output > > Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je > to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji > 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou > zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a > pomalu se presouvam k Plzni. > > Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu > importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :]

> Jakub Sykora napsal(a): >> Ahoj, >> >> skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na >> >> http://kubajz.kbx.cz/junk/uhul/output >> >> Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je >> to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji >> 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou >> zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a >> pomalu se presouvam k Plzni. >> >> Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu >> importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :] > Hnedka prvni soubor co jsem zkousel (http://kubajz.kbx.cz/junk/uhul/output/x853388_x1139320_x843388_x1129320.xml.bz2) > ma v sobe deravy polygon s propojkou a nejake prekryvy. > viz uhul:id=1478,2554,1482 > >

> Ahoj, > > To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru > hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno > korektni renderovani.

> Jakub Sykora napsal(a): >> Ahoj, >> >> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru >> hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno >> korektni renderovani. > > Myslel jsem, ze "spravne"(tm) se derave polygony tvori pomoci relace > multipolygon s inner/outer way. > viz relace#3033: > <relation id="3033" timestamp="2007-11-12T20:32:57Z"> > <member type="way" ref="4797225" role="inner"/> > <member type="way" ref="12172221" role="outer"/> > <tag k="created_by" v="JOSM" /> > <tag k="type" v="multipolygon" /> > </relation> > a jeji korektni renderovani: > http://openstreetmap.org/?lat=50.051056&lon=14.365452&zoom=18&layers=B0F > > Neco je zmineno tez na: > http://wiki.openstreetmap.org/index.php/Relations/Multipolygon > >

> Aha, tak to mi uniklo. Nicmene na strance s API 0.5 jsem skoncil tim, ze > restrictions jsou, ale zatim nemaji zadne specifikace. Proto jsem to > nechal tak, jak to je. Je to take tim, ze jsem akorat predelaval skript > z API 0.4 na 0.5 a ve starsi verzi se to resilo obracenim smeru, coz > nekdy fungovalo. > > Zde je tedy prostor pro diskuzi, jestli to nezkusit udelat pomoci relaci... > > K

> On Nov 26, 2007 5:10 PM, Jakub Sykora <kubajz na kbx.cz> wrote: >> Aha, tak to mi uniklo. Nicmene na strance s API 0.5 jsem skoncil tim, ze >> restrictions jsou, ale zatim nemaji zadne specifikace. Proto jsem to >> nechal tak, jak to je. Je to take tim, ze jsem akorat predelaval skript >> z API 0.4 na 0.5 a ve starsi verzi se to resilo obracenim smeru, coz >> nekdy fungovalo. >> >> Zde je tedy prostor pro diskuzi, jestli to nezkusit udelat pomoci relaci... >> >> K > > Urcite ano, do budoucna to bude mnohem jednodussi na spravovani. Jinak > ty data vypadaji super, uz se tesim az to bude vsecko zelene. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> On Nov 26, 2007 5:10 PM, Jakub Sykora <kubajz na kbx.cz> wrote: >> Aha, tak to mi uniklo. Nicmene na strance s API 0.5 jsem skoncil tim, ze >> restrictions jsou, ale zatim nemaji zadne specifikace. Proto jsem to >> nechal tak, jak to je. Je to take tim, ze jsem akorat predelaval skript >> z API 0.4 na 0.5 a ve starsi verzi se to resilo obracenim smeru, coz >> nekdy fungovalo. >> >> Zde je tedy prostor pro diskuzi, jestli to nezkusit udelat pomoci relaci... >> >> K > > Urcite ano, do budoucna to bude mnohem jednodussi na spravovani. Jinak > ty data vypadaji super, uz se tesim az to bude vsecko zelene. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Jak jsou na tom renderery, co se tyka teto relace? Zobrazi ji korektne? > > K >

> On Nov 26, 2007 5:25 PM, Jakub Sykora <kubajz na kbx.cz> wrote: >> Jak jsou na tom renderery, co se tyka teto relace? Zobrazi ji korektne? >> >> K >> > http://lists.openstreetmap.org/pipermail/talk/2007-October/019437.html > > prave sem to vyzkousel na lese, funguje to, vnejsi polygon po smeru, > vnitrni proti smeru. > relace: > <relation id='-21' visible='true'> > <member type='way' ref='-18' role='' /> > <member type='way' ref='-17' role='' /> > <tag k='type' v='multipolygon' /> > </relation> > > a je tam dira. > > rendrovano osmarenderem6 > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Jakub Sykora napsal(a): >> Ahoj, >> >> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru >> hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno >> korektni renderovani. > > Myslel jsem, ze "spravne"(tm) se derave polygony tvori pomoci relace > multipolygon s inner/outer way. > viz relace#3033: > <relation id="3033" timestamp="2007-11-12T20:32:57Z"> > <member type="way" ref="4797225" role="inner"/> > <member type="way" ref="12172221" role="outer"/> > <tag k="created_by" v="JOSM" /> > <tag k="type" v="multipolygon" /> > </relation> > a jeji korektni renderovani: > http://openstreetmap.org/?lat=50.051056&lon=14.365452&zoom=18&layers=B0F > > Neco je zmineno tez na: > http://wiki.openstreetmap.org/index.php/Relations/Multipolygon > >

> A nemely by byt role inner a outer? > > Jinak jsem zjistil, ze UHUL WFS ma v datech krasne popsane, co je > outline a co je uvnitr. Modifikace tak budou nenarocne. > > K >

> On Nov 27, 2007 7:49 AM, Jakub Sykora <kubajz na kbx.cz> wrote: >> A nemely by byt role inner a outer? >> >> Jinak jsem zjistil, ze UHUL WFS ma v datech krasne popsane, co je >> outline a co je uvnitr. Modifikace tak budou nenarocne. >> >> K >> > > role tam klidne napis:) to sem nezkousel, zkousel sem jen ruzne > smerovane vektory polygonu, kdyz byly shodne dira nebyla, kdyz byly > jak sem napsal tak dira byla. Ani v tom Buckingham palacu role nemel. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru > hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno > korektni renderovani.

>> To by nemela byt chyba, ale vlastnost. Ty diry by mely jit protismeru >> hod. rucicek a obrys jako takovy po smeru, cimz by melo byt zaruceno >> korektni renderovani. > > To je pravda, ale aby to tak opravdu fungovalo tak musi byt vsechny > polygony v relaci (s "type"="multipolygon"). Pokud je dodrzeno > pravidlo "po/proti" smeru rucicek, nemusi se nastavovat inner/outer > (jak tu uz nekdo zminoval) > > Na http://www.openstreetmap.org/?lat=50.09965&lon=14.4013&zoom=17&layers=B0F > jsou videt priklady budov s dirama, kde je to takhle reseny (bez > inner/outer, ale se spravnym smerovanim) Nekde jsou i tri "vrstvy" > (budova, pak vykus a pak mensi "domek na dvorku", ktery je opet po > smeru a zobrazen je jako polygon) > > Martin > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Ahoj, > > skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na > > http://kubajz.kbx.cz/junk/uhul/output > > Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je > to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji > 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou > zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a > pomalu se presouvam k Plzni. > > Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu > importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :] >

> Nova varka! > > Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > > Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > prekryvaji). > > Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > konkretni soubor/y. Kazdy soubor je 100sqkm. > > Na hranicich jsou pak data moc hezka - jsou tam videt i signalky... viz > http://kubajz.kbx.cz/junk/uhul/map.png > > V adresari http://kubajz.kbx.cz/junk/uhul/ je pak pro zajemce i java > zdrojak (omlouvam se, je to desna prasecina, ale funguje a je celkem > rozsiritelna/upravitelna :]) > > K > > Jakub Sykora wrote: >> Ahoj, >> >> skripty jsem doladil snad do finalni podoby. Podivejte se, prosim, na >> >> http://kubajz.kbx.cz/junk/uhul/output >> >> Je tam zatim par desitek souboru, ale snad z toho jde poznat, jestli je >> to dobre nebo ne. Prouzkuje to od zapadu na vychod. Soubory, co maji >> 129B jsou prazdne (resp. prazdne validni xml - v danem regionu nejsou >> zadna data). V archivu jsou ted urcite data Krusnych hor, KV kraje a >> pomalu se presouvam k Plzni. >> >> Pokud budou data shledana pouzitelnymi, tak soubor po souboru budu >> importovat pres JOSM na server. Pokud mate lepsi zpusob, uvitam ho :] >> >

> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > > Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > prekryvaji). > > Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > konkretni soubor/y. Kazdy soubor je 100sqkm.

> Ahoj! > >> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, >> protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene >> je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] >> >> Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich >> mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do >> BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak >> prekryvaji). >> >> Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s >> Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n >> konkretni soubor/y. Kazdy soubor je 100sqkm. > > Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, > E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... > Pavel

> Podle vseho by to mel byt tento: > > x723388_x1059320_x713388_x1049320.xml.gz > > ev. dalsi kolem

> >> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, > >> protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene > >> je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] > >> > >> Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich > >> mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do > >> BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak > >> prekryvaji). > >> > >> Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s > >> Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n > >> konkretni soubor/y. Kazdy soubor je 100sqkm. > > > > Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, > > E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... > > Pavel >

> On Fri 2007-11-30 13:58:24, Jakub Sykora wrote: >> Podle vseho by to mel byt tento: >>

>> >> ev. dalsi kolem > > Dik... posles prosim jeste zbytek url? Uz si ho nepamatuju :-(. > > Pavel >> K >> >> Pavel Machek wrote: >>> Ahoj! >>> >>>> Nyni plne podle API 0.5 vcetne relaci. Doufam, ze ted uz budou data OK, >>>> protoze to jelo celou noc, nez to vygenerovalo zabalenych 500MB. Nicmene >>>> je fakt, ze to jelo na skvelem Celeron M 360 s 512MB pameti :] >>>> >>>> Take jsem dodatecne pridal identifikaci kolizi a zjistil jsem, ze jich >>>> mezi sousednimi ctverci nebylo malo (UHUL WFS vraci vse co zasahuje do >>>> BB, tudiz vice nez BB a kdyz to udela kazdy ctverec, tak se pak >>>> prekryvaji). >>>> >>>> Mela by tam byt komplet cela CR. Pokud potrebujete konkreti soubor s >>>> Vasi oblasti, tak provedu reverzni preklad souradnic a poslu odkaz n >>>> konkretni soubor/y. Kazdy soubor je 100sqkm. >>> Jestli to neni problem, rad bych si prohlid' ctverec kolem N50, >>> E14.75. Trochu to tam znam, a mapoval jsem tam podle orthofoto... >>> Pavel >> -- >> Jakub Sýkora >> email: kubajz na kbx.cz <') >> ICQ: 68976632 ( =- >> mobil: +420 777 594 201 '' >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ahoj, > prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > coz pokryva asi 1/6 mesta Brna. > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne pracovat, na hloupych 10km ctverecnich. > Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win.

> > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety?

> * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM?

> * vytvorime tematicke vrstvy v JOSM, tak abych treba si nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem?

> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na napr: buk dub, nebo jen listnaty/jehlicnaty?

> * cokoliv jineho? > > PS: ctverec opet/jeste obsahuje nulove body v JTSK

> > ha

> > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > coz pokryva asi 1/6 mesta Brna. > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne pracovat, na hloupych 10km ctverecnich. > Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win. > > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety?

> * vytvorime tematicke vrstvy v JOSM, tak abych treba si > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem?

> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena > jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito > zbytecne mnoho bodu. > >> Ted je opet otazka jak dal: >> >> * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? > > To nepredpokladam. > >> * generalizujeme data tak, aby slo dale pracovat a tento vystup >> nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? > > Jak na to?

>> * vytvorime tematicke vrstvy v JOSM, tak abych treba si >> nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se >> zoomem? > > Jak na to? To netusim uz vubec...

>> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na >> napr: buk dub, nebo jen listnaty/jehlicnaty? > > Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam > nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho > informace les listnaty/jehlicnaty/smiseny vytahne sam...

>> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena >> jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito >> zbytecne mnoho bodu. >> >>> Ted je opet otazka jak dal: >>> >>> * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? >> To nepredpokladam. >> >>> * generalizujeme data tak, aby slo dale pracovat a tento vystup >>> nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? >> Jak na to? > *** zkusim se na to podivat. snad to umi JUMP... > zatim jsem se dostal pres kompilaci noveho osm2shp, ale vyhazuje prazdne > shapefily... Je slozita konverze vzorku do GML?

> >>> * vytvorime tematicke vrstvy v JOSM, tak abych treba si >>> nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se >>> zoomem? >> Jak na to? To netusim uz vubec... > *** to vi mozna Petr... > >>> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na >>> napr: buk dub, nebo jen listnaty/jehlicnaty? >> Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam >> nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho >> informace les listnaty/jehlicnaty/smiseny vytahne sam... > *** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake > oblasti lesa z mnoha polygonu na dva typy a to laicke napr. > listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme > udelat shapefile do jejich GISu s plnym datasetem.

> > Jeste jedna vec. On ten les je vlastne neni potreba editovat - tezko > vytvorime neco lepsiho, presnejsiho, podrobnejsiho. Je-li nejaka cast > vykacena, bude opet vysazena (pokud nebyla vynata z lesniho fondu pudy).

> > > ha > > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> Ahoj, > prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz

> > coz pokryva asi 1/6 mesta Brna. > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne pracovat, na hloupych 10km ctverecnich.

> Pocitac je to Pent Dual 2,8GHZ/2GB ram + JAVA 1.6win. > > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety?

> * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? > * vytvorime tematicke vrstvy v JOSM, tak abych treba si nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem?

> Vyhazeni vnitrnich polygonu je ovsem vec, ktera uz neni trivialni. > Muselo by se zjistovat, jestli dira obsahuje vypln (coz je jiny typ > lesa) a pokud ano, tak ji odstranit spolecne s dirou. > Na tento problem neznam nic moc dorby algoritmus - vede to na slozitost > n^2, kde n je pocet polygonu - porovnavat skoro kazdy les s kazdym > lesem. Pametova narocnost by v tomto pripade byla take nezanedbatelna.

> On Dec 4, 2007 1:55 PM, Jakub Sykora <kubajz na kbx.cz> wrote: >> Vyhazeni vnitrnich polygonu je ovsem vec, ktera uz neni trivialni. >> Muselo by se zjistovat, jestli dira obsahuje vypln (coz je jiny typ >> lesa) a pokud ano, tak ji odstranit spolecne s dirou. >> Na tento problem neznam nic moc dorby algoritmus - vede to na slozitost >> n^2, kde n je pocet polygonu - porovnavat skoro kazdy les s kazdym >> lesem. Pametova narocnost by v tomto pripade byla take nezanedbatelna. > > Hm, ja to vidim tak, ze kde je polygon, ktery presne vyplnuje diru, > tak maji shodne hrany, pouze opacne orientovane. Takze staci > zahashovat hrany, ne? > > Martin > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

>>> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena >>> jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito >>> zbytecne mnoho bodu. >>> >>>> Ted je opet otazka jak dal: >>>> >>>> * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? >>> To nepredpokladam. >>> >>>> * generalizujeme data tak, aby slo dale pracovat a tento vystup >>>> nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? >>> Jak na to? >> *** zkusim se na to podivat. snad to umi JUMP... >> zatim jsem se dostal pres kompilaci noveho osm2shp, ale vyhazuje prazdne >> shapefily... Je slozita konverze vzorku do GML? > > V GML jsou data od UHULu, takze je jednodussi vzit tento soubor vraceny > WMS a provest primo v nem transformaci do WGS84.

> > V GML jsou data od UHULu, takze je jednodussi vzit tento soubor vraceny > > WMS a provest primo v nem transformaci do WGS84. > *** to me nejak nedoslo. > > *** Nevim jak jsou presne v GML ci SHP definovany ostrovy polygonu, ale > ta nejhorsi varianta, je ze by se ostrovy daly bokem a pak znova do > slouceneho datasetu vlozily. > > existuje do JUMP plugin mapgeneralize, ktery ma i funkci klasickeho > slouceni polygonu. Pokud jsem to zkousel na prikladu: > > http://212.158.143.149/cgi-bin/wfs?service=WFS&version=1.0.0&request=getFeature&typeName=typo&bbox=-685591,-1064775,-682518,-1061770 > > * priklad stazeny (2967 bodů) > * priklad se sloucenim vsech polygonu do uzavrenych celku vcetne ostrovu > (1128 bodů)

> takze tudy vede cesta... ale asi by to stejne jeste chtelo generalizovat

> >>> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na > >>> napr: buk dub, nebo jen listnaty/jehlicnaty? > >> Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam > >> nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho > >> informace les listnaty/jehlicnaty/smiseny vytahne sam... > > *** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake > > oblasti lesa z mnoha polygonu na dva typy a to laicke napr. > > listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme > > udelat shapefile do jejich GISu s plnym datasetem. > > Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych > nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se > resil tezko - jedna se o zakomentovani dvou radku.

> Ahoj!

> Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o > poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- > "rozhrani porostu" -- a i podle toho se da v nouzi jit.

>>> *** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake >>> oblasti lesa z mnoha polygonu na dva typy a to laicke napr. >>> listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme >>> udelat shapefile do jejich GISu s plnym datasetem. >> Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych >> nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se >> resil tezko - jedna se o zakomentovani dvou radku. > > "Les je les"... no ne tak uplne. Je pomerne velky rozdil mezi > vzrostlym smrkovym lesem -- da se jim bezet -- a hustymi mladymi > smrcky ve vysce 2.5metru -- tim se neda v podstate ani jit. Ve fakt > hnusnym hustniku bude rychlost tak 1km/h a bezny clovek se mu radej > vyhne. Mapy pro orientacni beh to zachycujou, protoze je to nutne > potreba pro navigaci po lese, a da se podle toho bez problemu > orientovat. > > Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o > poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- > "rozhrani porostu" -- a i podle toho se da v nouzi jit. > Pavel > (jehoz josm se pri nacteni tri lesovych dlazdic > lehce zadychaval, ale lehke zadychavani povazuje > za lepsi nez chybejici data.)

> Ahoj! > > > prave jsem si nahral a vypada to moc pekne: > > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > > > coz pokryva asi 1/6 mesta Brna. > > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne pracovat, na hloupych 10km ctverecnich.

> > * vytvorime tematicke vrstvy v JOSM, tak abych treba si > > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem?

> Ahoj, > > hanoj napsal(a): > >> Z pozorovani take vyplyva, ze vetsina vyrezu v datech je pak zaplnena > >> jinym typem lesa - tudiz pro zobrazeni zeleneho fleku je vyuzito > >> zbytecne mnoho bodu. > >> > >>> Ted je opet otazka jak dal: > >>> > >>> * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety? > >> To nepredpokladam. > >> > >>> * generalizujeme data tak, aby slo dale pracovat a tento vystup > >>> nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM? > >> Jak na to? > > *** zkusim se na to podivat. snad to umi JUMP... > > zatim jsem se dostal pres kompilaci noveho osm2shp, ale vyhazuje prazdne > > shapefily... Je slozita konverze vzorku do GML? > > V GML jsou data od UHULu, takze je jednodussi vzit tento soubor vraceny > WMS a provest primo v nem transformaci do WGS84. > > > > >>> * vytvorime tematicke vrstvy v JOSM, tak abych treba si > >>> nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se > >>> zoomem? > >> Jak na to? To netusim uz vubec... > > *** to vi mozna Petr... > > > >>> * zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na > >>> napr: buk dub, nebo jen listnaty/jehlicnaty? > >> Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam > >> nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho > >> informace les listnaty/jehlicnaty/smiseny vytahne sam... > > *** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake > > oblasti lesa z mnoha polygonu na dva typy a to laicke napr. > > listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme > > udelat shapefile do jejich GISu s plnym datasetem. > > Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych > nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se > resil tezko - jedna se o zakomentovani dvou radku. > Vyhazeni vnitrnich polygonu je ovsem vec, ktera uz neni trivialni. > Muselo by se zjistovat, jestli dira obsahuje vypln (coz je jiny typ > lesa) a pokud ano, tak ji odstranit spolecne s dirou. > Na tento problem neznam nic moc dorby algoritmus - vede to na slozitost > n^2, kde n je pocet polygonu - porovnavat skoro kazdy les s kazdym > lesem. Pametova narocnost by v tomto pripade byla take nezanedbatelna. > > > > > Jeste jedna vec. On ten les je vlastne neni potreba editovat - tezko > > vytvorime neco lepsiho, presnejsiho, podrobnejsiho. Je-li nejaka cast > > vykacena, bude opet vysazena (pokud nebyla vynata z lesniho fondu pudy). > > > > > > > > > ha > > > > hanoj > > > > _______________________________________________ > > 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 > On 12/3/07, Pavel Machek <pavel na ucw.cz> wrote: > > Ahoj! > > > > > prave jsem si nahral a vypada to moc pekne: > > > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > > > > > coz pokryva asi 1/6 mesta Brna. > > > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne pracovat, na hloupych 10km ctverecnich. > > v zmapovane zastavbe to kvuli mnozstvi detailu asi tak dobre nepujde. > Ono kilometr ctverecni v zastavbe muze mit stejne mnozstvi detailu > jako 1000 km ctverecnich nekde v polich. Holt se bude muset pouzit > mensi okno (nebo zlepsit JOSM) > > Koukam ze vsechny lesy maji 141Mb dohromady zabalene, v soucasnosti ma > CR asi 7 Mb ... vcelku vyznamne ji to nafoukne, ale jinak bych to tam > nahral cele, z nejakemu prilisnemu zjednodusovani bych se neuchyloval > ... kdyz uz nahrat, tak poradne. Zjednodusit si to muze treba az > renderer .... > > > > * vytvorime tematicke vrstvy v JOSM, tak abych treba si > > > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem? > > To by ale asi muselo podporovat serverove api - stahnout z vyrezu data > v nejake vrstve nebo vyhovujici nejakemu filtru. > > Martin >

> On Dec 5, 2007 3:02 AM, BH <singularita na gmail.com> wrote: > > No > > On 12/3/07, Pavel Machek <pavel na ucw.cz> wrote: > > > Ahoj! > > > > > > > prave jsem si nahral a vypada to moc pekne: > > > > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz > > > > > > > > coz pokryva asi 1/6 mesta Brna. > > > > Tento jeden XML ma 7MB, takze po jeho natazeni uz nejde s JOSM rozumne pracovat, na hloupych 10km ctverecnich. > > > > v zmapovane zastavbe to kvuli mnozstvi detailu asi tak dobre nepujde. > > Ono kilometr ctverecni v zastavbe muze mit stejne mnozstvi detailu > > jako 1000 km ctverecnich nekde v polich. Holt se bude muset pouzit > > mensi okno (nebo zlepsit JOSM) > > > > Koukam ze vsechny lesy maji 141Mb dohromady zabalene, v soucasnosti ma > > CR asi 7 Mb ... vcelku vyznamne ji to nafoukne, ale jinak bych to tam > > nahral cele, z nejakemu prilisnemu zjednodusovani bych se neuchyloval > > ... kdyz uz nahrat, tak poradne. Zjednodusit si to muze treba az > > renderer .... > > > > > > * vytvorime tematicke vrstvy v JOSM, tak abych treba si > > > > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem? > > > > To by ale asi muselo podporovat serverove api - stahnout z vyrezu data > > v nejake vrstve nebo vyhovujici nejakemu filtru. > > > > Martin > > > Ja osobne bych upravoval editovaci nastroje, nez omezoval data v mape! > Pokud na to josm nestaci tak je chyba v nem a musi se opravit. Myslim, > ze by nebyl problem napriklad zahodit urcita data po stazeni, aby pri > editaci nezavazely a nezpomalovaly program. Ale to je spis diskuze do > josm-devel listu nebo na jejich bugzillu (trac nebo co to je). > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> > Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o > > poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- > > "rozhrani porostu" -- a i podle toho se da v nouzi jit. > > Pavel > > (jehoz josm se pri nacteni tri lesovych dlazdic > > lehce zadychaval, ale lehke zadychavani povazuje > > za lepsi nez chybejici data.) > > *** to sice mas pravdu, ale: > 1) mapa pro orientak je specialka, navic v CR je uzemi kde se muze behat > podle orientackych map mnohokrat premerene. OSM neni specialka. Pro > tento ucel by mel zustat zachovan grabnuty dataset z WFS v nejakem > standardu napr. GML. Mohlo by se s originalem zachazet jako se > SRTM...

> Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech!

> Aspon pro nektere lesy bych chtel plna data .. snazim se je mapovat > podobne podrobne jako jsou orientacke mapy. A myslim ze je > nejjednodussi importovat lesy uplne: ty data stejne nejsou hustssi nez > treba centrum Prahy... a aspon tady to beha celkem pouzitelne (a to je > to v jave).

> > Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech! > > (Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel > importovat, tak bych se za to dost primlouval ;-).

>> Aspon pro nektere lesy bych chtel plna data .. snazim se je mapovat >> podobne podrobne jako jsou orientacke mapy. A myslim ze je >> nejjednodussi importovat lesy uplne: ty data stejne nejsou hustssi nez >> treba centrum Prahy... a aspon tady to beha celkem pouzitelne (a to je >> to v jave). >> > > Treba ctverec 50.00,14.30 - 50.25,14.55 ma asi 10MB (1.5MB kdyz to > vezmu gzipem) a obsahuje vetsinu prahy a par nejakych vesnic na sever. > Coz je asi 10% cele CR (pro ni ma OSM vytahane z dumpu asi 100MB) > > Jak velky (kolik stupnu krat kolik stupnu) jsou ty ctverce v adresari > http://kubajz.kbx.cz/junk/uhul/output/ ? > > Ale asi bych to tam soupnul v plnych detailech i se vsemi porosty. > Kdyz uz mapu, tak kvalitni a asi o tolik mensi to nebude kdyby se to > zkouselo nejak osekat a kvalita by tim asi utrpela... > > >>> Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech! >>> >> (Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel >> importovat, tak bych se za to dost primlouval ;-). >> > > Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. > Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc > dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho > jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s > rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze > autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat > lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde > cpat. > > Martin > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ctverce jsou 10x10 km, kolik je to stupnu fakt nevim (resp. lze udelat > jednoduchy prepocet z nazvu souboru. Namisto x dosad minus a mas rozmery > BB. Pak staci konverze do WSG84).

> > (Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel > > importovat, tak bych se za to dost primlouval ;-). > > Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. > Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc > dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho > jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s > rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze > autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat > lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde > cpat. > > Martin

> > > (Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel > > > importovat, tak bych se za to dost primlouval ;-). > > > > Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. > > Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc > > dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho > > jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s > > rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze > > autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat > > lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde > > cpat.

> vrstevnice zatim nikdo neplanuje co sem pochytil, ale spousta projektu > pouziva dostupne data (SRTM) a placa to jako dalsi vrstvu nad osm > data, http://www.free-map.org.uk, freemap.sk, ja mam v garminu > pridanu mapu s vrstevnicemi z http://gps-maps.info/cz/

> SRTM se do OSM nestrka predevsim proto: > 1, ze je velky > 2, a neni duvod ho editovat > > Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene > jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k > permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL > my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam > podari ho omylem poskodit. > Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze > klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v > JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi > vrstva/mapa. > > Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to > jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, > ktery se ho pokousi zrychlit v stavajicich mezich). > > Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. > Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit > trebas 50km zeleznice pres vysocinu. > > > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> 2, a neni duvod ho editovat > [...] > Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap.

> On Dec 11, 2007 11:42 AM, hanoj <enemy na mail.muni.cz> wrote: > >> 2, a neni duvod ho editovat >> [...] >> Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. >> > > Jo, to jsou myslim dobre duvody, proc UHUL neimportovat. > > Martin > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> SRTM se do OSM nestrka predevsim proto: > 1, ze je velky > 2, a neni duvod ho editovat > > Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene > jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k > permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL > my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam > podari ho omylem poskodit. > Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze > klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v > JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi > vrstva/mapa. > > Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to > jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, > ktery se ho pokousi zrychlit v stavajicich mezich).

> Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. > Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit > trebas 50km zeleznice pres vysocinu.

> > Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze > > klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v > > JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi > > vrstva/mapa.

> > Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to > > jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, > > ktery se ho pokousi zrychlit v stavajicich mezich).

> Blby je, ze kdyz nechame uhul data jen "nekde vedle", tak bude > potreba: > > 1) upravit mapu na openstreetmap.org aby to zobrazovala

> 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data > > 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi > budou kreslit jiz existujici lesy) > > 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj > brat od jinud. (Napr. navit, maemomapper).

> ...to mi prijde celkem dost prace, ktera navic akorat vsechno > zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. > > Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak > strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit > celej zbytek OSM sveta pracovat s dvema zdroji dat.

> > Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. > > Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit > > trebas 50km zeleznice pres vysocinu.

> On Tue 2007-12-11 11:42:26, hanoj wrote: > >> SRTM se do OSM nestrka predevsim proto: >> 1, ze je velky >> 2, a neni duvod ho editovat >> >> Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene >> jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k >> permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL >> my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam >> podari ho omylem poskodit. >> Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze >> klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v >> JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi >> vrstva/mapa. >> >> Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to >> jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, >> ktery se ho pokousi zrychlit v stavajicich mezich). >> > > Blby je, ze kdyz nechame uhul data jen "nekde vedle", tak bude > potreba: > > 1) upravit mapu na openstreetmap.org aby to zobrazovala > > 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data > > 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi > budou kreslit jiz existujici lesy) > > 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj > brat od jinud. (Napr. navit, maemomapper). > > ...to mi prijde celkem dost prace, ktera navic akorat vsechno > zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. > > Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak > strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit > celej zbytek OSM sveta pracovat s dvema zdroji dat. > > >> Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. >> Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit >> trebas 50km zeleznice pres vysocinu. >> > > Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ > strasnej ten josm neni. > Pavel >

> Tak naimportujem data jen na zadost mapera v jeho okoli, zeleznice pres > vysocinu(potoky reky) by se opravdu delaly spatne. Pomalost JOSM s > velkymi objemy dat je castecne omezujici faktor, ale nejak jsem > nepozoroval ze by me vyrazne zdrzovalo. To ze si nemuzu nacist > maximalnich 5.4kmx6km v okoli velkych evropskych mest je realitou uz > delsi dobu.

> > 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj > > brat od jinud. (Napr. navit, maemomapper). > > Uz vidim to readme pro vyvojare: .... a zde je API pro stahovani dat z > OSM a zdre je 100 ruznych API pro stahovani 100 ruznych externich > zdroju ktery jsou na OSM nabaleny (UHUL + buhvico by si lidi z > ostatnich zemi vymysleli .... )

> 1) upravit mapu na openstreetmap.org aby to zobrazovala > > 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data > > 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam > lidi budou kreslit jiz existujici lesy) > > 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj > brat od jinud. (Napr. navit, maemomapper). > > ...to mi prijde celkem dost prace, ktera navic akorat vsechno > zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL.

> Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak > strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit > celej zbytek OSM sveta pracovat s dvema zdroji dat. > >> Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj >> CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo >> narocne nakreslit trebas 50km zeleznice pres vysocinu. > > Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ > strasnej ten josm neni.

> pouze mapovy list: > x613388_x1149320_x603388_x1139320.xml > cca 6000 kB negzipovany > zoom zobrazeni z fullextent na ctverec listu 11 sekund > zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) > posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m > uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m > select jedne area a jeji vysviceni 4 sekundy v meritku 250m > > nebo jsem snad jedinej? > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > >

> > 1) upravit mapu na openstreetmap.org aby to zobrazovala >> 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data >> >> 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam >> lidi budou kreslit jiz existujici lesy) >> >> 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj >> brat od jinud. (Napr. navit, maemomapper). >> >> ...to mi prijde celkem dost prace, ktera navic akorat vsechno >> zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. > *** myslim ze staci vygenerovat jeden IMG pro garmin, jeden OSM file > separe lesu, sestavit kubajzem navrhovy mapserver, napsat na wiki "lesy > se nekresli, uz jsou, ale zatim jinde", slippymapplugin pro JOSM > modifikovat pro jiny zdroj mapserveru nez openstreetmap.org. > >> Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak >> strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit >> celej zbytek OSM sveta pracovat s dvema zdroji dat. >> >>> Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj >>> CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo >>> narocne nakreslit trebas 50km zeleznice pres vysocinu. >> Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ >> strasnej ten josm neni. > *** no ja nevim, ja mam k dispozici hw: > 1* AMD XP 2GHz - Ubuntu 7.10, Java 1.6 > 2* Intel Centrino Duo 1,6GHz - WinXP, Java 1.6 > 3* Intel PentiumD ~2GHz - WinXP, Java 1.6 > ** vzdy s JOSMlatest+Mappaint,WMSplugin,Validator a neco jako -Xmx280m+ > > Vsude stejnej problem nekde od 2-3000kB dat (negzipovano) pracuje > vyrazne pomaleji, na hranici toho, jak se da slusne kreslit, zoomovat, etc. > > Priklad v sestave hw 1*: > pouze mapovy list: > x613388_x1149320_x603388_x1139320.xml > cca 6000 kB negzipovany > zoom zobrazeni z fullextent na ctverec listu 11 sekund > zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) > posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m > uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m > select jedne area a jeji vysviceni 4 sekundy v meritku 250m > > nebo jsem snad jedinej? > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

> > 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj > > brat od jinud. (Napr. navit, maemomapper). > > > > ...to mi prijde celkem dost prace, ktera navic akorat vsechno > > zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. > *** myslim ze staci vygenerovat jeden IMG pro garmin, jeden OSM file > separe lesu, sestavit kubajzem navrhovy mapserver, napsat na wiki "lesy > se nekresli, uz jsou, ale zatim jinde", slippymapplugin pro JOSM > modifikovat pro jiny zdroj mapserveru nez openstreetmap.org.

> > Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ > > strasnej ten josm neni. > *** no ja nevim, ja mam k dispozici hw: > 1* AMD XP 2GHz - Ubuntu 7.10, Java 1.6 > 2* Intel Centrino Duo 1,6GHz - WinXP, Java 1.6 > 3* Intel PentiumD ~2GHz - WinXP, Java 1.6 > ** vzdy s JOSMlatest+Mappaint,WMSplugin,Validator a neco jako -Xmx280m+ > > Vsude stejnej problem nekde od 2-3000kB dat (negzipovano) pracuje > vyrazne pomaleji, na hranici toho, jak se da slusne kreslit, zoomovat, etc. > > Priklad v sestave hw 1*: > pouze mapovy list: > x613388_x1149320_x603388_x1139320.xml > cca 6000 kB negzipovany

> zoom zobrazeni z fullextent na ctverec listu 11 sekund

> zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) > posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m

> uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m

> select jedne area a jeji vysviceni 4 sekundy v meritku 250m

> nebo jsem snad jedinej?

> > nebo jsem snad jedinej? > > Zda se... tak kde je rozdil?

> a) Co je mappaint? Ja zadny balicek na kresleni neinstaloval, pouzivam > to co je v josm defaultne.

> b) josm verse 350 z 2007-10-07.

>>> nebo jsem snad jedinej? >> Zda se... tak kde je rozdil? > > Ze by v parameterech javy? Zjistil jsem ze na zhruba srovnatelnych HW > konfiguracich je to ve windows dosti pomalejsi nez v linuxu. Kdyz jsem > ve windows ke spousteni javy s josm.jar prilipnul parametr > -Dsun.java2d.opengl=true > tak hned se to vyrazne zrychlilo, veskere vykreslovani, posouvani a > prace s mapou ve windows. Takze kdo tam tenhle parametr nema, tak at > si ho tam soupne a zkusi to znova.

>>>> nebo jsem snad jedinej? >>>> >>> Zda se... tak kde je rozdil? >>> >> Ze by v parameterech javy? Zjistil jsem ze na zhruba srovnatelnych HW >> konfiguracich je to ve windows dosti pomalejsi nez v linuxu. Kdyz jsem >> ve windows ke spousteni javy s josm.jar prilipnul parametr >> -Dsun.java2d.opengl=true >> tak hned se to vyrazne zrychlilo, veskere vykreslovani, posouvani a >> prace s mapou ve windows. Takze kdo tam tenhle parametr nema, tak at >> si ho tam soupne a zkusi to znova. >> > *** tenhle parametr fungoval v drivejsich verzich JOSM (pul roku zpet?) > a bez nej nesel na Windows prakticky pouzivat. Od jiste doby je IMHO > standardne zapnut bez nutnosti ho uvadet v prikazove radce. > > ha > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Zkousel ste nekdo merkator? Je to napsane v qt4, me se to nejak > nepodarilo zatim zkompilovat, ale mohla by to byt zajimava > alternativa.

> A rozhodne bych udelal optimalizaci (jako treba vyhazeni duplicitnich > nodes a tak ...) > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > >

> BH napsal(a): > >> A rozhodne bych udelal optimalizaci (jako treba vyhazeni duplicitnich >> nodes a tak ...) >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> >> >> > > Myslim, ze by lesum velmi pomohla tato myslenka, která zapadla. V mem > regionu, je kazdy les urcite z 50% tvoren duplicitnima bodama. > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Ja ted sedim pred sebou rok stary notebook Lenovo X60 s WinXP, JOSM 484 > (mappaint, wmsplugin, validator), JRE_1.5.0_06, natahnu si citovany

> mapset: x703388_x1169320_x693388_x1159320.xml ktery ma 16 MB rozbaleny

> Aby to slo importovat (coz bych byl i ja rad) > > 1) je treba upravit JOSM -- to se ale v aktualni dobe nedeje (ja to > nesvedu)==>

> 2) do te doby muze byt zajimave vyuzit lesy v mapserveru a etc., jak > rikal kubajz ==> > 3) naruzivy Pavel, si zatim muze stahnout les z kubajzovyho tempu, a v > lehce zadychanem JOSM podle nich mapovat specialky