Import Lesu

55 zpráv
Zpět na přehled

Import Lesu

55 zpráv KJPJBMPP 12 účastníků 35 min čtení
  1. Pavel Machek pavel na ucw.cz #m00f3f9
    Ahoj! Schyluje se nejak k importu lesu? Javou nevladnu, takze tam asi s vyhazenim duplicit nepomuzu, ale postprocesor ve skriptovacim jazyce bych zvladnout mel... Pavel
  2. Kubajz kubajz na kbx.cz #m7d6ebf
    Ahoj, postprocessing by byl zdlouhavy a zbytecne pracny. Zavedu indexaci primo v importeru. Odstavil jsem se ted na chvili. Delam do skoly a jak budu moci, tak to dodelam. Uz jsem taky uspesne stihl zapomenout, jak vlastne dopadla diskuze o importu. Mam pocit, ze tak, ze udelam novou varku dat a ty se pak naimportuji, pokud nebude pripominek. K
  3. Pavel Machek pavel na ucw.cz #m8dc363
    Ahoj!
    postprocessing by byl zdlouhavy a zbytecne pracny. Zavedu indexaci primo v importeru. Odstavil jsem se ted na chvili. Delam do skoly a jak budu
    Ok.
    moci, tak to dodelam. Uz jsem taky uspesne stihl zapomenout, jak vlastne dopadla diskuze o importu.
    Myslim ze import "zajimavych" casti uzemi by nemel byt problem.
    Mam pocit, ze tak, ze udelam novou varku dat a ty se pak naimportuji, pokud nebude pripominek.
    Dej vedet az budou data ;-). Pavel
  4. Pavel Machek pavel na ucw.cz #mc4ef48
    Ahoj! ...pokrocil nejak? Myslim ze by bylo pekne uploadnout aspon "huste zmapovane" oblasti -- treba lesy v Praze... Takhle je mapovat prazsky lesy/parky dost demotivujici -- k dispozici jsou nejspis lepsi data -- ale pravdepodobne ani ty "lepsi" data nebudou dokonaly... bylo by fajn je tam mit at se daj opravovat chyby etc... Pavel
  5. Pavel Machek pavel na suse.cz #m5a33ec
    Ahoj! Kdyz tak koukam na slovenskou freemap.sk... neni cas udelat ten import lesu? Na slovensku lesy maji, a diky nim mapa vypada jako mapa, a ne jako plan mesta... Pavel
  6. Jiri Klement jiri.klement na gmail.com #m3d97d2
    S lesy by mapa vypadala opravdu daleko lepe. Neprijemne ale je, ze josm se neunosne zpomali, kdyz mapa obsahuje nejake vetsi plochy. Je na to nejake reseni, krome pouziti Wireframe View?
  7. Michal Grézl michal.grezl na gmail.com #mcc0b49
    2008/5/15 Jiri Klement <jiri.klement na gmail.com>:
    S lesy by mapa vypadala opravdu daleko lepe. Neprijemne ale je, ze josm se neunosne zpomali, kdyz mapa obsahuje nejake vetsi plochy. Je na to nejake reseni, krome pouziti Wireframe View?
    nahrat mensi kousek protlacit josm-ng do josm, nebo iniciovat zmeny v josm, napriklad selektivni download nebo neco takoveho. koupit si lepsi pocitac Bude se jeste nejak ten export lesu z uhulu menit, nebo to zustane v takove podobe v jake to je ted? Hodlam si naimportovat kousek kolem meho bydliste, teda az ho najdu:)
  8. Kubajz kubajz na kbx.cz #mbf1056
    Ahoj, kvuli hustemu nedostatku casu jsem na to nemel vubec cas a vykaslal jsem se na to. Podivam se, jak se zmenila situace na UHULu (pokud vubec) a predelam ten importer tak, aby generoval spravna data pro OSM vcetne relaci a indexace bodu, abychom jich tam nemeli miliardu ale jenom pul miliardy. K
  9. Jachym Cepicky jachym.cepicky na gmail.com #m1e211f
    Indexace bodu, co to je? Coz takhle generalizace? j
  10. Kubajz kubajz na kbx.cz #mec9ef2
    Soucasny skript nezohlednuje duplicitu bodu a zavede klidne dva stejne. Indexaci jsem mel namysli to, ze se bude drzet tabulka bodu (index) v pameti po celou dobu zpracovani lesu a bude se napred zkoumat, zda bod uz v indexu neni, nez se vybleje do .osm souboru. K
  11. Jachym Cepicky jachym.cepicky na gmail.com #m81cfdd
    ok a co ta generalizace ? tim by se dala data jeste zmensit pri zachovani pouzitelnosti.... j 2008/5/15 Kubajz <kubajz na kbx.cz>:
  12. Kubajz kubajz na kbx.cz #m8d4f35
    Generalizaci bych provadel rucne. Kdyz to udelame strojove, muze to dopadnout spatne. Myslim, ze takhle znela dohoda. Kazdy zacne importovat casti, ktere spadaji pod jeho pusobnost a "nezajimava" mista pak muzeme streba prohnat generalizaci, ale spis bych to nedelal. K
  13. Jachym Cepicky jachym.cepicky na gmail.com #maba426
    bavime se o stejne mape lesu? nedovedu si predstavit "rucni" generalizaci. naopak generalizace za pouziti nejakeho pouzitelneho algoritmu vede k velice zajimavym vysledkum - za virazne mensi vklad cloveci prace j 2008/5/15 Kubajz <kubajz na kbx.cz>:
  14. Jiri Klement jiri.klement na gmail.com #mf1b8a5
    S lesy by mapa vypadala opravdu daleko lepe. Neprijemne ale je, ze josm se neunosne zpomali, kdyz mapa obsahuje nejake vetsi plochy. Je > na to nejake reseni, krome pouziti Wireframe View?
    koupit si lepsi pocitac
    Ja mam dobry pocitac :-) Ukazalo se, ze pomala byla pouze verze josm z gentoo (621). Aktualni verze (639) je daleko rychlejsi.
  15. Petr Nejedly Petr.Nejedly na Sun.COM #mf8a3f5
    Soucasny skript nezohlednuje duplicitu bodu a zavede klidne dva stejne. Indexaci jsem mel namysli to, ze se bude drzet tabulka bodu (index) v pameti po celou dobu zpracovani lesu a bude se napred zkoumat, zda bod uz v indexu neni, nez se vybleje do .osm souboru. K
    Indexace bodu, co to je? Coz takhle generalizace?
    ... by rozhodne byla na miste. Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu. Zachovanim pouze obalovych krivek lesa by se velikost datasetu redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat. Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude ~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad 2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit. Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit. Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org Opravdu chceme mit podrobnejsi mapu lesu nez treba silnic? Patri do mapy treba vsechny budovy? (>2M domu -> >12M OSM primitiv, potencialni import z katastru, pokud by licence povolila) "Ostatni" mapy ty budovy maji (bitmapove), viz nahodne: http://www.mapy.cz/#x=129562992 na y=136523456 na z=16 na mm=ZRP Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
  16. Kubajz kubajz na kbx.cz #m9345d7
    Ahoj, a mas nejaky vyuzitelny algoritmus a nejlepe i jeho implementaci v Jave? Zkusili bychom, co to s temi daty provede :) K
  17. Michal Grézl michal.grezl na gmail.com #mb1c101
    2008/5/15 Petr Nejedly <Petr.Nejedly na sun.com>:
    Soucasny skript nezohlednuje duplicitu bodu a zavede klidne dva stejne. Indexaci jsem mel namysli to, ze se bude drzet tabulka bodu (index) v pameti po celou dobu zpracovani lesu a bude se napred zkoumat, zda bod uz v indexu neni, nez se vybleje do .osm souboru. K
    Indexace bodu, co to je? Coz takhle generalizace?
    ... by rozhodne byla na miste. Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu. Zachovanim pouze obalovych krivek lesa by se velikost datasetu redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat. Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude ~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad 2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit. Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit. Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org Opravdu chceme mit podrobnejsi mapu lesu nez treba silnic?
    Chceme podrobnou mapu, at uz cest, silnic, potoku, nebo buhvi ceho vseho jeste, ovsem ja osobne nepotrebuju vedet jestli jsem ve smrkove jedline nebo jedlove smrcine, me staci vedet ze jsem v lese.
    Patri do mapy treba vsechny budovy? (>2M domu -> >12M OSM primitiv, potencialni import z katastru, pokud by licence povolila) "Ostatni" mapy ty budovy maji (bitmapove), viz nahodne: http://www.mapy.cz/#x=129562992 na y=136523456 na z=16 na mm=ZRP Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
    moc jich uz neni co by jeste sli, ale strasne bych chtel vodstvo:) si nedovedete predstavit jak nasere kdyz nekam jdete a najednou je pres cestu potok co je sice prtavej nepodstatnej a neni videt z ortofota ale vam se rozhodne nechce brodit.
  18. Jiri Klement jiri.klement na gmail.com #m3114b8
    Zkusili jste porovnavat exportovane lesy s ortofotem? Docela casto se to rozchazi, treba i o destky metru. Takze myslim ze nema smysl data importovat prilis presne. Pokud odstraneni bodu posune les do 5 metru, tak je to myslim ok. Rozdeleni podle typu porostu bych uplne zrusil. Pro lidi co je to zajima pravdepodobne UHUL nabizi WMS.
  19. Jachym Cepicky jachym.cepicky na gmail.com #mc76d49
    Souhlasim, IMHO OSM by nemelo suplovat funkci UHULa jakozto narodniho spravce a garanta vsech dat o lesich. Jde jenom o zobrazeni dat s urcitou presnosti. BTW: "Pravda" neni to, co ukazuje ortofoto, ale to, co ukazuji mapy UHUL (pravne vzato). Samozrejme hraje roli doba porizeni dat Jachym 2008/5/15 Jiri Klement <jiri.klement na gmail.com>:
    Zkusili jste porovnavat exportovane lesy s ortofotem? Docela casto se to rozchazi, treba i o destky metru. Takze myslim ze nema smysl data importovat prilis presne. Pokud odstraneni bodu posune les do 5 metru, tak je to myslim ok. Rozdeleni podle typu porostu bych uplne zrusil. Pro lidi co je to zajima pravdepodobne UHUL nabizi WMS.
    Soucasny skript nezohlednuje duplicitu bodu a zavede klidne dva stejne. Indexaci jsem mel namysli to, ze se bude drzet tabulka bodu (index) v > pameti po celou dobu zpracovani lesu a bude se napred zkoumat, zda bod > uz v indexu neni, nez se vybleje do .osm souboru. K
    Indexace bodu, co to je? Coz takhle generalizace?
    ... by rozhodne byla na miste. Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu. Zachovanim pouze obalovych krivek lesa by se velikost datasetu redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat. Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude ~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad 2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit. Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit. Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org Opravdu chceme mit podrobnejsi mapu lesu nez treba silnic? Patri do mapy treba vsechny budovy? (>2M domu -> >12M OSM primitiv, potencialni import z katastru, pokud by licence povolila) "Ostatni" mapy ty budovy maji (bitmapove), viz nahodne: http://www.mapy.cz/#x=129562992 na y=136523456 na z=16 na mm=ZRP Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
    j
    Ahoj, kvuli hustemu nedostatku casu jsem na to nemel vubec cas a vykaslal jsem >>> se na to. Podivam se, jak se zmenila situace na UHULu (pokud vubec) a >>> predelam ten importer tak, aby generoval spravna data pro OSM vcetne >>> relaci a indexace bodu, abychom jich tam nemeli miliardu ale jenom pul >>> miliardy. K
    Ahoj! ...pokrocil nejak? Myslim ze by bylo pekne uploadnout aspon "huste >>>> zmapovane" oblasti -- treba lesy v Praze... Takhle je mapovat prazsky lesy/parky dost demotivujici -- k dispozici >>>> jsou nejspis lepsi data -- ale pravdepodobne ani ty "lepsi" data >>>> nebudou dokonaly... bylo by fajn je tam mit at se daj opravovat chyby >>>> etc... Pavel >>>>
    _______________________________________________ http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>
    _______________________________________________ http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
    http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
    -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
  20. Petr Schonmann PSBOX na seznam.cz #m185ebf
    To bude timto http://josm.openstreetmap.de/changeset/631 ## ------------ Původní zpráva ------------ ## Od: Jiri Klement <jiri.klement na gmail.com> ## Předmět: Re: [Talk-cz] import lesu ## Datum: 15.5.2008 13:57:40 ## ---------------------------------------- ## > > S lesy by mapa vypadala opravdu daleko lepe. Neprijemne ale je, ze ## > > josm se neunosne zpomali, kdyz mapa obsahuje nejake vetsi plochy. Je ## > > na to nejake reseni, krome pouziti Wireframe View? ## ## > koupit si lepsi pocitac ## Ja mam dobry pocitac :-) ## ## Ukazalo se, ze pomala byla pouze verze josm z gentoo (621). Aktualni ## verze (639) je daleko rychlejsi. ## ## -- ## Jiri Klement ## ## _______________________________________________ ## http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ###### ---- S pozdravem Petr Schonmann Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
  21. Pavel Machek pavel na suse.cz #md8574a
    Ahoj!
    Patri do mapy treba vsechny budovy? (>2M domu -> >12M OSM primitiv, potencialni import z katastru, pokud by licence povolila) "Ostatni" mapy ty budovy maji (bitmapove), viz nahodne: http://www.mapy.cz/#x=129562992 na y=136523456 na z=16 na mm=ZRP Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
    moc jich uz neni co by jeste sli, ale strasne bych chtel vodstvo:) si nedovedete predstavit jak nasere kdyz nekam jdete a najednou je pres cestu potok co je sice prtavej nepodstatnej a neni videt z ortofota ale vam se rozhodne nechce brodit.
    :-). Jo, vodstvo je opravdu dulezity... Dal se hodej vrstevnice... jenze u tech neni ani jasny jak je vlastne v josm udelat. Pavel
  22. Jiri Klement jiri.klement na gmail.com #ma3ed13
    Vrstevnice nema smysl kreslit, jsou volne k dispozici z nejakeho satelitu. Na normalni mape nejsou hlavne proto, ze png s vrstevnicema se spatne komprimuje.
  23. Pavel Machek pavel na suse.cz #m9d3c7b
    Ahoj!
    Vrstevnice nema smysl kreslit, jsou volne k dispozici z nejakeho satelitu. Na normalni mape nejsou hlavne proto, ze png s vrstevnicema se spatne komprimuje.
    ...no, volne k dispozici v nejakem dost nepouzitelnem rozliseni, pokud si vzpominam. A chapu ze kreslit vrstevnice nema smysl, ale _neco_ na ukladani vyskovych dat by se myslim hodilo. Pavel
  24. BH singularita na gmail.com #mc77555
    Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu. Zachovanim pouze obalovych krivek lesa by se velikost datasetu redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat. Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude ~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad 2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit. Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit. Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org
    Takhle podrobna data (t.j. rozdeleni dle typu lesa by vyuzili nejspis jen lesnici (ti si to ale budou spise tahat rovnou z UHULu) a pak lidi vyrabejici mapy na orientacni beh - jenze jednak ti si to muzou stahnout z UHULu sami, jednak stejne musi do lesa aby zmapovali "kazdicky sutr v lese" :) IMHO pouze ty obalove krivky budou asi stacit :)
    Opravdu chceme mit podrobnejsi mapu lesu nez treba silnic?
    Spravnym resenim tohoto "problemu" neni zjednoduseni mapy lesu, ale zlepseni mapy silnic :)
    Patri do mapy treba vsechny budovy? (>2M domu -> >12M OSM primitiv, potencialni import z katastru, pokud by licence povolila) "Ostatni" mapy ty budovy maji (bitmapove), viz nahodne: http://www.mapy.cz/#x=129562992 na y=136523456 na z=16 na mm=ZRP
    Budovy urcite. Kazda vetsi budova (= maly rodinny domek a vetsi) je orientacni bod ktery by v podrobne mape nemel chybet. V mestech z toho je dobre ze clovek vidi co tak zhruba je mezi temi ulicemi (zdali neco na styl rodinnych domku nebo jednolita zastavba), v krajine muzou byt osamele budovy dulezite orientacni body. Mensi budovy (zastavky MHD, telefonni budky, stanky s novinama apod.) lze mapovat bodove. 12M OSM primitiv neni zas tolik :) Samozrejme je otazkou, odkud ty budovy sehnat ... zatim asi jedina realna moznost je kreslit je rucne podle UHULu nebo Yahoo.
    Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
    Vodstvo? Silnice 3. tridy? Hranice okresu/kraju/atd? Cyklostezky? Turisticke trasy? Cokoliv zajimaveho, co kdo vyhrabe s licenci umoznujici import a ma to rozumnou velikost :) Martin
  25. BH singularita na gmail.com #m92a2e4
    ...no, volne k dispozici v nejakem dost nepouzitelnem rozliseni, pokud si vzpominam. A chapu ze kreslit vrstevnice nema smysl, ale _neco_ na ukladani vyskovych dat by se myslim hodilo.
    Tusim 90m rozliseni pro cely svet: http://www.vterrain.org/Elevation/SRTM/ Nekde existuje program, ktery z toho vygeneruje vrstevnice. Co se tyce "neceho na ukladani vyskovych dat, nekde se to uz probiralo a dospelo se k tomu, ze vetsina lidi by nebyla schopna do toho dodavat dostatecne presna data. Obzvlaste blbe by pak bylo pokryti mist, kam nevedou zadne cesty (hory a kopce v CHKO apos.) Neco by slo mozna dostat vyimportovanim tracklogs (pokud obsahuji i udaje o nadmorske vysce) a nejakou interpolaci/extrapolaci spolu s 90m SRTM daty z toho vyrobit presnejsi vyskova data, ale nevim nevim ... Martin
  26. Jiri Klement jiri.klement na gmail.com #mabeef0
    Ale budovy predpokladam nikdo nekresli. Dival jsem se na www.mapy.cz a www.amapy.cz a v obou pripadech to vypada, ze budovy byly automaticky ziskany z ortofota. Nevim jestli by bylo mozne importovat z katastru, je v nem dost zmatek, spousta budov uplne chybi.
  27. Petr Nejedly Petr.Nejedly na Sun.COM #m345e16
    Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu. Zachovanim pouze obalovych krivek lesa by se velikost datasetu redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat. Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude ~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad 2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit. Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit. Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org
    Takhle podrobna data (t.j. rozdeleni dle typu lesa by vyuzili nejspis jen lesnici (ti si to ale budou spise tahat rovnou z UHULu) a pak lidi vyrabejici mapy na orientacni beh - jenze jednak ti si to muzou stahnout z UHULu sami, jednak stejne musi do lesa aby zmapovali "kazdicky sutr v lese" :) IMHO pouze ty obalove krivky budou asi stacit :)
    Opravdu chceme mit podrobnejsi mapu lesu nez treba silnic?
    Spravnym resenim tohoto "problemu" neni zjednoduseni mapy lesu, ale zlepseni mapy silnic :)
    Zajiste. Doplnit silnicni sit osobne povazuju za primarni. RSD export spolu s funkcnim UHUlem je pro dany ucel uzasny nastroj.
    12M OSM primitiv neni zas tolik :)
    Cela czechia.osm ma zatim stale <1M primitiv...
    Samozrejme je otazkou, odkud ty budovy sehnat ... zatim asi jedina realna moznost je kreslit je rucne podle UHULu nebo Yahoo.
    Oslovit katastr? Rucne podle jejich WMS by slo mnohem lepe nez dle UHULu, ale katastr ma ty data urcite i nejak vektorove. Alespon co jsem zanasel svuj dum do katastru, daval jsem jim dost presna data v Krovakovi ;-)
    Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
    Vodstvo? Silnice 3. tridy? Hranice okresu/kraju/atd? Cyklostezky? Turisticke trasy? Cokoliv zajimaveho, co kdo vyhrabe s licenci umoznujici import a ma to rozumnou velikost :)
    Ulicni sit? Nekdo tu chtel prokladat polygony mezi body z uir_adr a tim generovat hint. Nejaky pokrok?
  28. Jachym Cepicky jachym.cepicky na gmail.com #m75b3ea
    Vrstevnice by se nechaly odvodit ze SRTM - jsou tam data s rozlisenim 30m. Kdyby byl zajem, asi bych to dokzal pripravit Nebo zkusit ukecat Geodis, aby pustili napr. vrstevnice po 20m. Maji vlastni digitalni model terenu a jsou v tom fakt dobry. Dalsi moznost, nad kterou uz jsem uvazoval, kdyby vsechny tracky v OSM byly 3D, nechal by se nejakej model vygeneraovat z nich. Ale to by bylo asi hodne nepresny. Jachym
    Ahoj!
    Patri do mapy treba vsechny budovy? (>2M domu -> >12M OSM primitiv, potencialni import z katastru, pokud by licence povolila) "Ostatni" mapy ty budovy maji (bitmapove), viz nahodne: http://www.mapy.cz/#x=129562992 na y=136523456 na z=16 na mm=ZRP Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
    moc jich uz neni co by jeste sli, ale strasne bych chtel vodstvo:) si nedovedete predstavit jak nasere kdyz nekam jdete a najednou je pres cestu potok co je sice prtavej nepodstatnej a neni videt z ortofota ale vam se rozhodne nechce brodit.
    :-). Jo, vodstvo je opravdu dulezity... Dal se hodej vrstevnice... jenze u tech neni ani jasny jak je vlastne v josm udelat. Pavel
    -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
  29. Tomáš Tichý t.tichy na post.cz #mfb736e
    Nad SRTM neni treba badat, uz to udelali jini :-) Vrstevnice je mozne prevest do OSM nastrojem Srtm2OSM: http://wiki.openstreetmap.org/index.php/Srtm2Osm A nebo je mozne je rederovat primo v mapniku (pouziva Cyclemap a OPM): http://wiki.openstreetmap.org/index.php/Contours_on_the_Cycle_Map =TT= 2008/5/15 Jachym Cepicky <jachym.cepicky na gmail.com>:
  30. Pavel Machek pavel na suse.cz #mcc0dd6
    Ahoj!
    Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu. Zachovanim pouze obalovych krivek lesa by se velikost datasetu redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat. Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude ~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad 2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit. Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit. Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org
    Takhle podrobna data (t.j. rozdeleni dle typu lesa by vyuzili nejspis jen lesnici (ti si to ale budou spise tahat rovnou z UHULu) a pak lidi vyrabejici mapy na orientacni beh - jenze jednak ti si to muzou stahnout z UHULu sami, jednak stejne musi do lesa aby zmapovali "kazdicky sutr v lese" :) IMHO pouze ty obalove krivky budou asi stacit :)
    ...no, a pak turisti / houbari / jezdci na konich... "jak dlouho se jeste budem prodirat touhle houstinou?"... "je tohle starsi smrkovy les kterym jde projit, nebo mlady hustnik?"... Pavel
  31. BH singularita na gmail.com #mcacc10
    12M OSM primitiv neni zas tolik :)
    Cela czechia.osm ma zatim stale <1M primitiv...
    Porovnaval bych to spis s tim, kolik by mela czechia.osm az bude "kompletni" (dejme tomu vsechny silnice treti tridy, vsechny mensi mistni silnice, vsechny reky a vetsi rybniky a vsechny zeleznice a vyznamne budovy (kostely, pamatky, nadrazi, ....)) - to pak bude o dost vice nez 1M primitiv (10M? 20M) a pridat do toho dalsich 12M uz to tak nenafoukne a zvedne to kvalitu mapy... Navic, nektere budovy uz v OSM jsou (hlavne v Praze), byt je to jen maly zlomek tech co by tam mohly byt :) Martin
  32. BH singularita na gmail.com #m16b9d2
    ...no, a pak turisti / houbari / jezdci na konich... "jak dlouho se jeste budem prodirat touhle houstinou?"... "je tohle starsi smrkovy les kterym jde projit, nebo mlady hustnik?"...
    Import je jedna vec. Druha vec je, ze bychom to pak museli updatovat aby to melo nejakou hodnotu. Orientacka mapa se zakreslenymi porozty pokud je stara 10 let, uz tam porosty na mnoha mistech nesedi a na 20 let stare nesedi skoro nic. I behem 5 let se casto v lese odehraje dost zmen (mensi stromky o neco povyrostou, tamhle se neco pokaci a udela nova paseka ...) Mne osobne by se libilo to tam nacpat "v plnych detalech" ale mam dve starosti: Utahne to system? Mineno jak databaze openstreetmap, tak lidi co si vyzadaj kus mapy pres josm nebo jiny editor a chtej tam neco domalovat. Kdo to bude udrzovat? Obrysy lesa budou aktualni a rozumne presne asi i po 20 letech, ale skladba porostu se meni pomerne rychle a pri mnozstvi lesu v CR nevim nevim kdo by to stihal udrzovat. Zatim bych tam zkusil importovat "jednodussi" verzi, pokud budeme mit u vsech lesu takto naimportovanych je i nejak otagovane (maji lesy v UHULu nejake ID nebo tak neco?) nebylo by pozdeji pak byt problem lesy jeden po druhem nahrazovat presnejsi variantou (ty ktere nikdo nezeditoval automaticky, ty na ktere nekdo hrabnul s nejakou rucni kontrolou). Martin
  33. Pavel Machek pavel na suse.cz #m9440a6
    ...no, a pak turisti / houbari / jezdci na konich... "jak dlouho se jeste budem prodirat touhle houstinou?"... "je tohle starsi smrkovy les kterym jde projit, nebo mlady hustnik?"...
    Import je jedna vec. Druha vec je, ze bychom to pak museli updatovat aby to melo nejakou hodnotu. Orientacka mapa se zakreslenymi porozty pokud je stara 10 let, uz tam porosty na mnoha mistech nesedi a na 20 let stare nesedi skoro nic. I behem 5 let se casto v lese odehraje dost zmen (mensi stromky o neco povyrostou, tamhle se neco pokaci a udela nova paseka ...)
    No, porosty se meni, ale hranice porostu celkem zustavaji... takze odpoved na otazku "jak dlouho se jeste budem prodirat touhle houstinou" mapa dava, i kdyz tam mozna zacne _jina_ houstina... (A uhul mozna ty data bude updatovat, ne?) Pavel
  34. BH singularita na gmail.com #m2aa59d
    No, porosty se meni, ale hranice porostu celkem zustavaji... takze odpoved na otazku "jak dlouho se jeste budem prodirat touhle houstinou" mapa dava, i kdyz tam mozna zacne _jina_ houstina... (A uhul mozna ty data bude updatovat, ne?)
    To asi ano, ale my je musime nejak prebirat (nwevim jestli UHUL bude poskytovat nejake rozumne diffy nad svymi daty :)) a aktualizovat v OSM. Tady by to chtelo mit vyresene aby ve vetsine pripadu tohle nejak probihalo automaticky a lidi resili jen par konfliktnich pripadu. Pak by to asi slo. A nekdy hranice zustavaji, nekdy ne, treba kdyz se vykaci do te doby neohraniceny kus lesa a vysazi se tam nova paseka. Martin
  35. Jachym Cepicky jachym.cepicky na gmail.com #m69f035
    Konkretne informace o tom, jestli je to vysokokmeny mytni porost nebo smrkova mlazina se prece v relativne kratkem case meni. Udrzovat to +- aktualni (se spozdenim 10 let) by znamenalo napojit se na lesni hospodarske plany (ktere jsou neverejne) co se moc nemeneni je slozeni porostu - jehlicnany/listnace j
    Ahoj!
    Ony sice renderery vyrabeji mapu az do 30cm/px, ale mapovat okraje lesa s detaily v jednotkach metru nema moc smysl, obzvlaste kdyz jde o drobne rozliseni uvnitr souvisleho lesniho porostu. Zachovanim pouze obalovych krivek lesa by se velikost datasetu redukovala nejmene o 90% a to uz by pomalu davalo smysl importovat. Soucasny export UHULu ma ~30M nodu, po odstraneni duplicit jich bude ~15M, po redukci vnitrku se dostaneme radove na 1M. To je porad 2x tolik nez vsech ostatnich nodu v cele CR, ale dovedu si to uz predstavit. Musime si pak ale polozit otazku co a jak podrobne v te mape chceme mit. Popr. se opravdu zacit vazneji bavit o tematickych vrstvach v OSM.org
    Takhle podrobna data (t.j. rozdeleni dle typu lesa by vyuzili nejspis jen lesnici (ti si to ale budou spise tahat rovnou z UHULu) a pak lidi vyrabejici mapy na orientacni beh - jenze jednak ti si to muzou stahnout z UHULu sami, jednak stejne musi do lesa aby zmapovali "kazdicky sutr v lese" :) IMHO pouze ty obalove krivky budou asi stacit :)
    ...no, a pak turisti / houbari / jezdci na konich... "jak dlouho se jeste budem prodirat touhle houstinou?"... "je tohle starsi smrkovy les kterym jde projit, nebo mlady hustnik?"... Pavel
    -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
  36. Jachym Cepicky jachym.cepicky na gmail.com #me502c2
    tyhle novoty.. ja bych na to sel grassem 2008/5/15 Tomáš Tichý <t.tichy na post.cz>:
    Nad SRTM neni treba badat, uz to udelali jini :-) Vrstevnice je mozne prevest do OSM nastrojem Srtm2OSM: http://wiki.openstreetmap.org/index.php/Srtm2Osm A nebo je mozne je rederovat primo v mapniku (pouziva Cyclemap a OPM): http://wiki.openstreetmap.org/index.php/Contours_on_the_Cycle_Map =TT= 2008/5/15 Jachym Cepicky <jachym.cepicky na gmail.com>:
    Vrstevnice by se nechaly odvodit ze SRTM - jsou tam data s rozlisenim 30m. Kdyby byl zajem, asi bych to dokzal pripravit Nebo zkusit ukecat Geodis, aby pustili napr. vrstevnice po 20m. Maji vlastni digitalni model terenu a jsou v tom fakt dobry. Dalsi moznost, nad kterou uz jsem uvazoval, kdyby vsechny tracky v OSM byly 3D, nechal by se nejakej model vygeneraovat z nich. Ale to by bylo asi hodne nepresny. Jachym
    Ahoj!
    Patri do mapy treba vsechny budovy? (>2M domu -> >12M OSM primitiv, potencialni import z katastru, pokud by licence povolila) "Ostatni" mapy ty budovy maji (bitmapove), viz nahodne: http://www.mapy.cz/#x=129562992 na y=136523456 na z=16 na mm=ZRP Jake jeste datasety obdobne rozsahlosti by se chtely importovat?
    moc jich uz neni co by jeste sli, ale strasne bych chtel vodstvo:) si nedovedete predstavit jak nasere kdyz nekam jdete a najednou je pres cestu potok co je sice prtavej nepodstatnej a neni videt z ortofota ale vam se rozhodne nechce brodit.
    :-). Jo, vodstvo je opravdu dulezity... Dal se hodej vrstevnice... jenze u tech neni ani jasny jak je vlastne v josm udelat. Pavel
    -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
    http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
    -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
  37. Jachym Cepicky jachym.cepicky na gmail.com #mad4f10
    No, porosty se meni, ale hranice porostu celkem zustavaji... takze odpoved na otazku "jak dlouho se jeste budem prodirat touhle houstinou" mapa dava, i kdyz tam mozna zacne _jina_ houstina... (A uhul mozna ty data bude updatovat, ne?)
    To asi ano, ale my je musime nejak prebirat (nwevim jestli UHUL bude poskytovat nejake rozumne diffy nad svymi daty :)) a aktualizovat v OSM. Tady by to chtelo mit vyresene aby ve vetsine pripadu tohle nejak probihalo automaticky a lidi resili jen par konfliktnich pripadu. Pak by to asi slo. A nekdy hranice zustavaji, nekdy ne, treba kdyz se vykaci do te doby neohraniceny kus lesa a vysazi se tam nova paseka. Martin
    na diffy zapomente j
  38. Michal Kovar megabordel na seznam.cz #mbe35bd
    Ono by mozna stalo za to zamyslet se nad moznosti, ze by OSM umel nejakym zpusobem uzivateli rict, jak stara jsou data, na ktera se diva. To neplati jen o stromech, ale i o silnicich a zastavbe - bylo by to uzitecny. Pak bychom nemuseli resit, kdo co udrzuje, ale do neznama bychom sli s tim, ze na danou oblast uz nikdo 5 let nehrabnul a pocitali bychom s tim, ze tam muze byt neco jinak.
  39. Petr Nejedly Petr.Nejedly na Sun.COM #m5a366c
    Ono by mozna stalo za to zamyslet se nad moznosti, ze by OSM umel nejakym zpusobem uzivateli rict, jak stara jsou data, na ktera se diva. To neplati jen o stromech, ale i o silnicich a zastavbe - bylo by to uzitecny. Pak bychom nemuseli resit, kdo co udrzuje, ale do neznama bychom sli s tim, ze na danou oblast uz nikdo 5 let nehrabnul a pocitali bychom s tim, ze tam muze byt neco jinak.
    OSM to svym zpusobem umi - kazdy prvek ma ulozeno cas posledni editace. To vsak samozrejme vice ci mene neodpovida casu porizeni dat.
  40. Michal Kovar megabordel na seznam.cz #mbdb3f3
    Vim, ze to stoji a pada s uzivatelem. Kdyz to tam da dneska, neznamena to, ze nepouzil starsi reference (treba UHUL, kterej je starej jak metuzalem). Ale s tim nikdo nic nenadela - stejne jako s tim, ze nekdo muze zamerne zmenit silnici do zcela nesmyslnych mist. To je proste dan za otevreny system. I proto bych nepropadal hysterii o nejakych megapodrobnych datech lesu. Myslim, ze mame co dohanet ve mestech, o vesnicich nemluve. Cela diskuse o globalnim pokryti OSM map lesama mi prijde hrube predcasna. Co se map tyce, nosime jeste plinky - a bavime se o duchodovym pojisteni. On Fri, 16 May 2008 08:50:17 +0200, Petr Nejedly <Petr.Nejedly na Sun.COM>
  41. Jiri Klement jiri.klement na gmail.com #mbfc302
    Myslite ze je realna sance, ze nekdo bude v osm upravovat typy porostu? Podle me ne, takze nevidim zadnou vyhodu mit tutu informaci primo v osm, zajemnci muzou pouzit wms uhulu. Pripadne se muze udelat verze osm kde budou pouze typy lesu a mapa pro houbare vznikne spojenim teto vrstvy a normalniho osm. Dalsi vec je aktualnost a presnost dat z uhulu. Zkuste porovnat lesy kde to znate s verzi z uhulu. Lesy ktere jsme vysazeli v roce 1993 tam porad jeste nejsou, hranice lesa i u starsich porostu (> 40 let) jsou nekdy dost mimo. Myslim ze bohate staci udelat import obrysu lesu z UHUL. I tak budou informace o lesech presnejsi nez treba na www.mapy.cz
  42. Michal Kovar megabordel na seznam.cz #m2d6a8a
    Konecne rozumnej nazor. On Fri, 16 May 2008 09:09:33 +0200, Jiri Klement <jiri.klement na gmail.com>
    Myslite ze je realna sance, ze nekdo bude v osm upravovat typy porostu? Podle me ne, takze nevidim zadnou vyhodu mit tutu informaci primo v osm, zajemnci muzou pouzit wms uhulu. Pripadne se muze udelat verze osm kde budou pouze typy lesu a mapa pro houbare vznikne spojenim teto vrstvy a normalniho osm. Dalsi vec je aktualnost a presnost dat z uhulu. Zkuste porovnat lesy kde to znate s verzi z uhulu. Lesy ktere jsme vysazeli v roce 1993 tam porad jeste nejsou, hranice lesa i u starsich porostu (> 40 let) jsou nekdy dost mimo. Myslim ze bohate staci udelat import obrysu lesu z UHUL. I tak budou informace o lesech presnejsi nez treba na www.mapy.cz
    Ono by mozna stalo za to zamyslet se nad moznosti, ze by OSM umel
    nejakym
    zpusobem uzivateli rict, jak stara jsou data, na ktera se diva. To neplati jen o stromech, ale i o silnicich a zastavbe - bylo by to uzitecny. Pak bychom nemuseli resit, kdo co udrzuje, ale do neznama bychom sli s tim, ze na danou oblast uz nikdo 5 let nehrabnul a pocitali bychom s tim, ze tam muze byt neco jinak.
    OSM to svym zpusobem umi - kazdy prvek ma ulozeno cas posledni editace. To vsak samozrejme vice ci mene neodpovida casu porizeni dat.
    http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz __________ Informace od NOD32 3103 (20080516) __________ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz
    -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
  43. Jachym Cepicky jachym.cepicky na gmail.com #md2042c
    +1
    Myslite ze je realna sance, ze nekdo bude v osm upravovat typy porostu? Podle me ne, takze nevidim zadnou vyhodu mit tutu informaci primo v osm, zajemnci muzou pouzit wms uhulu. Pripadne se muze udelat verze osm kde budou pouze typy lesu a mapa pro houbare vznikne spojenim teto vrstvy a normalniho osm. Dalsi vec je aktualnost a presnost dat z uhulu. Zkuste porovnat lesy kde to znate s verzi z uhulu. Lesy ktere jsme vysazeli v roce 1993 tam porad jeste nejsou, hranice lesa i u starsich porostu (> 40 let) jsou nekdy dost mimo. Myslim ze bohate staci udelat import obrysu lesu z UHUL. I tak budou informace o lesech presnejsi nez treba na www.mapy.cz
    Ono by mozna stalo za to zamyslet se nad moznosti, ze by OSM umel nejakym zpusobem uzivateli rict, jak stara jsou data, na ktera se diva. To neplati > jen o stromech, ale i o silnicich a zastavbe - bylo by to uzitecny. Pak > bychom nemuseli resit, kdo co udrzuje, ale do neznama bychom sli s tim, ze > na danou oblast uz nikdo 5 let nehrabnul a pocitali bychom s tim, ze tam > muze byt neco jinak.
    OSM to svym zpusobem umi - kazdy prvek ma ulozeno cas posledni editace. To vsak samozrejme vice ci mene neodpovida casu porizeni dat.
    http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
    -- Jachym Cepicky e-mail: jachym.cepicky gmail com URL: http://les-ejk.cz GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
  44. Jakub Sykora kubajz na kbx.cz #maf24d7
    Udelame to generalizovane. Asi je fakt, ze to nema velky smysl... Udelame neco, at trochu zelena ta nase zemicka. Kdo chce presnejsi data, muze si je poridit na UHULu a kdo je chce jeste presneji, at si tam zajde a muze si vzit data s presnosti na 5m. K
    Myslite ze je realna sance, ze nekdo bude v osm upravovat typy porostu? Podle me ne, takze nevidim zadnou vyhodu mit tutu informaci primo v osm, zajemnci muzou pouzit wms uhulu. Pripadne se muze udelat verze osm kde budou pouze typy lesu a mapa pro houbare vznikne spojenim teto vrstvy a normalniho osm. Dalsi vec je aktualnost a presnost dat z uhulu. Zkuste porovnat lesy kde to znate s verzi z uhulu. Lesy ktere jsme vysazeli v roce 1993 tam porad jeste nejsou, hranice lesa i u starsich porostu (> 40 let) jsou nekdy dost mimo. Myslim ze bohate staci udelat import obrysu lesu z UHUL. I tak budou informace o lesech presnejsi nez treba na www.mapy.cz
    Ono by mozna stalo za to zamyslet se nad moznosti, ze by OSM umel nejakym zpusobem uzivateli rict, jak stara jsou data, na ktera se diva. To neplati > jen o stromech, ale i o silnicich a zastavbe - bylo by to uzitecny. Pak > bychom nemuseli resit, kdo co udrzuje, ale do neznama bychom sli s tim, ze > na danou oblast uz nikdo 5 let nehrabnul a pocitali bychom s tim, ze tam > muze byt neco jinak.
    OSM to svym zpusobem umi - kazdy prvek ma ulozeno cas posledni editace. To vsak samozrejme vice ci mene neodpovida casu porizeni dat.
    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 ''
  45. hanoj ehanoj na gmail.com #mbdf839
    Na UHUL ma jit lesak, ale nejaka elementarni informace o druhovem slozeni nikomu neublizi trebas na urovni hektaru. Tutisticka KCT ji taky ma, je to proste doplnujici topograficka informace. S mirou generalizace bych nemel problem. S generalnim importem do OSM stale jeste ano, separe zadny problem. hanoj
  46. Michal Kovar megabordel na seznam.cz #m01c831
    Zpresnovat se to muze postupne. Kdyz uz chcete mermomoci zelenou mapu, tak to zaplnte univerzalnim spenatem a mistni aktivni osmaci tomu pak priradi prislusny atribut. 80% lidi tyhle informace stejne neoceni.
  47. Pavel Machek pavel na suse.cz #m73d4b6
    Ahoj! Jsou nejake novinky okolo importu lesu? Myslim ze de-duplicitu bodu bych mel byt schopny udelat klidne v shellu... Je nekde posledni verse? Pavel
  48. Jakub Sykora kubajz na kbx.cz #mda23ae
    Ahoj, je to v tom stavu, ze zapomneli dodat do serveru WFS nastaveni se SRS a server ted odmita cokoliv vydat... Pokud se pletu, prosim, podivejte se na to nekdo s nejakym sofistikovanym GIS sw: http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WFS Uz kdyz se da request GetCapabilities, tak je to dost hole a sam server tam priznava, ze tam nejake veci chybeji... K
  49. Jakub Sykora kubajz na kbx.cz #m07ff38
    Ahoj, ted jsem koukal na WMS a je tam mozne stahovat zelene plochy lesu. Vse spatne je k necemu dobre - alespon by se vyrazne snizil pocet bodu, ktere by se importovaly, protoze ty zelene plochy uz nejsou deleny na typy lesu, ale jsou vcelku. Takze asi predelam ten program tak, ze bude fungovat jako lakewalker (mozna ho i pouziju) a bude delat z obrazku krivky... K
  50. Pavel Machek pavel na suse.cz #m376c7e
    AhoJ!
    ted jsem koukal na WMS a je tam mozne stahovat zelene plochy lesu. Vse spatne je k necemu dobre - alespon by se vyrazne snizil pocet bodu, ktere by se importovaly, protoze ty zelene plochy uz nejsou deleny na typy lesu, ale jsou vcelku. Takze asi predelam ten program tak, ze bude fungovat jako lakewalker (mozna ho i pouziju) a bude delat z obrazku krivky...
    Ty stary data nekde jsou, ne? Ta konverze uz se jednou delala... a nekde na webu jsou vysledky ... (kdybych si tak pamatoval kde).... ... (par grepu) http://kubajz.kbx.cz/junk/uhul/output/ Samozrejme, lakewalker by byla taky moznost ;-). Pavel
  51. Kubajz kubajz na kbx.cz #mc817c4
    Ahoj,
    AhoJ!
    ted jsem koukal na WMS a je tam mozne stahovat zelene plochy lesu. Vse spatne je k necemu dobre - alespon by se vyrazne snizil pocet bodu, ktere by se importovaly, protoze ty zelene plochy uz nejsou deleny na typy lesu, ale jsou vcelku. Takze asi predelam ten program tak, ze bude fungovat jako lakewalker (mozna ho i pouziju) a bude delat z obrazku krivky...
    Ty stary data nekde jsou, ne? Ta konverze uz se jednou delala... a
    Ano, ale ztroskotalo to na duplicite bodu a prilisne presnosti dat (za prve moc presna a zadruhe lesy byly deleny na podoblasti, coz je zeslozituje a v praxi nema opodstatneni). Rozhodnuti zde na konferenci bylo importovat zjednodusena data.
    nekde na webu jsou vysledky ... (kdybych si tak pamatoval kde).... ... (par grepu) http://kubajz.kbx.cz/junk/uhul/output/ Samozrejme, lakewalker by byla taky moznost ;-).
    O dost lepsi, protoze eliminuje nedostatky vyse uvedene.
  52. Kubajz kubajz na kbx.cz #m9ddff6
    AhoJ!
    ted jsem koukal na WMS a je tam mozne stahovat zelene plochy lesu. Vse spatne je k necemu dobre - alespon by se vyrazne snizil pocet bodu, ktere by se importovaly, protoze ty zelene plochy uz nejsou deleny na typy lesu, ale jsou vcelku. Takze asi predelam ten program tak, ze bude fungovat jako lakewalker (mozna ho i pouziju) a bude delat z obrazku krivky...
    Ty stary data nekde jsou, ne? Ta konverze uz se jednou delala... a nekde na webu jsou vysledky ... (kdybych si tak pamatoval kde).... ... (par grepu) http://kubajz.kbx.cz/junk/uhul/output/ Samozrejme, lakewalker by byla taky moznost ;-).
    udelal jsem algoritmus, ktery zjednodusi vstupni data na uroven definovanou uzivatelem a uz ho mam odzkouseny. Navic bude souvisle velke lesy delit na mensi, aby pri stazeni malych dat clovek nestahoval pulku lesu CR.
  53. Pavel Machek pavel na suse.cz #mabff40
    AhoJ!
    ted jsem koukal na WMS a je tam mozne stahovat zelene plochy lesu. Vse spatne je k necemu dobre - alespon by se vyrazne snizil pocet bodu, ktere by se importovaly, protoze ty zelene plochy uz nejsou deleny na typy lesu, ale jsou vcelku. Takze asi predelam ten program tak, ze bude fungovat jako lakewalker (mozna ho i pouziju) a bude delat z obrazku krivky...
    Ty stary data nekde jsou, ne? Ta konverze uz se jednou delala... a nekde na webu jsou vysledky ... (kdybych si tak pamatoval kde).... ... (par grepu) http://kubajz.kbx.cz/junk/uhul/output/ Samozrejme, lakewalker by byla taky moznost ;-).
    udelal jsem algoritmus, ktery zjednodusi vstupni data na uroven definovanou uzivatelem a uz ho mam odzkouseny. Navic bude souvisle velke lesy delit na mensi, aby pri stazeni malych dat clovek nestahoval pulku lesu CR.
    Je nekde k dispozici vysledek? Pavel
  54. Kubajz kubajz na kbx.cz #mcd1af2
    Az dorazim dom, tak ho nekde vystavim. Nemam to ted u sebe. K
  55. Petr Schonmann PSBOX na seznam.cz #m527412
    Muzete se nekdo chopit popsani importu lesu ? do WIKI ? http://wiki.openstreetmap.org/index.php/WikiProject_Czechia/free_map2osm#Dokon.C4.8Den.C3.A9_importy ---- S pozdravem Mail: psbox na seznam.cz http://fatbozz.towerofglass.net
Napsat odpověď e-mailem… Odpovědět

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