* zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na napr: buk dub, nebo jen listnaty/jehlicnaty?Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho informace les listnaty/jehlicnaty/smiseny vytahne sam...*** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake oblasti lesa z mnoha polygonu na dva typy a to laicke napr. listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme udelat shapefile do jejich GISu s plnym datasetem.Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se resil tezko - jedna se o zakomentovani dvou radku.
* zjednodussime klasifikaci lesa (jak jsem o tom puvodne mluvil) na napr: buk dub, nebo jen listnaty/jehlicnaty?Ten tag sam o sobe zjednodusit vlastne ani moc nejde. Sam o sobe tam nicemu nevadi a lesakovi to udela radost. Normalni clovek si z toho informace les listnaty/jehlicnaty/smiseny vytahne sam...*** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake oblasti lesa z mnoha polygonu na dva typy a to laicke napr. listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme udelat shapefile do jejich GISu s plnym datasetem.Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se resil tezko - jedna se o zakomentovani dvou radku.
Ahoj! Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- "rozhrani porostu" -- a i podle toho se da v nouzi jit.
Ahoj! Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- "rozhrani porostu" -- a i podle toho se da v nouzi jit.
*** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake oblasti lesa z mnoha polygonu na dva typy a to laicke napr. listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme udelat shapefile do jejich GISu s plnym datasetem.Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se resil tezko - jedna se o zakomentovani dvou radku."Les je les"... no ne tak uplne. Je pomerne velky rozdil mezi vzrostlym smrkovym lesem -- da se jim bezet -- a hustymi mladymi smrcky ve vysce 2.5metru -- tim se neda v podstate ani jit. Ve fakt hnusnym hustniku bude rychlost tak 1km/h a bezny clovek se mu radej vyhne. Mapy pro orientacni beh to zachycujou, protoze je to nutne potreba pro navigaci po lese, a da se podle toho bez problemu orientovat. Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- "rozhrani porostu" -- a i podle toho se da v nouzi jit. Pavel (jehoz josm se pri nacteni tri lesovych dlazdic lehce zadychaval, ale lehke zadychavani povazuje za lepsi nez chybejici data.)
*** myslel jsem tim to co asi pises vyse. zrusit "vnitrni kresbu" nejake oblasti lesa z mnoha polygonu na dva typy a to laicke napr. listnac/jehlicnan deleni zapsat napr do description. Pro lesaky muzeme udelat shapefile do jejich GISu s plnym datasetem.Je asi fakt, ze v OSM tato metadata nemaji valneho smyslu. Proste bych nechal, ze je to les a tim to hasne. Ovsem to neni problem, ktery by se resil tezko - jedna se o zakomentovani dvou radku."Les je les"... no ne tak uplne. Je pomerne velky rozdil mezi vzrostlym smrkovym lesem -- da se jim bezet -- a hustymi mladymi smrcky ve vysce 2.5metru -- tim se neda v podstate ani jit. Ve fakt hnusnym hustniku bude rychlost tak 1km/h a bezny clovek se mu radej vyhne. Mapy pro orientacni beh to zachycujou, protoze je to nutne potreba pro navigaci po lese, a da se podle toho bez problemu orientovat. Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- "rozhrani porostu" -- a i podle toho se da v nouzi jit. Pavel (jehoz josm se pri nacteni tri lesovych dlazdic lehce zadychaval, ale lehke zadychavani povazuje za lepsi nez chybejici data.)
Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- "rozhrani porostu" -- a i podle toho se da v nouzi jit. Pavel (jehoz josm se pri nacteni tri lesovych dlazdic lehce zadychaval, ale lehke zadychavani povazuje za lepsi nez chybejici data.)*** to sice mas pravdu, ale: 1) mapa pro orientak je specialka, navic v CR je uzemi kde se muze behat podle orientackych map mnohokrat premerene. OSM neni specialka. Pro tento ucel by mel zustat zachovan grabnuty dataset z WFS v nejakem standardu napr. GML. Mohlo by se s originalem zachazet jako se SRTM...
Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech!
Rozdil mezi "vzrostly listnaty les" a "vzrostly jehlicnaty les" je o poznani mensi. Orientacky mapy mezi ne presto kresli oddeleni -- "rozhrani porostu" -- a i podle toho se da v nouzi jit. Pavel (jehoz josm se pri nacteni tri lesovych dlazdic lehce zadychaval, ale lehke zadychavani povazuje za lepsi nez chybejici data.)*** to sice mas pravdu, ale: 1) mapa pro orientak je specialka, navic v CR je uzemi kde se muze behat podle orientackych map mnohokrat premerene. OSM neni specialka. Pro tento ucel by mel zustat zachovan grabnuty dataset z WFS v nejakem standardu napr. GML. Mohlo by se s originalem zachazet jako se SRTM...
Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech!
Aspon pro nektere lesy bych chtel plna data .. snazim se je mapovat podobne podrobne jako jsou orientacke mapy. A myslim ze je nejjednodussi importovat lesy uplne: ty data stejne nejsou hustssi nez treba centrum Prahy... a aspon tady to beha celkem pouzitelne (a to je to v jave).
Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech!(Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel importovat, tak bych se za to dost primlouval ;-).
Aspon pro nektere lesy bych chtel plna data .. snazim se je mapovat podobne podrobne jako jsou orientacke mapy. A myslim ze je nejjednodussi importovat lesy uplne: ty data stejne nejsou hustssi nez treba centrum Prahy... a aspon tady to beha celkem pouzitelne (a to je to v jave).
Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech!(Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel importovat, tak bych se za to dost primlouval ;-).
Aspon pro nektere lesy bych chtel plna data .. snazim se je mapovat podobne podrobne jako jsou orientacke mapy. A myslim ze je nejjednodussi importovat lesy uplne: ty data stejne nejsou hustssi nez treba centrum Prahy... a aspon tady to beha celkem pouzitelne (a to je to v jave).Treba ctverec 50.00,14.30 - 50.25,14.55 ma asi 10MB (1.5MB kdyz to vezmu gzipem) a obsahuje vetsinu prahy a par nejakych vesnic na sever. Coz je asi 10% cele CR (pro ni ma OSM vytahane z dumpu asi 100MB) Jak velky (kolik stupnu krat kolik stupnu) jsou ty ctverce v adresari http://kubajz.kbx.cz/junk/uhul/output/ ? Ale asi bych to tam soupnul v plnych detailech i se vsemi porosty. Kdyz uz mapu, tak kvalitni a asi o tolik mensi to nebude kdyby se to zkouselo nejak osekat a kvalita by tim asi utrpela...Taky holt neni v OSM a jak vypovida o mapovanych skutecnostech!(Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel importovat, tak bych se za to dost primlouval ;-).Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde cpat. Martin _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Ctverce jsou 10x10 km, kolik je to stupnu fakt nevim (resp. lze udelat jednoduchy prepocet z nazvu souboru. Namisto x dosad minus a mas rozmery BB. Pak staci konverze do WSG84).
Ctverce jsou 10x10 km, kolik je to stupnu fakt nevim (resp. lze udelat jednoduchy prepocet z nazvu souboru. Namisto x dosad minus a mas rozmery BB. Pak staci konverze do WSG84).
(Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel importovat, tak bych se za to dost primlouval ;-).Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde cpat. Martin
(Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel importovat, tak bych se za to dost primlouval ;-).Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde cpat. Martin
(Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel importovat, tak bych se za to dost primlouval ;-).Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde cpat.vrstevnice zatim nikdo neplanuje co sem pochytil, ale spousta projektu pouziva dostupne data (SRTM) a placa to jako dalsi vrstvu nad osm data, http://www.free-map.org.uk, freemap.sk, ja mam v garminu pridanu mapu s vrstevnicemi z http://gps-maps.info/cz/
(Jak se da pouzivat neco jako SRTM pro osm? Kdybych vyskovy data umel importovat, tak bych se za to dost primlouval ;-).Problem je spis v tom, ze OSM vyskova data tak nejak nepodporuje. Ostatne ziskat rozumne presna vyskova data pobihanimm s GPSkou moc dobre nejde (nebo je to na dlouho), takze ledatak ziskat je z nejakeho jineho zdroje (tusim z landsatu jsou vyskova data pro vetsinu sveta s rozlisenim asi 90 metru .... coz by pro zacatek moho stacit), takze autori OSM asi podporu pro ne nejak vypustili. To chce se asi optrat lidi co stoji za OSM jak s vyskovymi daty a jestli je tam nekdy pujde cpat.vrstevnice zatim nikdo neplanuje co sem pochytil, ale spousta projektu pouziva dostupne data (SRTM) a placa to jako dalsi vrstvu nad osm data, http://www.free-map.org.uk, freemap.sk, ja mam v garminu pridanu mapu s vrstevnicemi z http://gps-maps.info/cz/
SRTM se do OSM nestrka predevsim proto: 1, ze je velky 2, a neni duvod ho editovat Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam podari ho omylem poskodit. Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi vrstva/mapa. Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, ktery se ho pokousi zrychlit v stavajicich mezich). Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu. hanoj _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
2, a neni duvod ho editovat [...] Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap.
2, a neni duvod ho editovat [...] Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap.
On Dec 11, 2007 11:42 AM, hanoj <enemy na mail.muni.cz> wrote:2, a neni duvod ho editovat [...] Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap.Jo, to jsou myslim dobre duvody, proc UHUL neimportovat. Martin _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
SRTM se do OSM nestrka predevsim proto: 1, ze je velky 2, a neni duvod ho editovat Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam podari ho omylem poskodit. Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi vrstva/mapa. Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, ktery se ho pokousi zrychlit v stavajicich mezich).
Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.
SRTM se do OSM nestrka predevsim proto: 1, ze je velky 2, a neni duvod ho editovat Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam podari ho omylem poskodit. Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi vrstva/mapa. Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, ktery se ho pokousi zrychlit v stavajicich mezich).
Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.
Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi vrstva/mapa.
Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, ktery se ho pokousi zrychlit v stavajicich mezich).
Blby je, ze kdyz nechame uhul data jen "nekde vedle", tak bude potreba: 1) upravit mapu na openstreetmap.org aby to zobrazovala
2) upravit josm aby umel pouzit zaroven WMS a takovyhle data 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi budou kreslit jiz existujici lesy) 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper).
...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit celej zbytek OSM sveta pracovat s dvema zdroji dat.
Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.
Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi vrstva/mapa.
Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, ktery se ho pokousi zrychlit v stavajicich mezich).
Blby je, ze kdyz nechame uhul data jen "nekde vedle", tak bude potreba: 1) upravit mapu na openstreetmap.org aby to zobrazovala
2) upravit josm aby umel pouzit zaroven WMS a takovyhle data 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi budou kreslit jiz existujici lesy) 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper).
...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit celej zbytek OSM sveta pracovat s dvema zdroji dat.
Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.
SRTM se do OSM nestrka predevsim proto: 1, ze je velky 2, a neni duvod ho editovat Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam podari ho omylem poskodit. Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi vrstva/mapa. Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, ktery se ho pokousi zrychlit v stavajicich mezich).Blby je, ze kdyz nechame uhul data jen "nekde vedle", tak bude potreba: 1) upravit mapu na openstreetmap.org aby to zobrazovala 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi budou kreslit jiz existujici lesy) 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper). ...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit celej zbytek OSM sveta pracovat s dvema zdroji dat.Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ strasnej ten josm neni. Pavel
On Tue 2007-12-11 11:42:26, hanoj wrote:SRTM se do OSM nestrka predevsim proto: 1, ze je velky 2, a neni duvod ho editovat Rekl bych ze UHUL les je na tom obdobne. Rocne dojde ke zmene jednotkach km^2 lesa v CR, coz je zanedbatelne na to aby byl pripraven k permanentni editaci, navic v takove presnosti jako je zpracovan les UHUL my nejsme schopni pracovat, mozna ani tu zmenu zjistit. Spis se nam podari ho omylem poskodit. Na to aby se UHUL pouzival jako zdroj informaci pro mapovani se muze klidne nechat vyrendrovat a pres plugin slippymap si ho zobrazovat v JOSM, nebo jako pruhledna vrstva na mapserveru, do garmina jako dalsi vrstva/mapa. Zatim neni JOSM nikterak pripraven pro zvladani velkych dat a to jakymkoliv z moznych zpusobu, ani na tom asi nikdo pracuje (mimo Petra, ktery se ho pokousi zrychlit v stavajicich mezich).Blby je, ze kdyz nechame uhul data jen "nekde vedle", tak bude potreba: 1) upravit mapu na openstreetmap.org aby to zobrazovala 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi budou kreslit jiz existujici lesy) 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper). ...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL. Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit celej zbytek OSM sveta pracovat s dvema zdroji dat.Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ strasnej ten josm neni. Pavel
Tak naimportujem data jen na zadost mapera v jeho okoli, zeleznice pres vysocinu(potoky reky) by se opravdu delaly spatne. Pomalost JOSM s velkymi objemy dat je castecne omezujici faktor, ale nejak jsem nepozoroval ze by me vyrazne zdrzovalo. To ze si nemuzu nacist maximalnich 5.4kmx6km v okoli velkych evropskych mest je realitou uz delsi dobu.
Tak naimportujem data jen na zadost mapera v jeho okoli, zeleznice pres vysocinu(potoky reky) by se opravdu delaly spatne. Pomalost JOSM s velkymi objemy dat je castecne omezujici faktor, ale nejak jsem nepozoroval ze by me vyrazne zdrzovalo. To ze si nemuzu nacist maximalnich 5.4kmx6km v okoli velkych evropskych mest je realitou uz delsi dobu.
4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper).Uz vidim to readme pro vyvojare: .... a zde je API pro stahovani dat z OSM a zdre je 100 ruznych API pro stahovani 100 ruznych externich zdroju ktery jsou na OSM nabaleny (UHUL + buhvico by si lidi z ostatnich zemi vymysleli .... )
4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper).Uz vidim to readme pro vyvojare: .... a zde je API pro stahovani dat z OSM a zdre je 100 ruznych API pro stahovani 100 ruznych externich zdroju ktery jsou na OSM nabaleny (UHUL + buhvico by si lidi z ostatnich zemi vymysleli .... )
1) upravit mapu na openstreetmap.org aby to zobrazovala 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi budou kreslit jiz existujici lesy) 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper). ...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL.
Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit celej zbytek OSM sveta pracovat s dvema zdroji dat.Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ strasnej ten josm neni.
1) upravit mapu na openstreetmap.org aby to zobrazovala 2) upravit josm aby umel pouzit zaroven WMS a takovyhle data 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi budou kreslit jiz existujici lesy) 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper). ...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL.
Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit celej zbytek OSM sveta pracovat s dvema zdroji dat.Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ strasnej ten josm neni.
pouze mapovy list: x613388_x1149320_x603388_x1139320.xml cca 6000 kB negzipovany zoom zobrazeni z fullextent na ctverec listu 11 sekund zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m select jedne area a jeji vysviceni 4 sekundy v meritku 250m nebo jsem snad jedinej? ha hanoj http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
pouze mapovy list: x613388_x1149320_x603388_x1139320.xml cca 6000 kB negzipovany zoom zobrazeni z fullextent na ctverec listu 11 sekund zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m select jedne area a jeji vysviceni 4 sekundy v meritku 250m nebo jsem snad jedinej? ha hanoj _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
> 1) upravit mapu na openstreetmap.org aby to zobrazovala2) upravit josm aby umel pouzit zaroven WMS a takovyhle data 3) upravit potlatch aby umel uhul aspon zobrazovat (jinak nam tam lidi budou kreslit jiz existujici lesy) 4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper). ...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL.*** myslim ze staci vygenerovat jeden IMG pro garmin, jeden OSM file separe lesu, sestavit kubajzem navrhovy mapserver, napsat na wiki "lesy se nekresli, uz jsou, ale zatim jinde", slippymapplugin pro JOSM modifikovat pro jiny zdroj mapserveru nez openstreetmap.org.Alternativa je bud se smirit s tim ze se josm trochu zadychava (nijak strasny to neni), nebo zrychlit josm. Rozhodne min prace nez naucit celej zbytek OSM sveta pracovat s dvema zdroji dat.Pokud bychom ted importovali lesy od UHULu paralyzujeme vyvoj CZmap. Zkuste si predstavit jak manualne i vypocetne by bylo narocne nakreslit trebas 50km zeleznice pres vysocinu.Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ strasnej ten josm neni.*** no ja nevim, ja mam k dispozici hw: 1* AMD XP 2GHz - Ubuntu 7.10, Java 1.6 2* Intel Centrino Duo 1,6GHz - WinXP, Java 1.6 3* Intel PentiumD ~2GHz - WinXP, Java 1.6 ** vzdy s JOSMlatest+Mappaint,WMSplugin,Validator a neco jako -Xmx280m+ Vsude stejnej problem nekde od 2-3000kB dat (negzipovano) pracuje vyrazne pomaleji, na hranici toho, jak se da slusne kreslit, zoomovat, etc. Priklad v sestave hw 1*: pouze mapovy list: x613388_x1149320_x603388_x1139320.xml cca 6000 kB negzipovany zoom zobrazeni z fullextent na ctverec listu 11 sekund zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m select jedne area a jeji vysviceni 4 sekundy v meritku 250m nebo jsem snad jedinej? ha hanoj _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper). ...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL.*** myslim ze staci vygenerovat jeden IMG pro garmin, jeden OSM file separe lesu, sestavit kubajzem navrhovy mapserver, napsat na wiki "lesy se nekresli, uz jsou, ale zatim jinde", slippymapplugin pro JOSM modifikovat pro jiny zdroj mapserveru nez openstreetmap.org.
Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ strasnej ten josm neni.*** no ja nevim, ja mam k dispozici hw: 1* AMD XP 2GHz - Ubuntu 7.10, Java 1.6 2* Intel Centrino Duo 1,6GHz - WinXP, Java 1.6 3* Intel PentiumD ~2GHz - WinXP, Java 1.6 ** vzdy s JOSMlatest+Mappaint,WMSplugin,Validator a neco jako -Xmx280m+ Vsude stejnej problem nekde od 2-3000kB dat (negzipovano) pracuje vyrazne pomaleji, na hranici toho, jak se da slusne kreslit, zoomovat, etc. Priklad v sestave hw 1*: pouze mapovy list: x613388_x1149320_x603388_x1139320.xml cca 6000 kB negzipovany
zoom zobrazeni z fullextent na ctverec listu 11 sekund
zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m
uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m
select jedne area a jeji vysviceni 4 sekundy v meritku 250m
nebo jsem snad jedinej?
4) naucit vsechny nastroje co pracujou se streetmapou ze lesy se maj brat od jinud. (Napr. navit, maemomapper). ...to mi prijde celkem dost prace, ktera navic akorat vsechno zkomplikuje, protoze data jsou najednou z vice zdroju -- osm + UHUL.*** myslim ze staci vygenerovat jeden IMG pro garmin, jeden OSM file separe lesu, sestavit kubajzem navrhovy mapserver, napsat na wiki "lesy se nekresli, uz jsou, ale zatim jinde", slippymapplugin pro JOSM modifikovat pro jiny zdroj mapserveru nez openstreetmap.org.
Misto 1 minuty by to trvalo 2?! Paralyzujeme vyvoj?! Zas _tak_ strasnej ten josm neni.*** no ja nevim, ja mam k dispozici hw: 1* AMD XP 2GHz - Ubuntu 7.10, Java 1.6 2* Intel Centrino Duo 1,6GHz - WinXP, Java 1.6 3* Intel PentiumD ~2GHz - WinXP, Java 1.6 ** vzdy s JOSMlatest+Mappaint,WMSplugin,Validator a neco jako -Xmx280m+ Vsude stejnej problem nekde od 2-3000kB dat (negzipovano) pracuje vyrazne pomaleji, na hranici toho, jak se da slusne kreslit, zoomovat, etc. Priklad v sestave hw 1*: pouze mapovy list: x613388_x1149320_x603388_x1139320.xml cca 6000 kB negzipovany
zoom zobrazeni z fullextent na ctverec listu 11 sekund
zoom zobrazeni z fullextent na ctverec listu 8 sekund (bez sipek mappaintu) posun obrazu levym tlacitkem mysi za 5 sekund v meritku 250m
uchopeni nodu a jeho posun odezva za 5 sekund v meritku 250m
select jedne area a jeji vysviceni 4 sekundy v meritku 250m
nebo jsem snad jedinej?
nebo jsem snad jedinej?Zda se... tak kde je rozdil?
a) Co je mappaint? Ja zadny balicek na kresleni neinstaloval, pouzivam to co je v josm defaultne.
b) josm verse 350 z 2007-10-07.
nebo jsem snad jedinej?Zda se... tak kde je rozdil?
a) Co je mappaint? Ja zadny balicek na kresleni neinstaloval, pouzivam to co je v josm defaultne.
b) josm verse 350 z 2007-10-07.
nebo jsem snad jedinej?Zda se... tak kde je rozdil?Ze by v parameterech javy? Zjistil jsem ze na zhruba srovnatelnych HW konfiguracich je to ve windows dosti pomalejsi nez v linuxu. Kdyz jsem ve windows ke spousteni javy s josm.jar prilipnul parametr -Dsun.java2d.opengl=true tak hned se to vyrazne zrychlilo, veskere vykreslovani, posouvani a prace s mapou ve windows. Takze kdo tam tenhle parametr nema, tak at si ho tam soupne a zkusi to znova.
nebo jsem snad jedinej?Zda se... tak kde je rozdil?Ze by v parameterech javy? Zjistil jsem ze na zhruba srovnatelnych HW konfiguracich je to ve windows dosti pomalejsi nez v linuxu. Kdyz jsem ve windows ke spousteni javy s josm.jar prilipnul parametr -Dsun.java2d.opengl=true tak hned se to vyrazne zrychlilo, veskere vykreslovani, posouvani a prace s mapou ve windows. Takze kdo tam tenhle parametr nema, tak at si ho tam soupne a zkusi to znova.
nebo jsem snad jedinej?Zda se... tak kde je rozdil?Ze by v parameterech javy? Zjistil jsem ze na zhruba srovnatelnych HW konfiguracich je to ve windows dosti pomalejsi nez v linuxu. Kdyz jsem ve windows ke spousteni javy s josm.jar prilipnul parametr -Dsun.java2d.opengl=true tak hned se to vyrazne zrychlilo, veskere vykreslovani, posouvani a prace s mapou ve windows. Takze kdo tam tenhle parametr nema, tak at si ho tam soupne a zkusi to znova.*** tenhle parametr fungoval v drivejsich verzich JOSM (pul roku zpet?) a bez nej nesel na Windows prakticky pouzivat. Od jiste doby je IMHO standardne zapnut bez nutnosti ho uvadet v prikazove radce. ha hanoj _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Zkousel ste nekdo merkator? Je to napsane v qt4, me se to nejak nepodarilo zatim zkompilovat, ale mohla by to byt zajimava alternativa.
Zkousel ste nekdo merkator? Je to napsane v qt4, me se to nejak nepodarilo zatim zkompilovat, ale mohla by to byt zajimava alternativa.
Ja ted sedim pred sebou rok stary notebook Lenovo X60 s WinXP, JOSM 484 (mappaint, wmsplugin, validator), JRE_1.5.0_06, natahnu si citovany
mapset: x703388_x1169320_x693388_x1159320.xml ktery ma 16 MB rozbaleny Aby to slo importovat (coz bych byl i ja rad) 1) je treba upravit JOSM -- to se ale v aktualni dobe nedeje (ja to nesvedu)==>
2) do te doby muze byt zajimave vyuzit lesy v mapserveru a etc., jak rikal kubajz ==> 3) naruzivy Pavel, si zatim muze stahnout les z kubajzovyho tempu, a v lehce zadychanem JOSM podle nich mapovat specialky
Ja ted sedim pred sebou rok stary notebook Lenovo X60 s WinXP, JOSM 484 (mappaint, wmsplugin, validator), JRE_1.5.0_06, natahnu si citovany
mapset: x703388_x1169320_x693388_x1159320.xml ktery ma 16 MB rozbaleny Aby to slo importovat (coz bych byl i ja rad) 1) je treba upravit JOSM -- to se ale v aktualni dobe nedeje (ja to nesvedu)==>
2) do te doby muze byt zajimave vyuzit lesy v mapserveru a etc., jak rikal kubajz ==> 3) naruzivy Pavel, si zatim muze stahnout les z kubajzovyho tempu, a v lehce zadychanem JOSM podle nich mapovat specialky
Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.