UHUL WFS import

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

K

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

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

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.

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

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

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

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

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

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

Podle vseho by to mel byt tento:

ev. dalsi kolem

Dik... posles prosim jeste zbytek url? Uz si ho nepamatuju :-(. Pavel

K

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

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

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?

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?

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

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?

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.

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.

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

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

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!

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

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

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

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

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