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

[Talk-cz] UHUL WFS import

Vlákno 26.11. - 16.12.2007, počet zpráv: 67


26.11.2007 08:56:15 (#1)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
On Fri 2007-11-30 13:58:24, Jakub Sykora wrote: zobrazit citaci
> Podle vseho by to mel byt tento: > > x723388_x1059320_x713388_x1049320.xml.gz > > ev. dalsi kolem
Dik... posles prosim jeste zbytek url? Uz si ho nepamatuju :-(. Pavel zobrazit citaci
> 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
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

26.11.2007 02:49:16 (#2)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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 Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

26.11.2007 03:20:51 (#3)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Jakub Sykora napsal(a): zobrazit citaci
> 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 -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

26.11.2007 04:05:57 (#4)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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. Kazdopadne s daty z UHULu jako takovymi jsem nedelal vic nez translaci z jednoho typu souradnic na druhy typ - tam bych popripade hledal chyby, ale zatim u nahodne pootviranych souboru to sedi proti orotofoto mape. K Petr Nejedly wrote: zobrazit citaci
> 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 > >
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

26.11.2007 04:23:30 (#5)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Jakub Sykora napsal(a): zobrazit citaci
> 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 -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

26.11.2007 05:10:34 (#6)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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 Petr Nejedly wrote: zobrazit citaci
> 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 > >
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

26.11.2007 05:20:00 (#7)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
On Nov 26, 2007 5:10 PM, Jakub Sykora <kubajz na kbx.cz> wrote: zobrazit citaci
> 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.

26.11.2007 05:22:25 (#8)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Tak na to koukam - UHUL ty polygony generuje oddelene, takze tady by problem byt nemusel. Otazkou je, jestli vzdy vnejsi polygon generuje jak o prvni. V par souborech, co tu mam to tak je, ale jestli je to pravidlo, to nevim. A porovnavat proti sobe polygony by se mi zrovna nechtelo... K Michal Grézl wrote: zobrazit citaci
> 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
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

26.11.2007 05:25:06 (#9)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Jak jsou na tom renderery, co se tyka teto relace? Zobrazi ji korektne? K Michal Grézl wrote: zobrazit citaci
> 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
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

26.11.2007 08:11:33 (#10)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
On Nov 26, 2007 5:25 PM, Jakub Sykora <kubajz na kbx.cz> wrote: zobrazit citaci
> 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

27.11.2007 07:49:52 (#11)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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 Michal Grézl napsal(a): zobrazit citaci
> 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

27.11.2007 07:51:16 (#12)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Z tohoto prikladu to moc zrejme neni, protoze diru vyplnuje jeste hriste, nicmene udelam to tak a budu verit, ze to bude fungovat :] K Petr Nejedly napsal(a): zobrazit citaci
> 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 > >

27.11.2007 08:04:56 (#13)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
On Nov 27, 2007 7:49 AM, Jakub Sykora <kubajz na kbx.cz> wrote: zobrazit citaci
> 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.

27.11.2007 08:07:22 (#14)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Ono to nakonec dopadne tim nejuniverzalnejsim zpusobem. Budou tam role i polygony budou obracene. K Michal Grézl napsal(a): zobrazit citaci
> 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

27.11.2007 08:52:21 (#15)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> 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

28.11.2007 08:57:00 (#16)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Ahoj, ja tam radeji dam inner a outer, protoze nemuzu z principu zarucit, ze na UHULu maji ta data prave takhle usporadana (i kdyz se to tak zda). Kazdopadne do toho sveho udelatka pridelam na relatko :] K BH napsal(a): zobrazit citaci
>> 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

30.11.2007 08:43:51 (#17)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
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: zobrazit citaci
> 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 Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

30.11.2007 09:26:28 (#18)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Tak jsem zjistil, ze se do nekterych oblasti propasovala nejaka zvlastni chyba. Jedna se o sest duplicitnich bodu s konstantnimi souradnicemi kdesi daleko od nasi zemicky. Skript upravim tak, aby ramcovve kontroloval, zda se data nachazeji nekde ve vymezenem BB a popripade je nenahraval vubec. Chyba bud vznikla tak, ze UHUL sam poskytuje nekorektni data nebo cs2cs udelalo nejakou chybu. Neni trivialni to odstranit dodatecne na uz hotovych datech, protoze body jsou uz soucasti way a ty uz soucasti relaci. Rucne by to taky byl opruz, takze jdu modifikovat skript. K Jakub Sykora wrote: zobrazit citaci
> 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 :] >> >
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

30.11.2007 10:31:56 (#19)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj! zobrazit citaci
> 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

30.11.2007 01:58:24 (#20)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Podle vseho by to mel byt tento: x723388_x1059320_x713388_x1049320.xml.gz ev. dalsi kolem K Pavel Machek wrote: zobrazit citaci
> 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 ''

30.11.2007 05:37:29 (#21)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj! zobrazit citaci
> Podle vseho by to mel byt tento: > > x723388_x1059320_x713388_x1049320.xml.gz > > ev. dalsi kolem
Diky, nalezeno, s pomoci historie v browseru. Vypada to opravdu dobre! Pavel zobrazit citaci
> >> 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 >
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2.12.2007 12:12:29 (#22)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Pavel Machek wrote: zobrazit citaci
> On Fri 2007-11-30 13:58:24, Jakub Sykora wrote: >> Podle vseho by to mel byt tento: >>
http://kubajz.kbx.cz/junk/uhul/output/x723388_x1059320_x713388_x1049320.xml.gz zobrazit citaci
>> >> 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 >
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

3.12.2007 02:26:30 (#23)
gravatar

enemy na mail.muni.cz

<enemy at mail.muni.cz>
115
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

3.12.2007 02:45:22 (#24)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Ahoj, enemy na mail.muni.cz wrote: zobrazit citaci
> 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.
O tomto problemu vim a uz jsem ho nekolikrat nenapadne prezentoval - generalizace vede ke zmenseni datasetu, ale v mnoha pripadech i k drastickemu narustu chyby. Viz data z HELP SERVICE. Pokud nekdo umite data prohnat generalizacnim algoritmem, aby zustala pouzitelne, pak s tim nemam problem. 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. zobrazit citaci
> > Ted je opet otazka jak dal: > > * zlepsi se JOSM tak aby slo pracovat i s tak velkymi datasety?
To nepredpokladam. zobrazit citaci
> * generalizujeme data tak, aby slo dale pracovat a tento vystup nechame na jindy/na jine pouziti mimo hlavni vrstvu JOSM?
Jak na to? zobrazit citaci
> * 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... zobrazit citaci
> * 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... zobrazit citaci
> * cokoliv jineho? > > PS: ctverec opet/jeste obsahuje nulove body v JTSK
Nevim, proc to tak je, ale v UHULu jsou body dobre, vypada to na problem pri transformaci XML UHUL -> Point2D.Double zobrazit citaci
> > ha
Kkkk Kubajz :] zobrazit citaci
> > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

3.12.2007 10:40:39 (#25)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj! zobrazit citaci
> 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?
Doufejme. Bylo by skoda ponicit data jen proto ze josm nestaci. zobrazit citaci
> * vytvorime tematicke vrstvy v JOSM, tak abych treba si > nestahoval/vypnul zobr. lesu, ci zjednodusil vykreslovani se zoomem?
Tohle by bylo dost pekny... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

4.12.2007 09:31:22 (#26)
gravatar

hanoj

<enemy at mail.muni.cz>
115
zobrazit citaci
> 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? zobrazit citaci
>> * 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... zobrazit citaci
>> * 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

4.12.2007 01:55:56 (#27)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Ahoj, hanoj napsal(a): zobrazit citaci
>> 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. zobrazit citaci
> >>> * 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. zobrazit citaci
> > 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).
zobrazit citaci
> > > ha > > hanoj > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz

4.12.2007 01:56:20 (#28)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
enemy na mail.muni.cz napsal(a): zobrazit citaci
> Ahoj, > prave jsem si nahral a vypada to moc pekne: > http://kubajz.kbx.cz/junk/uhul/output/x603388_x1159320_x593388_x1149320.xml.gz
Hmm, kdyz maji dva polygony polecnou hranu (coz je bezny pripad na rozhranni dvou druhu lesa), jsou nody duplikovany (kazdy polygon ma na hrane vlastni nody). Chtelo by to ty nody reusovat. Mimo jine se tim zmensi mnozstvi dat v databazi zobrazit citaci
> > 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.
Ani s vypnutym mappaintem a vypnutymi sipkami? Muj upraveny JOSM to nahral bez zakolisani a bez mappaintu zoomuju i panuju v realnem case. Ale pravda, je to stale jen jeden ctverec, ne vsechna data. Snad se pred vanocema dostanu k navrzeni a obhajeni zmen v trunku JOSM. Zatim jsem nedelal nic tak kontroverzniho... (Hehe, az budu chtit maintainerum vysvetlit, ze ta enkapsulace a striktne privatni fieldy maji neco do sebe, to teprve pujde do tuheho...) zobrazit citaci
> 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?
JOSM vzdy bude mit sve limity. Do editoru se precijen trochu hure implementuje kvadraturni strom, nez do vieweru. zobrazit citaci
> * 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?
Umi snad OSM jako takove tematicke vrstvy? Pravda, do JOSM by sel dopsat importni filtr, co by to prorezal. -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

4.12.2007 02:20:49 (#29)
gravatar

Martin Vidner

<martin.osm at vidner.net>
34
On Dec 4, 2007 1:55 PM, Jakub Sykora <kubajz na kbx.cz> wrote: zobrazit citaci
> 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

4.12.2007 02:23:59 (#30)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Tak vysledne osm mate k dispozici, pokud je nekdo schopen tento filtr udelat, pak neni problem ta data tim prohnat. Neda se ovsem predpokladat, ze vsechny vyplne se nachazeji v jednom ctverci, ale to by se dalo ozelet, popripade otevirat cely nonet, kdyz by to melo byt echt spravne. K Martin Vidner napsal(a): zobrazit citaci
> 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

4.12.2007 06:11:16 (#31)
gravatar

hanoj

<enemy at mail.muni.cz>
115
zobrazit citaci
>>> 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.
*** 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 hanoj

4.12.2007 06:57:16 (#32)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj! zobrazit citaci
> > 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ů)
zobrazit citaci
> takze tudy vede cesta... ale asi by to stejne jeste chtelo generalizovat
Mozna je prvni rozumny krok odstranit duplicitni nody? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

4.12.2007 07:03:57 (#33)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj! zobrazit citaci
> >>> * 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.
"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.) -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

4.12.2007 07:24:57 (#34)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
On Tue 2007-12-04 19:03:57, Pavel Machek wrote: zobrazit citaci
> Ahoj!
zobrazit citaci
> 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.
Jeste jedna vec... cesty/potoky maji tendenci jit po rozhrani porostu (nebo naopak?). Data z UHULu se zdaji byt presnejsi nez GPSka a diky tomu by se ta rozhrani mohla na mapovani lesu dost hodit. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

4.12.2007 09:43:09 (#35)
gravatar

hanoj

<enemy at mail.muni.cz>
115
zobrazit citaci
>>> *** 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.)
*** 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! 2) kdyby byl k dispozici dataset silnic Silnicni databanky ostrava, tak by se asi taky neimportoval cely, pac je kazdy km silnice rozdelen na radove 10 useku. Proste mnohe informace napr. o materialu obrubniku nejspis kazdy nevyuzije... hanoj

5.12.2007 03:02:15 (#36)
gravatar

BH

<singularita at gmail.com>
306
No On 12/3/07, Pavel Machek <pavel na ucw.cz> wrote: zobrazit citaci
> 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 .... zobrazit citaci
> > * 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

5.12.2007 03:07:40 (#37)
gravatar

BH

<singularita at gmail.com>
306
Sedi presne souradnice vnitrniho a vnejsiho polygonu? Potom by sla udelat nejaka lookup table se souradnicemi jako klicem a seznamem polygonu jako hodnotou. Tam nacpu vsechny data, pak prochazim vsechny hodnoty a kde je pro jeden bod vice polygonu, tak tam delam cely test na to, jestli to jde sloucit (ale tech testu pro jeden polygon bude o dost min nez n) Slozitost tohodle pak bude nekde kolem n log n. Pokud by nesedely, tak nasadit treba nejaky quadtree.... Martin On 12/4/07, Jakub Sykora <kubajz na kbx.cz> wrote: zobrazit citaci
> 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 >

5.12.2007 08:23:11 (#38)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
On Dec 5, 2007 3:02 AM, BH <singularita na gmail.com> wrote: zobrazit citaci
> 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).

5.12.2007 01:38:37 (#39)
gravatar

BH

<singularita at gmail.com>
306
No tak ve chvili kdy nekdo nahraje o josm cely svet (rozbalene xml ma tusim asi 35 GB) tak se to asi sesype na libovolnem existujicim pocitaci. JOSM zvlada, jen musi byt vyrez rozumne velky. Co jde udelat je upravit JOSM aby zvladal vice dat najednou, ale nejaky limit tam bude vzdycky a v huste mapovanych oblastech (mesta) bude koncentrace dat na kilometr ctverecni obvykle vyssi, tudiz muzu editovat najednou mensi kus. Ono staci vybrat si maximalni vyrez kolem centra prahy co server posle (0.25 stupne tusim, cela praha se tam nevejde, ale vetsina jo) a uz za soucasneho stavu to v josm jede pomerne pomalu (holt mnozstvi ulic a dalsich veci v mape je pomerne znacne.) Rozhodne bych nezjednodusoval hranice polygonu, maximalne bych zvazil slouceni navazujicich polygonu s ruznymi typy lesa (mt jen "les" by mohlo vetsine lidi stacit, nevim jak moc lidi bude z toho co je v OSM vyrabet treba orientacky mapy nebo mapy porostu :) A rozhodne bych udelal optimalizaci (jako treba vyhazeni duplicitnich nodes a tak ...) Martin On 12/5/07, Michal Grézl <michal.grezl na gmail.com> wrote: zobrazit citaci
> 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 >

9.12.2007 10:16:50 (#40)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj! zobrazit citaci
> > 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...
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). zobrazit citaci
> 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 ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

10.12.2007 12:17:33 (#41)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> 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... zobrazit citaci
> > 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

10.12.2007 01:45:20 (#42)
gravatar

Kubajz

<kubajz at kbx.cz>
618
Ahoj, ja jeste do toho programu udelam indexaci nodu, aby se zamezilo duplicitam, odstranim nulove body JTSK (ktere vznikaji zatim zahadou pri cteni vstupu) a az budu mit novou verzi, tak to opet vrhnu do plena. Nevim ovsem, jestli to stihnu do Vanoc. Mela by tam byt znatelna nodova uspora. Kdyby si nekdo myslel, ze to zvladne driv a chtel na to tlacit, tak zdrojaky stale lezi na webu... 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). S vyskovymi daty maji zkusenosti bratri ze Slovenska http://www.freemap.sk - maji hezky vrstevnicovy model - ovsem je to jen layer v mape a s OSM to nema az moc spolecneho. K BH napsal(a): zobrazit citaci
>> 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 >

10.12.2007 02:02:03 (#43)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> 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).
10x10km bude tak 0.09 stupne krat 0.14 stupne v nasich zemepisnych sirkach. Kdyz jsem zkusil udelat vysek cca 10x10km z centra prahy tak to melo 5.4mb nezkomprimovany a 815kb po aplikaci gzipu. Toliko k hustote dat v centru prahy. Ten vysek je z 50.03,14.35 - 50.14,14.49 Martin

10.12.2007 06:16:27 (#44)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
zobrazit citaci
> > (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
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/

10.12.2007 11:58:07 (#45)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
On Mon 2007-12-10 18:16:27, Michal Grézl wrote: zobrazit citaci
> > > (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.
zobrazit citaci
> 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/
Da se neco z toho nahrat do josm jako podklad? V kopcovatym terenu gpsky moc nefungujou :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

11.12.2007 11:42:26 (#46)
gravatar

hanoj

<enemy at mail.muni.cz>
115
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

11.12.2007 12:30:27 (#47)
gravatar

Jachym Cepicky

<jachym.cepicky at gmail.com>
414 93
skoro mam pocit, ze OpenLayers na editaci by byly lepsi, nez ten josm .. jenom kde vzit cernocha (cas), aby to napsal? j hanoj píše v Út 11. 12. 2007 v 11:42 +0100: zobrazit citaci
> 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
-- Jachym Cepicky e-mail: jachym.cepicky na gmail.com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub ------------- další část --------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Toto je digitálně podepsaná část zprávy URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20071211/d75fe0ea/attachment.sig>

11.12.2007 01:35:48 (#48)
gravatar

Martin Vidner

<martin.osm at vidner.net>
34
On Dec 11, 2007 11:42 AM, hanoj <enemy na mail.muni.cz> wrote: zobrazit citaci
> 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

11.12.2007 01:37:36 (#49)
gravatar

Kubajz

<kubajz at kbx.cz>
618
Takze to dopadne tak, jak jsem puvodne navrhoval? Zridit cesky OSM server se slippy map a nekolika vrstvami? K Martin Vidner napsal(a): zobrazit citaci
> 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 >

11.12.2007 11:04:12 (#50)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
On Tue 2007-12-11 11:42:26, hanoj wrote: zobrazit citaci
> 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. zobrazit citaci
> 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

12.12.2007 12:48:08 (#51)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> > 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.
Jsou lidi co slippymap nemaj, nebo jim nefunguje nebo o tomhle netusi zobrazit citaci
> > 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).
Vetsi vysek Prahy (teda skoro celou Prahu) to vcelku zvlada, pokud neni odzoomovano moc daleko. Kdyby se aspon lehce zoptimalizovalo vykreslovani (nekreslit sipky u car kratsich nez treba 10 pixelu) tak to bude zvladat vcelku v pohode, ale zase pokud je najednou videt 100000 car, tak to asi nikdy nebude nejak hvezdne rychly. zobrazit citaci
> Blby je, ze kdyz nechame uhul data jen "nekde vedle", tak bude > potreba: > > 1) upravit mapu na openstreetmap.org aby to zobrazovala
Asi vcelku nerealny. Ted tam jako needitovatelna (a v JOSM tudiz neviditelna) vrstva jsou akorat obrysy oceanu, ale pokud by zacaly pribyvat, tak jednak v tom bude chaos, jednak budou lidi nastvany, ze chteli u toho lesa primapovat treba vesnici co tam je ale nemuzou ten les v JOSM najit. Dalsi obrovska nevyhoda je, ze kdyz si nekdo vezme dump ze si zprovozni OSM jinde, treba u sebe na lokale, tak tyhle extra data mit nebude a najednou mu v mape pul veci chybi. zobrazit citaci
> 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).
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 .... ) Realne by to dopadlo tak, ze vetsina nastroju by UHUL proste neumela. zobrazit citaci
> ...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.
Lepsi je zrychlit JOSM... zobrazit citaci
> > 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.
Kdyby se na serveru implementovaly filtry (chci vysek 50Km na vysocine, ale chci jen silnice a zeleznice a ne lesy a vodstvo) Tak mne napada ... neslo by tohle udelat do JOSM? lesy se pri zobrazeni odfiltrujou (= patricne cary se schovaji a nebudou prekazet) a edituje se zeleznice jako by tam nebyly ... nekdo jiny si zas treba odfiltruje silnice nebo neco co ho treba aktualne nezajima. Pridal by se nastavitelny filtr, par presetu (zapinatelne a vypinatelne "vrstvy" s lesy, silnicemi, vodstvem ....) a tohle by se tim vyresilo. Martin

12.12.2007 01:19:34 (#52)
gravatar

noone02

<noone02 at centrum.cz>
28
Pavel Machek napsal(a): zobrazit citaci
> 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.

12.12.2007 01:52:53 (#53)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> 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.
Tak v okoli vetsich mest (Praha, Brno, Plzen ...) bych je naimportoval uz ted (tam ty data moc nenarostou, kdyz vetsina dat je prave ulice dotycneho mesta ... ) Martin

12.12.2007 02:00:45 (#54)
gravatar

Martin Vidner

<martin.osm at vidner.net>
34
On Dec 12, 2007 12:48 PM, BH <singularita na gmail.com> wrote: zobrazit citaci
> > 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 .... )
To je prece samozrejmost, ze API ma zustat stejne. Meni se jen URL zdroje. A co se poucit u Slovaku? Ja jsem to pochopil tak, ze vrstevnice maji mimo OSM. http://www.freemap.sk/ Martin

12.12.2007 11:20:30 (#55)
gravatar

hanoj

<enemy at mail.muni.cz>
115
zobrazit citaci
> 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. zobrazit citaci
> 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

13.12.2007 01:56:51 (#56)
gravatar

noone02

<noone02 at centrum.cz>
28
hanoj napsal(a): zobrazit citaci
> 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 > > >
Pentium4 3.4Ghz; 2Gb RAM; Gentoo; Java 1.6; JOSM 352+vmsplugin+zapnute sipky jen mapovy list a naznaky zpomaleni pri posunu mapy pozoruji az od cca 550m zoomu ... uchopeni nodu/posun select/podsviceni je okamzite do 800m. Pokud vypnu sipky zpomaleni az kolem 2 km zoomu. Kdyz bych si chtel editovat 700km cestu po Holandsku (mapa je tam hodne husta) tak stejne nema smysl zatezovaty systemy tim ze si v JOSM mohu celou cestu prohlednout, nehlede na to ze bych spise zanesl nepresnosti a tak stale dokola dalsi a dalsi kdo po stejne ceste bude projizdet. Vybral jsem mista kde jsem udelal fotky, ty si otevrel a upravil - problem s tim, ze dat bylo hodne nebyl. JOSM je s hodne datama pomaly to je fakt a to ze ma nekdo slabsi PC jej nemuze vyrazne omezovat, tzn se na tomto smeru bude muset urcite zapracovat. Me by vyhovovalo data importovat, ale z pohledu cele CR urcite ne, to ma Hanoj pravdu. Jestli se mi to nezda tak stejna situace je i v nemecku kde jsou take importovany jen casti lesu, kde jsou maperi. NoOne

13.12.2007 10:04:44 (#57)
gravatar

Jakub Sykora

<kubajz at kbx.cz>
618
Me se zatim nejvic libila myslenka udelat do JOSMu filtr na zobrazovana/zpracovavana data. Podle me by to resilo problem okamzite a nejen problem s lesy, ale problem velkeho mnozstvi dat obecne. Napriklad, kdyz bych vedel, ze budu upravovat jen zeleznice, muzu s klidem skoro zbytek veci vypnout - resp. vypnout/zapnout podle potreby. K hanoj wrote: zobrazit citaci
> > 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
-- Jakub Sýkora email: kubajz na kbx.cz <') ICQ: 68976632 ( =- mobil: +420 777 594 201 ''

13.12.2007 02:30:30 (#58)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
zobrazit citaci
> > 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.
To porad neresi veci jako mapit. zobrazit citaci
> > 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
Ok, zjistime. Ja mam po ruce thinkpad x60 a list -rw-r--r-- 1 pavel pavel 16M Dec 11 00:10 /tmp/delme_x703388_x1169320_x693388_x1159320.xml Startup je ~39 sekund, nic moc zobrazit citaci
> zoom zobrazeni z fullextent na ctverec listu 11 sekund
posun zobrazeni kdyz je zobrazeny vsechno -- 18 sek. (Sipky zapnuty). Kdyz sipky vypnu je to <2 sekundy. zobrazit citaci
> zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) > posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m
Posun obrazu v meritku 250m je v realnym case -- presneji je tam tak 250msec zavahani. Posun obrazu v meritku 863m je <500msec. V meritku 1.8km je to kolem dvou sekund. zobrazit citaci
> uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m
Posun nodu je v realnym case. zobrazit citaci
> select jedne area a jeji vysviceni 4 sekundy v meritku 250m
Select jedny oblasti je taky v realnym case. zobrazit citaci
> 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. c) pavel na amd:~$ java -version java version "1.5.0_09" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) Java HotSpot(TM) Server VM (build 1.5.0_09-b03, mixed mode) pavel na amd:~$ d) CPU Genuine Intel(R) CPU T2400 @ 1.83GHz, 2GB RAM Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

13.12.2007 11:20:00 (#59)
gravatar

hanoj

<enemy at mail.muni.cz>
115
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 a NELZE s nim samotnym realnem case pracovat. Odezvy jsou jak ze zahrobi v nekolika sekundach az po desitky, byt je asi podstane rychlejsi nez muj domaci stroj s linuxem. Opakuji: JOSM neni pripraven na import lesa v dnesni podobe. 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 ha hanoj

14.12.2007 02:41:50 (#60)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> > 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. Plus tam mam jeste -Xmx512m (bez toho to padalo na nedostatek pameti pri tahani vetsiho mnozstvi snimku z yaghoo nebo uhulu) zobrazit citaci
> a) Co je mappaint? Ja zadny balicek na kresleni neinstaloval, pouzivam > to co je v josm defaultne.
Alternativni vykreslovaci balicek. Kresli cary barevne (silnice sede/zlute/cervene dle vyznamnosti, reky modre, atd .... ) a s ruznou tloustkou nebo vzorem. Ma to nevyhodu, ze ty barvy v defaultnim nastaveni se tloucou se satelitnim podkladem (takz to pak treba neni videt, takova seda cara pres sedou silnici v uhulu moc kontrastni neni ....) a nejde bez restartu JOSM prepinat aspon docasne zpet do defaultniho vykreslovani. zobrazit citaci
> b) josm verse 350 z 2007-10-07.
Ted uz je novejsi :) Martin

14.12.2007 08:41:35 (#61)
gravatar

hanoj

<enemy at mail.muni.cz>
115
zobrazit citaci
>>> 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

14.12.2007 09:50:01 (#62)
gravatar

Kubajz

<kubajz at kbx.cz>
618
Podle meho nazoru se nema cenu prit o tom, s jak velkym datasetem je JOSM pouzitelny na kterem stroji. Porad se mi ze vsech navrhu zda nejlepsi udelat filtr na data do JOSM. Potlach se asi moc nezpomali, pac ten pouziva uplne jiny pristup a formu dat nez JOSM. Co jsem vypozoroval, tak nektere starsi verze mappaintu hodne zpomalovaly, protoze byly spatne napsane. U novejsich uz jsem to toliko nepozoroval. K hanoj napsal(a): zobrazit citaci
>>>> 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 >

14.12.2007 04:26:38 (#63)
gravatar

Michal Grézl

<michal.grezl at gmail.com>
231
Zkousel ste nekdo merkator? Je to napsane v qt4, me se to nejak nepodarilo zatim zkompilovat, ale mohla by to byt zajimava alternativa.

14.12.2007 06:09:49 (#64)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> Zkousel ste nekdo merkator? Je to napsane v qt4, me se to nejak > nepodarilo zatim zkompilovat, ale mohla by to byt zajimava > alternativa.
Zkousel, ale neumel zobrazovat podklady z WMS, takze jsem pak presel na JOSM. Ten je zatim dal co se mnozstvi implementovanych features tyce. Martin

15.12.2007 03:03:43 (#65)
gravatar

noone02

<noone02 at centrum.cz>
28
BH napsal(a): zobrazit citaci
> 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.

15.12.2007 10:39:13 (#66)
gravatar

Kubajz

<kubajz at kbx.cz>
618
Ta nezapadla. Psal jsem, ze do noveho importu to udelam. K noone02 napsal(a): zobrazit citaci
> 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 >

16.12.2007 01:11:37 (#67)
gravatar

Pavel Machek

<pavel at ucw.cz>
1066 1226
Ahoj! zobrazit citaci
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ zobrazit citaci
> mapset: x703388_x1169320_x693388_x1159320.xml ktery ma 16 MB rozbaleny
zobrazit citaci
> 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)==>
Ale jo, myslim ze staci vypnout mappaint a validator...? Protoze tady to na stejnym hardwaru bezi o poznani slusneji. zobrazit citaci
> 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
Myslim, ze je skoda, ze v Praze chybi zelena tam kde ma byt Sarka, a podobne. Krok 0 je jasny -- vyhazet z lesu duplicitni nody. Pak bych se primlouval za import v lesu v Praze -- Praha je celkem zmapovana ale ty lesy tam proste chybej. Pokud chcem byt opatrny, tak mozna dava smysl pred Prahou importovat treba okoli Rican -- lesu je tam pozehnane a jestli se maj projevit nejaky problemy, je mozna malinko lepsi at se obevej tam a ne v Praze. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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