> 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 > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

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

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

> 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 > > Pavel Machek napsal(a): >> 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 >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Indexace bodu, co to je? > > Coz takhle generalizace? > > j > > Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): > >> 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 >> >> Pavel Machek napsal(a): >> >>> 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 >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > >

> 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 > > Jachym Cepicky napsal(a): >> Indexace bodu, co to je? >> >> Coz takhle generalizace? >> >> j >> >> Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): >> >>> 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 >>> >>> Pavel Machek napsal(a): >>> >>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 >

> ok > > a co ta generalizace ? tim by se dala data jeste zmensit pri zachovani > pouzitelnosti.... > > j > > 2008/5/15 Kubajz <kubajz na kbx.cz>: > >> 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 >> >> Jachym Cepicky napsal(a): >> >>> Indexace bodu, co to je? >>> >>> Coz takhle generalizace? >>> >>> j >>> >>> Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): >>> >>> >>>> 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 >>>> >>>> Pavel Machek napsal(a): >>>> >>>> >>>>> 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 >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 >> >> > > > >

> 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 > > Jachym Cepicky napsal(a): >> ok >> >> a co ta generalizace ? tim by se dala data jeste zmensit pri zachovani >> pouzitelnosti.... >> >> j >> >> 2008/5/15 Kubajz <kubajz na kbx.cz>: >> >>> 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 >>> >>> Jachym Cepicky napsal(a): >>> >>>> Indexace bodu, co to je? >>>> >>>> Coz takhle generalizace? >>>> >>>> j >>>> >>>> Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): >>>> >>>> >>>>> 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 >>>>> >>>>> Pavel Machek napsal(a): >>>>> >>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> >> >> >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

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

> 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 > > Jachym Cepicky napsal(a): >> Indexace bodu, co to je? >> >> Coz takhle generalizace?

>> >> j >> >> Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): >> >>> 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 >>> >>> Pavel Machek napsal(a): >>> >>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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

> 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>: > >> 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 >> >> Jachym Cepicky napsal(a): >> >>> ok >>> >>> a co ta generalizace ? tim by se dala data jeste zmensit pri zachovani >>> pouzitelnosti.... >>> >>> j >>> >>> 2008/5/15 Kubajz <kubajz na kbx.cz>: >>> >>> >>>> 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 >>>> >>>> Jachym Cepicky napsal(a): >>>> >>>> >>>>> Indexace bodu, co to je? >>>>> >>>>> Coz takhle generalizace? >>>>> >>>>> j >>>>> >>>>> Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): >>>>> >>>>> >>>>> >>>>>> 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 >>>>>> >>>>>> Pavel Machek napsal(a): >>>>>> >>>>>> >>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>> >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> >> > > > >

> Kubajz napsal(a): >> 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 >> >> Jachym Cepicky napsal(a): >>> 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?

> Kubajz napsal(a): > > > 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 > > > > Jachym Cepicky napsal(a): > >> 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 > >> > >> Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): > >> > >>> 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 > >>> > >>> Pavel Machek napsal(a): > >>> > >>>> 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 > >>>> > >>>> > >>> _______________________________________________ > >>> 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 > > > > -- > Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org > 355/113 -- Not the famous irrational number PI, but an incredible simulation! > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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. > On 5/15/08, Petr Nejedly <Petr.Nejedly na sun.com> wrote: >> Kubajz napsal(a): >> >> > 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 >> > >> > Jachym Cepicky napsal(a): >> >> 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 >> >> >> >> Dne 15. květen 2008 9:29 Kubajz <kubajz na kbx.cz> napsal(a): >> >> >> >>> 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 >> >>> >> >>> Pavel Machek napsal(a): >> >>> >> >>>> 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 >> >>>> >> >>>> >> >>> _______________________________________________ >> >>> 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 >> >> >> >> -- >> Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org >> 355/113 -- Not the famous irrational number PI, but an incredible simulation! >> >> >> _______________________________________________ >> 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 >

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

> 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 > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> Vrstevnice nema smysl kreslit, jsou volne k dispozici z nejakeho > satelitu. Na normalni mape nejsou hlavne proto, ze png s vrstevnicema > se spatne komprimuje.

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

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

> > 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 > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

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

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

> 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 > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 > > Dne 15. květen 2008 20:28 Pavel Machek <pavel na suse.cz> napsal(a): >> 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 >> -- >> (english) http://www.livejournal.com/~pavelmachek >> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >> >> _______________________________________________ >> 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 gmail com > URL: http://les-ejk.cz > GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

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

> > 12M OSM primitiv neni zas tolik :) > > Cela czechia.osm ma zatim stale <1M primitiv...

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

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

> 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 > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-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 >> >> Dne 15. květen 2008 20:28 Pavel Machek <pavel na suse.cz> napsal(a): >>> 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 >>> -- >>> (english) http://www.livejournal.com/~pavelmachek >>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html >>> >>> _______________________________________________ >>> 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 gmail com >> URL: http://les-ejk.cz >> GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

>> No, 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 >

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

> Michal Kovar napsal(a): >> 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. >

> Michal Kovar napsal(a): > > > 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. > > > -- > Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org > 355/113 -- Not the famous irrational number PI, but an incredible simulation! > > _______________________________________________ > > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >

> 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 > > On 5/16/08, Petr Nejedly <Petr.Nejedly na sun.com> wrote: >> Michal Kovar napsal(a): >> >> > 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. >> >> >> -- >> Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, >> http://www.netbeans.org >> 355/113 -- Not the famous irrational number PI, but an incredible >> simulation! >> >> _______________________________________________ >> >> 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 > > __________ Informace od NOD32 3103 (20080516) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >

> 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 > > On 5/16/08, Petr Nejedly <Petr.Nejedly na sun.com> wrote: >> Michal Kovar napsal(a): >> >> > 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. >> >> >> -- >> Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org >> 355/113 -- Not the famous irrational number PI, but an incredible simulation! >> >> _______________________________________________ >> >> 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 >

> 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 > > On 5/16/08, Petr Nejedly <Petr.Nejedly na sun.com> wrote: >> Michal Kovar napsal(a): >> >>> 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. >> >> >> -- >> Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org >> 355/113 -- Not the famous irrational number PI, but an incredible simulation! >> >> _______________________________________________ >> >> 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

> 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 > > On 5/16/08, Petr Nejedly <Petr.Nejedly na sun.com> wrote: >> Michal Kovar napsal(a): >> >> > 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.

> 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 > > Dne 16. květen 2008 9:09 Jiri Klement <jiri.klement na gmail.com> napsal(a): >> 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 >> >> On 5/16/08, Petr Nejedly <Petr.Nejedly na sun.com> wrote: >>> Michal Kovar napsal(a): >>> >>> > 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. > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > __________ Informace od NOD32 3105 (20080516) __________ > > Tato zprava byla proverena antivirovym systemem NOD32. > http://www.nod32.cz > >