> Nedalo mi to a zeptal jsem se Povodí Labe na možnost využití jejich dat > (osy vodních toků) ve formátu SHP, která poskytují na svých stránkách ke > stažení a dostalo se mi kladné odpovědi od p. Staňka, správce jejich GIS > i s doporučením. Ujmul by se prosím někdo importu? > > Martin Kokeš > (shr3k) > --- > Dobrý den, > > filosofie našeho podniku je založena na principu, že data by měl > poskytovat ten, který dané mapové objekty spravuje > a to pokud možno zdarma. > > To je i odpovědí na Váš dotaz. > Na našich stránkách poskytujeme osy vodních toků, cizí i ty, které > spravujeme (cca 300 os vodohospodářsky významných toků z cca 20.000 > všech os toků a meliorací na území našech Podniku = cca 1/5 ČR). Ty co > spravujeme i aktualizujeme, a ty ostatní budou postupně aktualizovat > jejich správci (Lesy ČR, Státní meliorační správa, Vojenské újezdy, ...) > Centrálně tak existuje 5 databází na 5 podnicích Povodí, které dohromady > pokrývají toky celé ČR. > > Co se týká IDéček, bylo na úrovni MZe odsouhlaseno, že bude používán > jednoznačný číselný bezvýznamový identifikátor vodního IDVT, který již > dnes naše databáze obsahují. > V případném využití doporučujeme tento IDVT udržovat a přes něj provádět > jakékoli aktualizace nebo vazby. Tento IDVT přebírá postupně i ČÚZK do > ZaBaGeD. > > Offline data poskytujeme (cca 1x ročně) na našich stránkách: > http://www.pla.cz/planet/ram.aspx?id=21 v SHP formátu > a do budoucna uvažujeme o zřízení WMS či WFS online přístupů do naší > centrální databáze. > > Zároveň naše data a data, která jsme oprávněni využít i pro internetové > presentace jsou veřejně dostupná > přes GIS aplikaci http://www.pla.cz/gis/ , kde je vyžadován ActiveX > prvek MapGuide od firmy AutoDESK. > > Závěrem si dovolím konstaovat, že každý podnik Povodí řeší presentaci a > poskytování svých dat individuálně. > Přesto jsou vybraná data (převážně legislativně určená), která se > zveřejňují jednotně a ty jsou pak přístupná přes porál Ministerstva > zemědělství (MZe) a Životního prostředí (MŽP) > http://www.voda.gov.cz/portal/cz/ > > S pozdravem > > > > Pavel Staněk, správce GIS > ______________________________________ > Povodí Labe, státní podnik > Víta Nejedlého 951 > 500 03 Hradec Králové > tel. : +420 495 088 633 > e-mail : pstanek na pla.cz > http://www.pla.cz/ > --- > Dobrý den, > > chtěl jsem se zeptat, zda by bylo možné použít některá mapová díla > státního podniku Povodí Labe pro účely projektu OpenStreetMap. Zejména > pak osy vodních toků, vodní nádrže, ale i případně i další vhodné > objekty ve správě Povodí Labe (jezy atd.). Nekomerční projekt > OpenStreetMap má za cíl vytvoření svobodných a licencemi nezatížených > map, volně použitelných v otevřeném formátu pro všechny uživatele. V > současné době to vypadá tak, že přispěvatelé buď mapují území na základě > záznamů svých GPS zařízení, nebo odvozují mapy ze zdrojů, které toto > umožňují (převážně ortofotomapy ÚHUL, případně katastru nemovitostí ČÚZK). > > Více informací k uvedenému projektu naleznete zde: > > http://www.openstreetmap.org/ případně http://www.informationfreeway.org/ > a > http://wiki.openstreetmap.org/index.php/Cz:Main_Page > http://wiki.openstreetmap.org/index.php/WikiProject_Czechia > > Myslím, že česká komunita, mapující naši republiku v projektu > OpenStreetMap, by uvítala jakákoliv, případně i mírně generalizovaná > (znepřesněná) data, případně jakoukoliv formu licence k jejich použití > nebo vytvoření odvozeného mapového díla. Věříme, že tato a ostatní data > z projektu by byla v budoucnu dobře použitelná i pro Vaše zaměstnance > (podklady pro plány, prezentace, plánování či navigaci atp.), neboť je > lze exportovat přímo z centrálního úložiště v mnoha dostupných formátech > (mj. pro Garmin GPS atp.). > > Děkuji za jakoukoliv odpověď, s pozdravem > > Martin Kokeš > Dašická 1253 > 53003 Pardubice > tel. 777 136 677 > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Klidne se toho ujmu, jaky source tomu chcete priradit?

> Tomas Kolda píše v Út 21. 10. 2008 v 12:53 +0200: > >> Klidne se toho ujmu, jaky source tomu chcete priradit? >> > > Jak se bude řešit konflikt s již zakreslenými toky? > > Myslím, že spousta z nás strávila dlouhé hodiny mapováním všech meandrů > některé z řek a říček podle ortofotomapy. Takové podklady mohou být > přesnější, na druhou stranu jsme ale nemuseli správně odhadnout, které > z koryt v místě rozvětvení je považováno za hlavní (a také ÚHUL je místy > o pár metrů vedle). > > Také jsem narazil na problém oficiálního pojmenování malých říček, které > se zjišťuje poměrně problematicky. Místní je často nazývají jinými > jmény, než jsou uvedena na mapě. Zato místně zažitá jména často sedí > s mapou z předminulého století. > >

> Klidne se toho ujmu, jaky source tomu chcete priradit?

> > T > > Martin Kokeš napsal(a): >> Nedalo mi to a zeptal jsem se Povodí Labe na možnost využití jejich dat >> (osy vodních toků) ve formátu SHP, která poskytují na svých stránkách ke >> stažení a dostalo se mi kladné odpovědi od p. Staňka, správce jejich GIS >> i s doporučením. Ujmul by se prosím někdo importu? >> >> Martin Kokeš >> (shr3k) >> --- >> Dobrý den, >> >> filosofie našeho podniku je založena na principu, že data by měl >> poskytovat ten, který dané mapové objekty spravuje >> a to pokud možno zdarma. >> >> To je i odpovědí na Váš dotaz. >> Na našich stránkách poskytujeme osy vodních toků, cizí i ty, které >> spravujeme (cca 300 os vodohospodářsky významných toků z cca 20.000 >> všech os toků a meliorací na území našech Podniku = cca 1/5 ČR). Ty co >> spravujeme i aktualizujeme, a ty ostatní budou postupně aktualizovat >> jejich správci (Lesy ČR, Státní meliorační správa, Vojenské újezdy, ...) >> Centrálně tak existuje 5 databází na 5 podnicích Povodí, které dohromady >> pokrývají toky celé ČR. >> >> Co se týká IDéček, bylo na úrovni MZe odsouhlaseno, že bude používán >> jednoznačný číselný bezvýznamový identifikátor vodního IDVT, který již >> dnes naše databáze obsahují. >> V případném využití doporučujeme tento IDVT udržovat a přes něj provádět >> jakékoli aktualizace nebo vazby. Tento IDVT přebírá postupně i ČÚZK do >> ZaBaGeD. >> >> Offline data poskytujeme (cca 1x ročně) na našich stránkách: >> http://www.pla.cz/planet/ram.aspx?id=21 v SHP formátu >> a do budoucna uvažujeme o zřízení WMS či WFS online přístupů do naší >> centrální databáze. >> >> Zároveň naše data a data, která jsme oprávněni využít i pro internetové >> presentace jsou veřejně dostupná >> přes GIS aplikaci http://www.pla.cz/gis/ , kde je vyžadován ActiveX >> prvek MapGuide od firmy AutoDESK. >> >> Závěrem si dovolím konstaovat, že každý podnik Povodí řeší presentaci a >> poskytování svých dat individuálně. >> Přesto jsou vybraná data (převážně legislativně určená), která se >> zveřejňují jednotně a ty jsou pak přístupná přes porál Ministerstva >> zemědělství (MZe) a Životního prostředí (MŽP) >> http://www.voda.gov.cz/portal/cz/ >> >> S pozdravem >> >> >> >> Pavel Staněk, správce GIS >> ______________________________________ >> Povodí Labe, státní podnik >> Víta Nejedlého 951 >> 500 03 Hradec Králové >> tel. : +420 495 088 633 >> e-mail : pstanek na pla.cz >> http://www.pla.cz/ >> --- >> Dobrý den, >> >> chtěl jsem se zeptat, zda by bylo možné použít některá mapová díla >> státního podniku Povodí Labe pro účely projektu OpenStreetMap. Zejména >> pak osy vodních toků, vodní nádrže, ale i případně i další vhodné >> objekty ve správě Povodí Labe (jezy atd.). Nekomerční projekt >> OpenStreetMap má za cíl vytvoření svobodných a licencemi nezatížených >> map, volně použitelných v otevřeném formátu pro všechny uživatele. V >> současné době to vypadá tak, že přispěvatelé buď mapují území na základě >> záznamů svých GPS zařízení, nebo odvozují mapy ze zdrojů, které toto >> umožňují (převážně ortofotomapy ÚHUL, případně katastru nemovitostí ČÚZK). >> >> Více informací k uvedenému projektu naleznete zde: >> >> http://www.openstreetmap.org/ případně http://www.informationfreeway.org/ >> a >> http://wiki.openstreetmap.org/index.php/Cz:Main_Page >> http://wiki.openstreetmap.org/index.php/WikiProject_Czechia >> >> Myslím, že česká komunita, mapující naši republiku v projektu >> OpenStreetMap, by uvítala jakákoliv, případně i mírně generalizovaná >> (znepřesněná) data, případně jakoukoliv formu licence k jejich použití >> nebo vytvoření odvozeného mapového díla. Věříme, že tato a ostatní data >> z projektu by byla v budoucnu dobře použitelná i pro Vaše zaměstnance >> (podklady pro plány, prezentace, plánování či navigaci atp.), neboť je >> lze exportovat přímo z centrálního úložiště v mnoha dostupných formátech >> (mj. pro Garmin GPS atp.). >> >> Děkuji za jakoukoliv odpověď, s pozdravem >> >> Martin Kokeš >> Dašická 1253 >> 53003 Pardubice >> tel. 777 136 677 >> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Tomas Kolda napsal(a): > >> Klidne se toho ujmu, jaky source tomu chcete priradit? >> > > Že by "source=pla:dibavod"? > Nicméně: V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na vytištěném > listu takto: "(c) Zpracováno s použitím dat Povodí Labe, státní podnik" > > Toto je podmínka, kterou těžko v OSM splníme. To by chtělo vyjasnit. > > Zdroj: http://www.pla.cz/planet/ram.aspx?id=21 > > >> T >> >> Martin Kokeš napsal(a): >> >>> Nedalo mi to a zeptal jsem se Povodí Labe na možnost využití jejich dat >>> (osy vodních toků) ve formátu SHP, která poskytují na svých stránkách ke >>> stažení a dostalo se mi kladné odpovědi od p. Staňka, správce jejich GIS >>> i s doporučením. Ujmul by se prosím někdo importu? >>> >>> Martin Kokeš >>> (shr3k) >>> --- >>> Dobrý den, >>> >>> filosofie našeho podniku je založena na principu, že data by měl >>> poskytovat ten, který dané mapové objekty spravuje >>> a to pokud možno zdarma. >>> >>> To je i odpovědí na Váš dotaz. >>> Na našich stránkách poskytujeme osy vodních toků, cizí i ty, které >>> spravujeme (cca 300 os vodohospodářsky významných toků z cca 20.000 >>> všech os toků a meliorací na území našech Podniku = cca 1/5 ČR). Ty co >>> spravujeme i aktualizujeme, a ty ostatní budou postupně aktualizovat >>> jejich správci (Lesy ČR, Státní meliorační správa, Vojenské újezdy, ...) >>> Centrálně tak existuje 5 databází na 5 podnicích Povodí, které dohromady >>> pokrývají toky celé ČR. >>> >>> Co se týká IDéček, bylo na úrovni MZe odsouhlaseno, že bude používán >>> jednoznačný číselný bezvýznamový identifikátor vodního IDVT, který již >>> dnes naše databáze obsahují. >>> V případném využití doporučujeme tento IDVT udržovat a přes něj provádět >>> jakékoli aktualizace nebo vazby. Tento IDVT přebírá postupně i ČÚZK do >>> ZaBaGeD. >>> >>> Offline data poskytujeme (cca 1x ročně) na našich stránkách: >>> http://www.pla.cz/planet/ram.aspx?id=21 v SHP formátu >>> a do budoucna uvažujeme o zřízení WMS či WFS online přístupů do naší >>> centrální databáze. >>> >>> Zároveň naše data a data, která jsme oprávněni využít i pro internetové >>> presentace jsou veřejně dostupná >>> přes GIS aplikaci http://www.pla.cz/gis/ , kde je vyžadován ActiveX >>> prvek MapGuide od firmy AutoDESK. >>> >>> Závěrem si dovolím konstaovat, že každý podnik Povodí řeší presentaci a >>> poskytování svých dat individuálně. >>> Přesto jsou vybraná data (převážně legislativně určená), která se >>> zveřejňují jednotně a ty jsou pak přístupná přes porál Ministerstva >>> zemědělství (MZe) a Životního prostředí (MŽP) >>> http://www.voda.gov.cz/portal/cz/ >>> >>> S pozdravem >>> >>> >>> >>> Pavel Staněk, správce GIS >>> ______________________________________ >>> Povodí Labe, státní podnik >>> Víta Nejedlého 951 >>> 500 03 Hradec Králové >>> tel. : +420 495 088 633 >>> e-mail : pstanek na pla.cz >>> http://www.pla.cz/ >>> --- >>> Dobrý den, >>> >>> chtěl jsem se zeptat, zda by bylo možné použít některá mapová díla >>> státního podniku Povodí Labe pro účely projektu OpenStreetMap. Zejména >>> pak osy vodních toků, vodní nádrže, ale i případně i další vhodné >>> objekty ve správě Povodí Labe (jezy atd.). Nekomerční projekt >>> OpenStreetMap má za cíl vytvoření svobodných a licencemi nezatížených >>> map, volně použitelných v otevřeném formátu pro všechny uživatele. V >>> současné době to vypadá tak, že přispěvatelé buď mapují území na základě >>> záznamů svých GPS zařízení, nebo odvozují mapy ze zdrojů, které toto >>> umožňují (převážně ortofotomapy ÚHUL, případně katastru nemovitostí ČÚZK). >>> >>> Více informací k uvedenému projektu naleznete zde: >>> >>> http://www.openstreetmap.org/ případně http://www.informationfreeway.org/ >>> a >>> http://wiki.openstreetmap.org/index.php/Cz:Main_Page >>> http://wiki.openstreetmap.org/index.php/WikiProject_Czechia >>> >>> Myslím, že česká komunita, mapující naši republiku v projektu >>> OpenStreetMap, by uvítala jakákoliv, případně i mírně generalizovaná >>> (znepřesněná) data, případně jakoukoliv formu licence k jejich použití >>> nebo vytvoření odvozeného mapového díla. Věříme, že tato a ostatní data >>> z projektu by byla v budoucnu dobře použitelná i pro Vaše zaměstnance >>> (podklady pro plány, prezentace, plánování či navigaci atp.), neboť je >>> lze exportovat přímo z centrálního úložiště v mnoha dostupných formátech >>> (mj. pro Garmin GPS atp.). >>> >>> Děkuji za jakoukoliv odpověď, s pozdravem >>> >>> Martin Kokeš >>> Dašická 1253 >>> 53003 Pardubice >>> tel. 777 136 677 >>> >>> >>> >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >>> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > >

> Tomas Kolda napsal(a): > >> Klidne se toho ujmu, jaky source tomu chcete priradit? >> > > Že by "source=pla:dibavod"? > Nicméně: V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na vytištěném > listu takto: "(c) Zpracováno s použitím dat Povodí Labe, státní podnik" > > Toto je podmínka, kterou těžko v OSM splníme. To by chtělo vyjasnit. > > Zdroj: http://www.pla.cz/planet/ram.aspx?id=21 >

> Další otázkou je zda nezkusit využít přímo DIBAVOD celý. > http://www.vuv.cz/oddeleni-gis/17/o-projektu-dibavod.html >

> Martin Kokeš napsal(a): > >> Další otázkou je zda nezkusit využít přímo DIBAVOD celý. >> http://www.vuv.cz/oddeleni-gis/17/o-projektu-dibavod.html >> >> > Podíval jsem se na příslušné zákony, zejména 254/2001 Sb. a 391/2004 > Sb. kvůli nimž by DIBAVOD stvořen. Vzhledem k tomu, že DIBAVOD podléhá > zákonu 365/2000 Sb. o informačních systémech veřejné správy a na výstupy > z něj má právo každý bezplatně (pokud nepožaduje ověření) a to v > libovolném rozsahu (úplné či po částech), a je to veřejně přístupný > rejstřík (§ 3 121/2000 Sb.), nevztahuje se na něj ochrana podle > autorského zákona. > > MK > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou > podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i > louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, > ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat > vzorek rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti. > > Pokud nekdo najdete indicii, ze to nelze pouzit, reknete...

> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou > podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i louze :) > Bude potreba udelat nejakou simplifikaci a pridani jen toku, ktere maji > alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek rek, vodnich > nadrzi a obrysu brehu (riverbank) v nejake oblasti.

>> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou >> podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i louze :) >> Bude potreba udelat nejakou simplifikaci a pridani jen toku, ktere maji >> alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek rek, vodnich >> nadrzi a obrysu brehu (riverbank) v nejake oblasti. >> > Pokud budou ty data presna, tak bych je prilis nezjednodusoval. To > same pro ruzne potucky, skoro zadny nema oficialni nazev, ale jsou to > dulezite orientacni body. >

> > V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou > > podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i louze :) > > Bude potreba udelat nejakou simplifikaci a pridani jen toku, ktere maji > > alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek rek, vodnich > > nadrzi a obrysu brehu (riverbank) v nejake oblasti. > > Pokud budou ty data presna, tak bych je prilis nezjednodusoval. To > same pro ruzne potucky, skoro zadny nema oficialni nazev, ale jsou to > dulezite orientacni body.

> Zkusim udelat vzorek rek, vodnich nadrzi a obrysu brehu (riverbank) v > nejake oblasti.

>> Pokud budou ty data presna, tak bych je prilis nezjednodusoval. To >> same pro ruzne potucky, skoro zadny nema oficialni nazev, ale jsou to >> dulezite orientacni body. > > I bezejmenný potok, který nejde přeskočit, je pro pěšího turistu > důležitý. Přikláním se k tomu, aby se nezjednodušovalo.

> Zároveň to otestuje přesnost zákresu vodních ploch. Při zakreslování > z ortofotografie prakticky nelze odlišit oblast zarostlou rákosím od > pevniny, a mohutné stromy na břehu zakrývají výhled na vodní plochu.

> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou > podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i > louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, > ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek > rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti.

> Tomas Kolda napsal(a): > >> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou >> podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i >> louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, >> ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek >> rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti. >> > Tak jsem v ramci treningu skouknul DIBAVOD-A16 (brehove linie toku *) > a to da zhruba 1M bodu, 18MB v .osm.bz2 > > *) neobsahuje vodni nadrze ani linie tenkych toku, tu jsou v jinych > datovych souborech, viz: http://www.vuv.cz/oddeleni-gis/index.php?id=27 >

> Petr Nejedly napsal(a): >> Tomas Kolda napsal(a): >> >>> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou >>> podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i >>> louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, >>> ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek >>> rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti. >>> >> Tak jsem v ramci treningu skouknul DIBAVOD-A16 (brehove linie toku *) >> a to da zhruba 1M bodu, 18MB v .osm.bz2 >> >> *) neobsahuje vodni nadrze ani linie tenkych toku, tu jsou v jinych >> datovych souborech, viz: http://www.vuv.cz/oddeleni-gis/index.php?id=27 >> > > Já jsem se dival v ArcExploreru na ty vodní nádrže a rozhodně nelze > říct, že by tam byly nějaké zbytečné "louže". Proto navrhuju stejně jako > u břehových linií případnou korekci (odstranění zbytečných nodů) nechat > na ručním zpracování.

> No ja jsem se mezitim mrknul i na A01 (osy vsech toku) a to bylo bratru 5M > bodu a vsechno siroko daleko (cela republika) modre. > A kdyz jsem se koukal zblizka na horni tok moravy (od pramene po obec Horni > Morava, cili asi 8km), bylo tam spousta potucku ;-)

> Martin Kokeš napsal(a): >> Další otázkou je zda nezkusit využít přímo DIBAVOD celý. >> http://www.vuv.cz/oddeleni-gis/17/o-projektu-dibavod.html >> > Podíval jsem se na příslušné zákony, zejména 254/2001 Sb. a 391/2004 > Sb. kvůli nimž by DIBAVOD stvořen. Vzhledem k tomu, že DIBAVOD podléhá > zákonu 365/2000 Sb. o informačních systémech veřejné správy a na výstupy > z něj má právo každý bezplatně (pokud nepožaduje ověření) a to v > libovolném rozsahu (úplné či po částech)

>, a je to veřejně přístupný > rejstřík (§ 3 121/2000 Sb.), nevztahuje se na něj ochrana podle > autorského zákona.

> Dne 21. říjen 2008 19:12 Martin Kokeš <shr3k na typo3-hosting.com> napsal(a): > >> Martin Kokeš napsal(a): >> >>> Další otázkou je zda nezkusit využít přímo DIBAVOD celý. >>> http://www.vuv.cz/oddeleni-gis/17/o-projektu-dibavod.html >>> >>> >> Podíval jsem se na příslušné zákony, zejména 254/2001 Sb. a 391/2004 >> Sb. kvůli nimž by DIBAVOD stvořen. Vzhledem k tomu, že DIBAVOD podléhá >> zákonu 365/2000 Sb. o informačních systémech veřejné správy a na výstupy >> z něj má právo každý bezplatně (pokud nepožaduje ověření) a to v >> libovolném rozsahu (úplné či po částech) >> > *** kde se píše v 365/2000 Sb o poskytování bezplatného obsahu, na > prvni pohled jsem to nenašel? >

>> , a je to veřejně přístupný >> rejstřík (§ 3 121/2000 Sb.), nevztahuje se na něj ochrana podle >> autorského zákona. >> > *** o rejstřík IMHO nejde, jde o geodatabázi, která je odvozená z ZVH > mapy. Jako rejstřík bych považoval nejspíš evidenci knih v knihovně. >

> Petr Nejedly napsal(a): > >> No ja jsem se mezitim mrknul i na A01 (osy vsech toku) a to bylo bratru 5M >> bodu a vsechno siroko daleko (cela republika) modre. >> A kdyz jsem se koukal zblizka na horni tok moravy (od pramene po obec Horni >> Morava, cili asi 8km), bylo tam spousta potucku ;-) >> > Předpokládám, že potůček je "A naturally-formed waterway that is too > thin to be classed as a river. A person may be able to just jump over > it."Tak takový atribut OSM zná, stejně jako "An artificial waterway for > carrying storm water or industrial discharge. ". ;o) > Jako je jasné, že Saúdská Arábie se, co se týče vodstva asi bude mapovat > lépe, ale na druhou stranu, co mají říkat třeba Nizozemci nebo Finové, > že... :-) > > MK > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Jiri Klement napsal(a): > >> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou > >> podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i > >> louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, > >> ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek > >> rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti. > > > > Pokud budou ty data presna, tak bych je prilis nezjednodusoval. To > > same pro ruzne potucky, skoro zadny nema oficialni nazev, ale jsou to > > dulezite orientacni body. > > Mám stejný názor. Myslel jsem si také, že tu děláme mapy a ne jakési > pseudokartogramy... :-)

> +1 > > prolítnul jsem si maily o konkrétních velikostech ... s lehkým přimhouřením > oka se dá říci, že Mooreův zákon stále funguje, takže co se nám dnes zdá z > hlediska zpracování nepředstavitelně veliké a podrobné bude za chvíli "uboze > jednoduché" > > nejsem sice přítelem vynucování hardwarových upgradů, nicméně neměli bychom se > tomu bránit za cenu zahazování kvalitních dat, nýbrž zkvalitněním jejich > zpracování > (a teď si jdu zamést před vlastním prahem a dát si do úkolů při zprovozňování > svého generátoru dlaždic, že nemám plýtvat přenosovou kapacitou na stahování > celého snapshotu, když lze - pokud vím - získat jen rozdílové aktualizace) > > just my €0.02 ;-) > > K. > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Typ waterway bych detekoval podle nazvu. Pokud tam bude slovo potok > tak potok, jinak reka. Vse bez nazvu bych dal take potok. Take muzem > pomoci distinct vyjet vsechny nazvy a nekdo muze oznacit seznam co je > reka... Zbytek se doupravi rucne.

> Tomas Kolda píše v Čt 23. 10. 2008 v 10:32 +0200: > >> Typ waterway bych detekoval podle nazvu. Pokud tam bude slovo potok >> tak potok, jinak reka. Vse bez nazvu bych dal take potok. Take muzem >> pomoci distinct vyjet vsechny nazvy a nekdo muze oznacit seznam co je >> reka... Zbytek se doupravi rucne. >> > > To nebude fungovat příliš dobře. > > Botič je potok. > > Hamerský potok je řeka. > > Zlatá stoka je umělý kanál. > > A například Nová řeka je také umělý kanál. > >

> Pro prvni rozhozeni do kategorii to bude stacit. Pote seznam > doopravime rucne a ten se pouzije. > > Jinak jsou stejne jen 2-3 pouzitelne kategorie > (waterway/river,canal?,stream). V OSM bych rekl, ze spise vyjadruji > sirku pri kresleni, takze by botic jako river asi nevadil. > > T > > Stanislav Brabec napsal(a): >> Tomas Kolda píše v Čt 23. 10. 2008 v 10:32 +0200: >> >>> Typ waterway bych detekoval podle nazvu. Pokud tam bude slovo potok >>> tak potok, jinak reka. Vse bez nazvu bych dal take potok. Take muzem >>> pomoci distinct vyjet vsechny nazvy a nekdo muze oznacit seznam co je >>> reka... Zbytek se doupravi rucne. >>> >> >> To nebude fungovat příliš dobře. >> >> Botič je potok. >> >> Hamerský potok je řeka. >> >> Zlatá stoka je umělý kanál. >> >> A například Nová řeka je také umělý kanál. >> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ahoj, > > takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo > by to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli > prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam > jsou.Polygony a brehy jeste dodelavam. > > Podivejte na super prehnanou presnost u nekterych potucku, presne jak > jsem rikal. > > http://www.web2net.cz/osm/dibavod.zip > > Zitra uz snad poslu nejakej zdrojacek at si muzete hrat. Spise jeste > bude prace s navazanim "krizovatek", ale to asi udelam jen prostorove. > > T > > PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at > nezavisle potvrdi tu moznost pouziti. Ja se v pravni hantyrce > neorientuji... Jen abysme to pak cele nemuseli revertovat. > > > Tomas Kolda napsal(a): >> Pro prvni rozhozeni do kategorii to bude stacit. Pote seznam >> doopravime rucne a ten se pouzije. >> >> Jinak jsou stejne jen 2-3 pouzitelne kategorie >> (waterway/river,canal?,stream). V OSM bych rekl, ze spise vyjadruji >> sirku pri kresleni, takze by botic jako river asi nevadil. >> >> T >> >> Stanislav Brabec napsal(a): >>> Tomas Kolda píše v Čt 23. 10. 2008 v 10:32 +0200: >>> >>>> Typ waterway bych detekoval podle nazvu. Pokud tam bude slovo potok >>>> tak potok, jinak reka. Vse bez nazvu bych dal take potok. Take muzem >>>> pomoci distinct vyjet vsechny nazvy a nekdo muze oznacit seznam co je >>>> reka... Zbytek se doupravi rucne. >>>> >>> >>> To nebude fungovat příliš dobře. >>> >>> Botič je potok. >>> >>> Hamerský potok je řeka. >>> >>> Zlatá stoka je umělý kanál. >>> >>> A například Nová řeka je také umělý kanál. >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ahoj, > > takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by > to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli > prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam > jsou.Polygony a brehy jeste dodelavam. >

> > Podivejte na super prehnanou presnost u nekterych potucku, presne jak > jsem rikal. > > http://www.web2net.cz/osm/dibavod.zip > > Zitra uz snad poslu nejakej zdrojacek at si muzete hrat. Spise jeste > bude prace s navazanim "krizovatek", ale to asi udelam jen prostorove. > > T > > PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at > nezavisle potvrdi tu moznost pouziti. Ja se v pravni hantyrce > neorientuji... Jen abysme to pak cele nemuseli revertovat. > > > Tomas Kolda napsal(a):

> Mě teda ta přesnost nepřipadá nijak přehnaně vysoká, ne pokud si děláme > ambice, že to jednou může sloužit i jako turistická mapa. Později bychom > toho mohli litovat, protože například podle detailů ve tvaru těch řek by > šlo odhadnout polohu různých objektů při podrobném mapování (cesta vede > podel řeky a odpojí se u třetího meandru). > Nemám úplně představu, kolik to bude zabírat celkem, ale pokud se to vejde > do 50MB (po komprimaci), tak bych o tom osobně nepřemýšlel. Byl bych spíš > pro to, aby se udělala generalizovaná verze czehie určená pro export do > různých zařízení (například do navigace se možná řeky nemusí exportovat > vůbec). >

> On Fri, 24 Oct 2008 00:33:55 +0200, Tomas Kolda <kolda na web2net.cz> wrote: > > >> Ahoj, >> >> takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by >> to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli >> prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam >> jsou.Polygony a brehy jeste dodelavam. >> >> > > Mě teda ta přesnost nepřipadá nijak přehnaně vysoká, ne pokud si děláme > ambice, že to jednou může sloužit i jako turistická mapa. Později bychom > toho mohli litovat, protože například podle detailů ve tvaru těch řek by > šlo odhadnout polohu různých objektů při podrobném mapování (cesta vede > podel řeky a odpojí se u třetího meandru). > Nemám úplně představu, kolik to bude zabírat celkem, ale pokud se to vejde > do 50MB (po komprimaci), tak bych o tom osobně nepřemýšlel. Byl bych spíš > pro to, aby se udělala generalizovaná verze czehie určená pro export do > různých zařízení (například do navigace se možná řeky nemusí exportovat > vůbec). > Možná by bylo dobré spojit stejnou řeku na křižovatce do jedné (na silnice > jsem si udělal xslt, zítra můžu poslat) > > >> Podivejte na super prehnanou presnost u nekterych potucku, presne jak >> jsem rikal. >> >> http://www.web2net.cz/osm/dibavod.zip >> >> Zitra uz snad poslu nejakej zdrojacek at si muzete hrat. Spise jeste >> bude prace s navazanim "krizovatek", ale to asi udelam jen prostorove. >> >> T >> >> PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at >> nezavisle potvrdi tu moznost pouziti. Ja se v pravni hantyrce >> neorientuji... Jen abysme to pak cele nemuseli revertovat. >> >> >> Tomas Kolda napsal(a): >> > > > > >

> Možná by bylo dobré spojit stejnou řeku na křižovatce do jedné (na > silnice > jsem si udělal xslt, zítra můžu poslat) > >

> Jaka by mela byt vyhoda spojovani? Vzdyt nechceme polygony a cary o > rozmerech nekolika kilometru.... U silnic to ma navic za nasledek, ze se > pak neda routovat. Co jsi spojoval na silnicich? Nebo to detekuje > krizovatku o dvou hranach a vice nespojuje? > > T >

> On Fri, 24 Oct 2008 07:14:14 +0200, Tomas Kolda <kolda na web2net.cz> wrote: > > Automaticky jsem na silnicích nic nespojoval. Používal jsem to při > vytváření toho grafu (aby se vymazal bod, pokud je ta silnice někde > uprostřed přerušená). > > Ručně jsem ovšem některé silnice spojoval, protože mi to tak připadá lepší > (možá si ale neuvědomuji nějakou zradu). Silnice pocházející z importu > jsou toti přerušené v místě neexistující křižovatky, což má za následek, > že když si toho někdo nevšimne a udělá křižovatku kousek vedle, tak je pak > to přerušení kousek za křižovatkou. Další výhoda je, že pokud je nutné > změnit tag, tak to stačí udělat na míň místech, a pokud je nutné mít > rozdílný tag pro část té waye, tak to bude pravděpodobně stejně nutné > přerušit. > Opravdu je to s tím routováním pravda? Vždyť většina silnic není na > (všech) křižovatkách přerušená. > Jestli ale má spojování nějakou zásadní nevýhodu, tak s tím přestanu. > > >> Jaka by mela byt vyhoda spojovani? Vzdyt nechceme polygony a cary o >> rozmerech nekolika kilometru.... U silnic to ma navic za nasledek, ze se >> pak neda routovat. Co jsi spojoval na silnicich? Nebo to detekuje >> krizovatku o dvou hranach a vice nespojuje? >> >> T >> >> > > > >

> Ano to s tim routovanim pravda je. Je to tim, ze graf (vrcholy a hrany) > urcuji way, kde vrchol je pocatecni a koncovy nodeID. To jsou prave ty > krizovatky. Kdyz je spojis do jedne way napr. u Tckove krizovatky tak > pak bude ta treti slepa, protoze nema navaznou way, ktera zacina stenym > nodeID jako ona konci.... Orientace u jednosmerne hrany se urcuje stejne > jako u graficke mapy (oneway). Proto se nesmi spojovat napric > krizovatkou. > > Slo by to v pripade, ze nekdo kdo dela routovani bude kontrolovat kazdy > nodeID v way a kdyz uvidi, ze je obsazen koncovy z jine cesty tak tam > umele udela krizovatku. To je ale velika nevyhoda, protoze ty nemuzes > implicitne predpokladat krizovatku pro kazdy sdileny nod. Proto se to > dela explicitne tim sekanim.

> > Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres > pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v > OSM dela... > > T > > > Petr Dlouhý napsal(a): >> On Fri, 24 Oct 2008 07:14:14 +0200, Tomas Kolda <kolda na web2net.cz> >> wrote: >> >> Automaticky jsem na silnicích nic nespojoval. Používal jsem to při >> vytváření toho grafu (aby se vymazal bod, pokud je ta silnice někde >> uprostřed přerušená). >> >> Ručně jsem ovšem některé silnice spojoval, protože mi to tak připadá >> lepší >> (možá si ale neuvědomuji nějakou zradu). Silnice pocházející z importu >> jsou toti přerušené v místě neexistující křižovatky, což má za následek, >> že když si toho někdo nevšimne a udělá křižovatku kousek vedle, tak je >> pak >> to přerušení kousek za křižovatkou. Další výhoda je, že pokud je nutné >> změnit tag, tak to stačí udělat na míň místech, a pokud je nutné mít >> rozdílný tag pro část té waye, tak to bude pravděpodobně stejně nutné >> přerušit. >> Opravdu je to s tím routováním pravda? Vždyť většina silnic není na >> (všech) křižovatkách přerušená. >> Jestli ale má spojování nějakou zásadní nevýhodu, tak s tím přestanu. >> >> >>> Jaka by mela byt vyhoda spojovani? Vzdyt nechceme polygony a cary o >>> rozmerech nekolika kilometru.... U silnic to ma navic za nasledek, ze >>> se >>> pak neda routovat. Co jsi spojoval na silnicich? Nebo to detekuje >>> krizovatku o dvou hranach a vice nespojuje? >>> >>> T >>> >>> >> >> >> >> >

> Ano to s tim routovanim pravda je. Je to tim, ze graf (vrcholy a hrany) > urcuji way, kde vrchol je pocatecni a koncovy nodeID. To jsou prave ty > krizovatky. Kdyz je spojis do jedne way napr. u Tckove krizovatky tak > pak bude ta treti slepa, protoze nema navaznou way, ktera zacina stenym > nodeID jako ona konci.... Orientace u jednosmerne hrany se urcuje stejne > jako u graficke mapy (oneway). Proto se nesmi spojovat napric krizovatkou. > > Slo by to v pripade, ze nekdo kdo dela routovani bude kontrolovat kazdy > nodeID v way a kdyz uvidi, ze je obsazen koncovy z jine cesty tak tam > umele udela krizovatku. To je ale velika nevyhoda, protoze ty nemuzes > implicitne predpokladat krizovatku pro kazdy sdileny nod. Proto se to > dela explicitne tim sekanim.

> Ahoj, > > takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by > to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli > prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam > jsou.Polygony a brehy jeste dodelavam. > > Podivejte na super prehnanou presnost u nekterych potucku, presne jak > jsem rikal. > > http://www.web2net.cz/osm/dibavod.zip

> Uff, fakt nekdo videl navigaci nad OSM, ktera by mela problem s prubeznou > silnici? I ten gpsmid do mobilu si, krome grafu pro renderovani grafiky > predpocita i separatni routovaci graf, ktery obsahuje prave jen ty krizovatky > (nalezene automaticky i na tech prubeznych krizovatkach) a zadne mezilehle nody > (protoze proc by routovaci algoritmus melo zajimat, krome prirazene ceny spojnice, > kudy se dana cesta krouti). > > Naopak, kdyz bych si predstavil mapu New Yorku, ve ktere by kazdy ten 200yardovy > usek ulice mezi dvema avenue mela byt separatni way, asi bych se opupinkoval > pri predstave, ze jsem udelal typo v nazvu jedne ulice. > > Zaver: Spojujte ulice, spojujte silnice. Jedine, co vam v tom muze zabranit > jsou odlisne parametry segmentu (bridge, speed limit), kde by OSM uzila mirne > hierarchicky model (tohle je way II/601 a sklada se z techto casti). Ale to vlastne > pouzivaji napriklad cyklisti s relacema, ze? > >

> Tomas Kolda napsal(a): > >> Ahoj, >> >> takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by >> to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli >> prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam >> jsou.Polygony a brehy jeste dodelavam. >> >> Podivejte na super prehnanou presnost u nekterych potucku, presne jak >> jsem rikal. >> >> http://www.web2net.cz/osm/dibavod.zip >> > > Mohl bys, prosim, zkusit udelat kousek na hornim toku Moravy? > Mapoval jsem ho podle ortofoto, ale nakonec jsem to doladil podle katastru, > a muj pokusny import DIBAVODu mel stejny tvar krivek, ale byl o par (desitek) metru mimo.... > http://www.openstreetmap.org/?lat=50.15321&lon=16.81535&zoom=17&layers=B000FTF > >

> V tom pripade se pouziva to co jsem psal v druhem odstavci (sekani ways > pomoci algoritmu, jenz urcuje zda tam krizovatka je ci neni). Komercni > navigacni data napr. multinet jsou skutecne rozsekana po castech (format > GDF). > Jestli je to v OSM takto zavedene, tak proc ne. Asi tento zpusob > zpracovani zavedli, protoze je tak kreslena vetsina silnic. Osobne bych > volil druhou variantu, ale na to uz je pozde...

> Vecer neco poslu. Ja vybral oblast kde jsou polygony, linie i riverbank. > Kdyz posles bounding rect udelam oblast na morave. Hlavne at to neni moc > velike...

> Jinak kdyz to dam do JOSMu a pak stahnu okoli, tak ta oblast co jsem > posilal sedi skoro presne...

> Ahoj, > > On Fri, Oct 24, 2008 at 09:48:37AM +0200, Tomas Kolda wrote: > >> V tom pripade se pouziva to co jsem psal v druhem odstavci (sekani ways >> pomoci algoritmu, jenz urcuje zda tam krizovatka je ci neni). Komercni >> navigacni data napr. multinet jsou skutecne rozsekana po castech (format >> GDF). >> Jestli je to v OSM takto zavedene, tak proc ne. Asi tento zpusob >> zpracovani zavedli, protoze je tak kreslena vetsina silnic. Osobne bych >> volil druhou variantu, ale na to uz je pozde... >> > > ber to tak, ze z aktualni varianty do tve varianty se to da kdykoliv > zkonvertovat 'online' (napr. pri buildovani routovacich dat - tak to dela > Garmin - ma ulozeny cary jako spojnice + routovaci graf zvlast, mimo jine > proto v Garminu nefunguje aktualne routovani nad OSM :). > Obracene to jde hur (nemuzu jen tak spojovat automaticky veci). > >

> V tom pripade se pouziva to co jsem psal v druhem odstavci (sekani ways > pomoci algoritmu, jenz urcuje zda tam krizovatka je ci neni). Komercni > navigacni data napr. multinet jsou skutecne rozsekana po castech (format > GDF).

> Jestli je to v OSM takto zavedene, tak proc ne. Asi tento zpusob > zpracovani zavedli, protoze je tak kreslena vetsina silnic. Osobne bych > volil druhou variantu, ale na to uz je pozde...

> T > > Petr Nejedly napsal(a): >> Uff, fakt nekdo videl navigaci nad OSM, ktera by mela problem s prubeznou >> silnici? I ten gpsmid do mobilu si, krome grafu pro renderovani grafiky >> predpocita i separatni routovaci graf, ktery obsahuje prave jen ty krizovatky >> (nalezene automaticky i na tech prubeznych krizovatkach) a zadne mezilehle nody >> (protoze proc by routovaci algoritmus melo zajimat, krome prirazene ceny spojnice, >> kudy se dana cesta krouti). >> >> Naopak, kdyz bych si predstavil mapu New Yorku, ve ktere by kazdy ten 200yardovy >> usek ulice mezi dvema avenue mela byt separatni way, asi bych se opupinkoval >> pri predstave, ze jsem udelal typo v nazvu jedne ulice. >> >> Zaver: Spojujte ulice, spojujte silnice. Jedine, co vam v tom muze zabranit >> jsou odlisne parametry segmentu (bridge, speed limit), kde by OSM uzila mirne >> hierarchicky model (tohle je way II/601 a sklada se z techto casti). Ale to vlastne >> pouzivaji napriklad cyklisti s relacema, ze? >> >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> ------------ Původní zpráva ------------ > Od: Tomas Kolda <kolda na web2net.cz> > Předmět: Re: [Talk-cz] Možnost využití dat Povodí Labe > Datum: 24.10.2008 10:10:10 > ---------------------------------------- > Ja to delam presne obracene, pro grafiku spojuji entity se stejnymi > atributy a navigacni data beru tak jak jsou. Proste to pro OSM > upravim... A stejne tak se to bude muset udelat pro Garmin, jak rikas. > > A timto bych uzavrel tenhle offtopic :) > > T > > Ondrej Novy napsal(a): >

> Já bych ho změnil spátky na "intopic" tím, že bych zopakoval požadavek na spojení těch řek na úseky o nějaké rozumné délce (například po 30Km). Myslím, že se s tím pak bude líp pracovat a zmenší se tím velikost výsledného souboru.

> PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at nezavisle > potvrdi tu moznost pouziti. Ja se v pravni hantyrce neorientuji... Jen > abysme to pak cele nemuseli revertovat.

> Petr Nejedly uz psal, ale asi to zapadlo: > V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na > vytištěném listu > takto: "(c) Zpracováno s použitím dat Povodí Labe" > http://www.pla.cz/planet/ram.aspx?id=21 > > 2008/10/24 Tomas Kolda <kolda na web2net.cz>: > >> PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at nezavisle >> potvrdi tu moznost pouziti. Ja se v pravni hantyrce neorientuji... Jen >> abysme to pak cele nemuseli revertovat. >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Ano to s tim routovanim pravda je. Je to tim, ze graf (vrcholy a hrany) > urcuji way, kde vrchol je pocatecni a koncovy nodeID. To jsou prave ty > krizovatky. Kdyz je spojis do jedne way napr. u Tckove krizovatky tak > pak bude ta treti slepa, protoze nema navaznou way, ktera zacina stenym > nodeID jako ona konci.... Orientace u jednosmerne hrany se urcuje > stejne jako u graficke mapy (oneway). Proto se nesmi spojovat napric > krizovatkou. > Slo by to v pripade, ze nekdo kdo dela routovani bude kontrolovat kazdy > nodeID v way a kdyz uvidi, ze je obsazen koncovy z jine cesty tak tam > umele udela krizovatku. To je ale velika nevyhoda, protoze ty nemuzes > implicitne predpokladat krizovatku pro kazdy sdileny nod. Proto se to > dela explicitne tim sekanim.

> Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres > pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v > OSM dela...

> Slo by to v pripade, ze nekdo kdo dela routovani bude kontrolovat kazdy > nodeID v way a kdyz uvidi, ze je obsazen koncovy z jine cesty tak tam umele > udela krizovatku. To je ale velika nevyhoda, protoze ty nemuzes implicitne > predpokladat krizovatku pro kazdy sdileny nod. Proto se to dela explicitne > tim sekanim.

> Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres > pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v OSM > dela...

> Já bych ho změnil spátky na "intopic" tím, že bych zopakoval požadavek na spojení těch řek na úseky o nějaké rozumné délce (například po 30Km). Myslím, že se s tím pak bude líp pracovat a zmenší se tím velikost výsledného souboru.

> > Jinak sdidelni nazvu pres vsechny cesty by mohlo jit udelat pres > > pojmenovanou relaci, ne? Nikdy jsem to nedelal, ale mozna se to tak v OSM > > dela... > > Nic takovyho jsem v OSM nevidel. V praxi clovek musi pojmenovat vsechny kousky.

> Petr Nejedly uz psal, ale asi to zapadlo: > V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na > vytištěném listu > takto: "(c) Zpracováno s použitím dat Povodí Labe" > http://www.pla.cz/planet/ram.aspx?id=21

>> Petr Nejedly uz psal, ale asi to zapadlo: >> V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na >> vytištěném listu >> takto: "(c) Zpracováno s použitím dat Povodí Labe" >> http://www.pla.cz/planet/ram.aspx?id=21 >> > > No, pokud jsem to spravne pochopil, tak nam to povodi Labe pisemne > dovolilo pouzit :-). Mohli bychom se jich jeste extra zeptat... > > Je nekde ke stazeni v osm formatu dibavod pro celou republiku? > Zajimalo by me treba okoli Rican... > Pavel >

> Je to strasne velike, takze s uploadem cekam az nekdo alespon rekne, ze > ten vyrez je prijatelnej... > > T >

> Já taky teda nevím, díval jsem se právě na ty rybníčky a někdy mám > pocit, že veškerá moje předešlá práce by taky asi chtěla > zgeneralizovat, protože moje zákruty silnic jsou až moc objemné... ;o) > > Otázkou je, proč nemít přesnou databázi a teprve výstupy z ní třeba > pro málo výkonné přístroje generalizovat. Případně opravovat velké > shluky bodů ručně. Podle mého názoru v případě břehů řek a břehů > vodních nádrží je totiž myslím prioritou mít přesná data. Imaginární > linie, jako je střed řeky, už tak přesný potřeba není (s ohledem na to > jak se řeka následně renderuje). > > MK > > ------------------------------------------------------------------------ > *From:* Petr Dlouhý [mailto:petr.dlouhy na email.cz] > *To:* talk-cz na openstreetmap.org > *Sent:* Mon, 27 Oct 2008 18:18:59 +0100 > *Subject:* Re: [Talk-cz] Mo?nost vyu?it? dat Povod? Labe > > On Mon, 27 Oct 2008 17:15:09 +0100, Tomas Kolda <kolda na web2net.cz > <mailto:kolda na web2net.cz>> wrote: > > Jo, mě ten výřez přišel v pořádku. Osobně bych tu generalizaci > nedělal (až > na těch několik zhlukků cca 10 bodů u případě Sázavy), ale i ty 2 > metry > jsou celkem přijatelné (akorát malé nádrže to udělá dost hranaté). > Pokud > jsou ty čísla od dibavodu pro každý úsek řeky, tak to asi opravdu > nemá > cenu spojovat. Taky jsem úplně nepochopil, jak je to přesně s těmi > velikostmi (kolik přesěn měří jednotlivé varianty, jestli včetně > břehů, > nebo bez nich a taky bzip2 podle mých pokusů zkomprimuje hůř, > takže kolik > to měří v bz). > > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Jo, mě ten výřez přišel v pořádku. Osobně bych tu generalizaci nedělal (až

> na těch několik zhlukků cca 10 bodů u případě Sázavy), ale i ty 2 metry > jsou celkem přijatelné (akorát malé nádrže to udělá dost hranaté). Pokud

> jsou ty čísla od dibavodu pro každý úsek řeky, tak to asi opravdu nemá > cenu spojovat. Taky jsem úplně nepochopil, jak je to přesně s těmi > velikostmi (kolik přesěn měří jednotlivé varianty, jestli včetně břehů, > nebo bez nich a taky bzip2 podle mých pokusů zkomprimuje hůř, takže kolik > to měří v bz).

> Skoda jen, ze maximalne presne je hodne relativni. Chtel bych videt zda je > neco v OSM s presnosti odchylky zakruty 2m. Jelikoz se pouzivaji nastroje > jako GPS a ortofoto, tak o tom dost pochybuji.

> Slo mi o to zbytecne OSM nezatezovat. Cele vody (6mil bodu), je mnohem vice > nez cela czechia. Hezky to ukazuje generalizace na 1 metr, kde odpadne 30%

> bodu. Ja kdyz neco zakresluji tak automaticky delam optimalizaci a presnost > se pohybuje rekl bych min kolem 2 metru. > > Ale necham se ukecat.

> > Ale necham se ukecat. >

> Cena za výpočetní > výkon, který daný objem dat spotřebuje bude jistě řádově nižší. > Skutečným argumentem by pro mě bylo, kdyby přesnost těch dat byla > nepřiměřená pro danou metodu mapování, a tudíž by už nebyla zachycena > žádná další informace o realitě. >

> On Mon, 27 Oct 2008 19:17:23 +0100, Tomas Kolda <kolda na web2net.cz> wrote: > > >> Ale necham se ukecat. >> >> > > Dobře. Moje argumenty proti generalizaci jsou: > > -Dnes se zdá 100 nebo 200MB moc, ale je to způsobené tím, že tu databázi > máme poměrně prázdnou. Jak budeme postupně přidávat další data, tak se ten > objem stane přiměřeným vzhledem ke svému významu. > Je otázka jak moc by bylo složité ty data případně časem vyměnit za > přesnější; aktualizaci se stejně asi nevyhneme (pokud nám budou data > poskytnuta i příště), takže by to asi bylo možné udělat při ní. > Je také jasné, že se tak jako tak časem nevyhneme generalizaci dat > určených pro pomalejší zařízení. > Pokud by s tím ale měly servery Openstreetmap opravdové problémy, tak je > to pro mě argument, který budu akceptovat. > > -Na mapování silnic trávím docela dost času, a docela by mě naštvalo, > kdyby je prostě někdo jen tak generalizoval. Na těch vodách sice > nepracoval nikdo z nás, ale je to práce, kterou nám někdo dává jen tak. > Nemám sice s kartografií nic společného, ale myslím že cena práce která je > v těch datech bude určitě v řádu milionů (nebo i víc). Cena za výpočetní > výkon, který daný objem dat spotřebuje bude jistě řádově nižší. > Skutečným argumentem by pro mě bylo, kdyby přesnost těch dat byla > nepřiměřená pro danou metodu mapování, a tudíž by už nebyla zachycena > žádná další informace o realitě. > > -Na dibavodu píšou, že se data hodí pro mapy s měřítkem 1:10 000 až 1:50 > 000. Mapy na orientační běh mají měřítko 1:5 000 až 1:15 000 (nejčastěji > 1:10 000). V současné době data v OSM nemají kvalitu, která by se vůbec > blížila možnosti je využít při tvorbě map na OB, ale tu možnost bych jen > tak nezahazoval. Nějaké příklady map na OB jsou třeba tady: > <http://dkp.orienteering.cz/Kotlarka/mapy.html>. > Určitě se najdou i další možnosti využití tak přesných dat. > >

> > Prosim tedy o: > - Kontrolu lokalizace > - Kontrolu nazvu rek, rybniku apod. > - Kontrolu nekolika der > - Kouknuti do generovanych XML (staci 1, protoze ostatni jsou dle > sablony) zda jsou vsechny tagy apod. jak chceme. > - Kontrolu licence :). Ja vim, ze s tim porad otravuju, ale asi je to > nejvice dulezite... > > Jeste dodelam ty brehy (riverbank). > > T >

> On Mon, 27 Oct 2008 21:36:36 +0100, Tomas Kolda <kolda na web2net.cz> wrote: > > Jo, zapoměl jsem na jednu věc, která v tom výřezu chyběla. Byli tam > použity zkratky místo celých názvů (v. n. místo vodní nádrž). > Předpokládám, že to tak je už ve zdrojových datech. Nešlo by to náhodou > rozvinout do plných názvů automaticky? > > >> Prosim tedy o: >> - Kontrolu lokalizace >> - Kontrolu nazvu rek, rybniku apod. >> - Kontrolu nekolika der >> - Kouknuti do generovanych XML (staci 1, protoze ostatni jsou dle >> sablony) zda jsou vsechny tagy apod. jak chceme. >> - Kontrolu licence :). Ja vim, ze s tim porad otravuju, ale asi je to >> nejvice dulezite... >> >> Jeste dodelam ty brehy (riverbank). >> >> T >> >> > > >

> Ted si uvedomuju, ze vlastne nemame zapracovane to rozhodovani mezi > river a stream (seznam jsem posilal). Takze finalni dump to stejne asi > neni... > > Do finalniho muzeme toto zapracovat. > > T > > Petr Dlouhý napsal(a): >> On Mon, 27 Oct 2008 21:36:36 +0100, Tomas Kolda <kolda na web2net.cz> wrote: >> >> Jo, zapoměl jsem na jednu věc, která v tom výřezu chyběla. Byli tam >> použity zkratky místo celých názvů (v. n. místo vodní nádrž). >> Předpokládám, že to tak je už ve zdrojových datech. Nešlo by to náhodou >> rozvinout do plných názvů automaticky? >> >> >>> Prosim tedy o: >>> - Kontrolu lokalizace >>> - Kontrolu nazvu rek, rybniku apod. >>> - Kontrolu nekolika der >>> - Kouknuti do generovanych XML (staci 1, protoze ostatni jsou dle >>> sablony) zda jsou vsechny tagy apod. jak chceme. >>> - Kontrolu licence :). Ja vim, ze s tim porad otravuju, ale asi je to >>> nejvice dulezite... >>> >>> Jeste dodelam ty brehy (riverbank). >>> >>> T >>> >>> >> >> >> > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Je otázka jak moc by bylo složité ty data případně časem vyměnit za > přesnější; aktualizaci se stejně asi nevyhneme (pokud nám budou data

> poskytnuta i příště), takže by to asi bylo možné udělat při ní. > Je také jasné, že se tak jako tak časem nevyhneme generalizaci dat > určených pro pomalejší zařízení.

> Pokud by s tím ale měly servery Openstreetmap opravdové problémy, tak je > to pro mě argument, který budu akceptovat.

> -Na dibavodu píšou, že se data hodí pro mapy s měřítkem 1:10 000 až 1:50 > 000. Mapy na orientační běh mají měřítko 1:5 000 až 1:15 000 (nejčastěji > 1:10 000). V současné době data v OSM nemají kvalitu, která by se vůbec > blížila možnosti je využít při tvorbě map na OB, ale tu možnost bych jen

> tak nezahazoval. Nějaké příklady map na OB jsou třeba tady: > <http://dkp.orienteering.cz/Kotlarka/mapy.html>. > Určitě se najdou i další možnosti využití tak přesných dat.

>Martin Kokeš: > Ano stejný názor na to mám také já. S ohledem na velikost celé databáze > se jedná stále o relativně málo dat. Ať tak nebo tak, OSM projekt bude > muset v budoucnu přejít na výkonnější HW případně MySQL cluster, přičemž

> osobně raději přispěju nějakým obolusem na něco lepšího než je aktuální > Athlon X2 5200 a 8 GB paměti.

> - Kontrolu licence :). Ja vim, ze s tim porad otravuju, ale asi je to > nejvice dulezite...

> Tak jeste jsem to ani nenahral a uz je tam chyba, ktera josmu nevadi, > ale osmosis jo (redefinuji spolecne nody). Udelam to tedy naopak. > Zkusim nahrat databazi a budem vylepsovat exportovaci skript... > > Mazu tedy jiz uploadnute at tam nekdo nema chyby... > > T > > Tomas Kolda napsal(a): >> Ted si uvedomuju, ze vlastne nemame zapracovane to rozhodovani mezi >> river a stream (seznam jsem posilal). Takze finalni dump to stejne >> asi neni... >> >> Do finalniho muzeme toto zapracovat. >> >> T >> >> Petr Dlouhý napsal(a): >>> On Mon, 27 Oct 2008 21:36:36 +0100, Tomas Kolda <kolda na web2net.cz> wrote: >>> >>> Jo, zapoměl jsem na jednu věc, která v tom výřezu chyběla. Byli tam >>> použity zkratky místo celých názvů (v. n. místo vodní nádrž). >>> Předpokládám, že to tak je už ve zdrojových datech. Nešlo by to náhodou >>> rozvinout do plných názvů automaticky? >>> >>> >>>> Prosim tedy o: >>>> - Kontrolu lokalizace >>>> - Kontrolu nazvu rek, rybniku apod. >>>> - Kontrolu nekolika der >>>> - Kouknuti do generovanych XML (staci 1, protoze ostatni jsou dle >>>> sablony) zda jsou vsechny tagy apod. jak chceme. >>>> - Kontrolu licence :). Ja vim, ze s tim porad otravuju, ale asi je to >>>> nejvice dulezite... >>>> >>>> Jeste dodelam ty brehy (riverbank). >>>> >>>> T >>>> >>>> >>> >>> >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > ------------------------------------------------------------------------ > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Nebezi jim to nahodou na postgresql? Ale postgresql ma taky moznost > behu v clusteru pokud vim ....

> Je to strasne velike, takze s uploadem cekam az nekdo alespon rekne, ze > ten vyrez je prijatelnej...

> > Jo, mě ten výřez přišel v pořádku. Osobně bych tu generalizaci nedělal (až > > Mrknul jsem na to a vypada to ok. Jak se bude resit kolize se > soucasnymi daty? (dost vodstva uz tam mame, vetsinou asi s mensi > presnosti, takze nejspis by to chtelo po importu ty stary data nejak > selektivne promazat (mozna smazat vicemene vse, ale zase treba tam > nekde budou nejake mistni nazvy vodnich ploch nebo ruzne male pozarni > nadrze co v dibavodu byt nemusi ...)) > > Mozna soucasna data oznacit nejakym tagem "mozna duplicita, po kontrole smazat"

> Procisteni bych nechal na principu 'kdo co vytvoril to taky smaze' > respektive 'kdyz jsem neco vytvoril tak se rozhodnu jestli je lepsi to > moje nebo dibavod, a to horsi smaznu'... U lesu to fungovalo. (a chtit > po jednom cloveku aby krome importu delal procistovani cely republiky > je imo nesmysl).

>> Procisteni bych nechal na principu 'kdo co vytvoril to taky smaze' >> respektive 'kdyz jsem neco vytvoril tak se rozhodnu jestli je lepsi to >> moje nebo dibavod, a to horsi smaznu'... U lesu to fungovalo. (a chtit >> po jednom cloveku aby krome importu delal procistovani cely republiky >> je imo nesmysl). > > Ja osobne si teda nepamatuju kde vsude jsem dokresloval nejake vodstvo > ... bylo to na celkem dost mistech. U lesu to sice funguje celkem > dobre, ale myslim ze i ted jsou stale v mape jeste duplicitni lesy :) > > I kdyz napadlo mne reseni (ktere by mohlo nakonec resit vice veci > najednou) - vezme se cela czechie, z ni se vyfiltruje veskere vodstvo > a na vystup se zkopiruje to, kde se neco protina/prekryva (coz nebude > zas uplne jednoduche, minimalne ne pokud to ma dobehnout v rozumnem > case :). To si pak muzou pootvirat lidi treba v JOSM, jit na misto kde > tenhle skript vyplivl kolizi, stahnout si tam normalni data a nejak to > resit. Podobny soubor by se mohl udelat i pro lesy, eventuelne pro > "chybna data" - typicke preklepy typu highway=residental, neoznacene > ways (casto je nekdo zapomnel otagovat a ways bez tagu jsou jaksi k > nicemu), body a ways obsahujici nejake FIXME, highway=road (ty to chce > upresnit) apod .... > > Martin >

> _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Pokud těch dat není mnoho (cca do 100MB nekomprimovaně, na ty překlepy to > stačit bude určitě), tak stačí použít xapi. > Tedy například: > http://xapi.openstreetmap.org/api/0.5/*[highway=residental][bbox=12.06,48.57,18.97,51.06]

> To jde, pokud podminka je jednoducha, ale pokud chci neoznacene ways, > ktere ale nejsou casti relation, tak na to uz asi xapi ponekud > nestaci. A ani nepredpokladam, ze by to dokazalo najit prekryvajici se > lesy :) > > Cas od casu si takhle z xapi vyzadam typicke preklepy pro cely svet a > hromadne to opravim (residental -> residential, town_hall -> townhall, > atd ...), ale napadlo mne napsat nejakou komplexnejsi kontrolu > (vyhledove s mnoha podminkami a kontrolou i kombinaci tagu)