Možnost využití dat Povodí Labe na Talk-cz

Martin Kokeš shr3k na typo3-hosting.com #mcfc59f 21. 10. 2008 11:48

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

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

Tomas Kolda kolda na web2net.cz #mc582ae 21. 10. 2008 12:53

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

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

Stanislav Brabec utx na penguin.cz #m142f0d 21. 10. 2008 13:27

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

Tomas Kolda kolda na web2net.cz #m0a5037 21. 10. 2008 13:30

Udelam jen xml do JOSMu, Samozrejmne si to vsichni nejdrive prohledneme. Jinak se asi bude importovat waterway, ale riverbank zustanou ty co jsme kreslili.... T

Petr Nejedly Petr.Nejedly na Sun.COM #mc62014 21. 10. 2008 13:47

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

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

-- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

Tomas Kolda kolda na web2net.cz #m837818 21. 10. 2008 18:38

Na data jsem koukal. Je to pomerne velka cast CR zpracovana do nejmensich detailu (ruzne potucky apod.). Zkuste tedy nekdo vyjasnit licenci a pak to muzem naimportovat. Takto to tedy zatim ukladam k ledu... T

Na data jsem koukal. Je to pomerne velka cast CR zpracovana do nejmensich detailu (ruzne potucky apod.). Zkuste tedy nekdo vyjasnit licenci a pak to muzem naimportovat. Takto to tedy zatim ukladam k ledu... T Petr Nejedly napsal(a):

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

Martin Kokeš shr3k na typo3-hosting.com #m6a2b65 21. 10. 2008 18:45

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 MK

Martin Kokeš shr3k na typo3-hosting.com #mbc155d 21. 10. 2008 19:12

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

Tomas Kolda kolda na web2net.cz #m5bb1c0 21. 10. 2008 19:21

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

Martin Kokeš shr3k na typo3-hosting.com #m1a5003 21. 10. 2008 19:46

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

Tady jde pravděpodobně jen o pokřivený výklad nebo neznalost zákona některých úředníků státních institucí. Pokud má nějaká statní instituce veřejně přístupný rejstřík a obsah tohoto rejstříku je dokonce detailně popsán v nějakém zákoně nebo prováděcí vyhlášce, má na něj každý občan právo. Nezáleží na tom, jestli původním zpracovatelem či dodavatelem díla byla soukromá osoba či firma nebo jiná státní organizace. Je úkolem státních úředníků definovat příslušné smlouvy, které se svými dodavateli dat/rešerší/mapových děl uzavírají, tak, aby odpovídaly konsekvencím plynoucím z 365/2000 Sb. o informačních systémech veřejné správy (tzn. taková díla by měla mít neomezené licence - protože je předpoklad, že se takové dílo po zapojení do příslušného informačního systému stane dílem úředním). Pokud to tak nedělají, je to jejich chyba a následky chybně uzavřených smluv si ponesou sami. Takový příklad si můžete prohlédnout třeba na GISu v Autodesk MapGuide, který zmínil pan Staněk z Povodí Labe. Krom dat Povodí Labe, která jsou určena pro IS DIBAVOD tam jsou i data, která si Povodí Labe licencovalo pro vlastní potřebu. Taková data pak samozřejmě většinou nelze použít dál. Konkrétně podle § 22 254/2001 Sb. paragrafy 3 a 4 určují, která data jsou v DIBAVODu "veřejná" a tedy se jedná o úřední dílo. http://www.tzb-info.cz/t.py?t=15&i=342 Prováděcí vyhláška 391/2004 Sb. pak obsah tohoto IS dále vymezuje http://www.tzb-info.cz/t.py?t=15&i=359 MK

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. Pokud nekdo najdete indicii, ze to nelze pouzit, reknete...

Tady jde pravděpodobně jen o pokřivený výklad nebo neznalost zákona některých úředníků státních institucí. Pokud má nějaká statní instituce veřejně přístupný rejstřík a obsah tohoto rejstříku je dokonce detailně popsán v nějakém zákoně nebo prováděcí vyhlášce, má na něj každý občan právo. Nezáleží na tom, jestli původním zpracovatelem či dodavatelem díla byla soukromá osoba či firma nebo jiná státní organizace. Je úkolem státních úředníků definovat příslušné smlouvy, které se svými dodavateli dat/rešerší/mapových děl uzavírají, tak, aby odpovídaly konsekvencím plynoucím z 365/2000 Sb. o informačních systémech veřejné správy (tzn. taková díla by měla mít neomezené licence - protože je předpoklad, že se takové dílo po zapojení do příslušného informačního systému stane dílem úředním). Pokud to tak nedělají, je to jejich chyba a následky chybně uzavřených smluv si ponesou sami. Takový příklad si můžete prohlédnout třeba na GISu v Autodesk MapGuide, který zmínil pan Staněk z Povodí Labe. Krom dat Povodí Labe, která jsou určena pro IS DIBAVOD tam jsou i data, která si Povodí Labe licencovalo pro vlastní potřebu. Taková data pak samozřejmě většinou nelze použít dál. Konkrétně podle § 22 254/2001 Sb. paragrafy 3 a 4 určují, která data jsou v DIBAVODu "veřejná" a tedy se jedná o úřední dílo. http://www.tzb-info.cz/t.py?t=15&i=342 Prováděcí vyhláška 391/2004 Sb. pak obsah tohoto IS dále vymezuje http://www.tzb-info.cz/t.py?t=15&i=359 MK

Jiri Klement jiri.klement na gmail.com #m538b73 21. 10. 2008 21:00

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.

Martin Kokeš shr3k na typo3-hosting.com #mf3b442 21. 10. 2008 21:23

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

Stanislav Brabec utx na penguin.cz #m3a0adc 21. 10. 2008 21:31

Jiri Klement píše v Út 21. 10. 2008 v 21:00 +0200:

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.

?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. ? Tomas Kolda píše v Út 21. 10. 2008 v 19:21 +0200:

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

Navrhuji Veselskou rybniční soustavu. Je tam mnoho rybníků, a právě jsem začal s mapováním napájecích stok. V případě, že ?Dibavod budou lepší, nebudu s tím pokračovat. http://www.openstreetmap.org/?lat=49.1105&lon=14.7456&zoom=13&layers=B000FFF (Případně vše mezi Veselím a Třeboní s meandry Nežárky a Lužnice.) 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. Některé konkurenční mapy, s kterými jsem svůj zákres porovnával, často vypadají jako zákresy z ortofotografií. Stanislav Brabec http://www.penguin.cz/~utx

BH singularita na gmail.com #mdd038e 21. 10. 2008 21:59

Pokud ty data nebudou nejak obzvlaste enormne velka (= pocet bodu o dost vetsi nez treba kolik maji lesy) tak bych to nechal - pokud se zkomprimnovane OSM XML s novymi daty vejde pod 10 MB, neresil bych to vubec, mozna pokud by zkomprimovane XML se vsemi toky melo nad 50 MB tak bych zacal uvazovat jestli to nezjednodusit a jak ...

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.

V katastralni mape od cuzk i dost maly potucky (tak nejak na hranici preskocitelnosti) mely jmeno, staci jen dostatecne dlouho rolovat na usek, kde je napsane ...

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 katastralnich mapach od CUZK jsou nekdy hranice rybniku videt lepe nez z ortofota ... problem taky bude v tom, ze hladina u nekterych dost kolisa a na ortofotu muzou byt zaneseny vypusteny (napr. Podhradni rybnik u Male Vozice na UHULu nebyl videt protoze byl byl v dobe foceni vypusteny a musel jsem ho obkreslovat z CUZK) Martin

Petr Nejedly Petr.Nejedly na Sun.COM #m0e6f80 22. 10. 2008 14:33

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

Martin Kokeš shr3k na typo3-hosting.com #mface53 22. 10. 2008 16:44

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

Petr Nejedly Petr.Nejedly na Sun.COM #mf5bc0c 22. 10. 2008 16:51

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š shr3k na typo3-hosting.com #ma08e81 22. 10. 2008 17:05

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

hanoj ehanoj na gmail.com #m2f1ccb 22. 10. 2008 20:02

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ě. haj hou hanoj

Martin Kokeš shr3k na typo3-hosting.com #m6fbfdb 22. 10. 2008 20:48

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?

Tak to chce příště i druhý pohled, ne jen ten první. §2 t) veřejným informačním systémem informační systém vedený správci uvedenými v § 3 odst. 2 nebo jiný informační systém poskytující služby veřejnosti, který má vazby na informační systémy veřejné správy; § 3 (2) Správci informačních systémů veřejné správy jsou ministerstva, jiné správní úřady a územní samosprávné celky (dále jen ?orgány veřejné správy?). § 5 Orgány veřejné správy (2) Orgány veřejné správy jsou v rámci informačních systémů veřejné správy povinny f) postupovat při uveřejňování informací způsobem umožňujícím dálkový přístup tak, aby byly informace související s výkonem veřejné správy uveřejňovány ve formě, která umožňuje, aby se s těmito informacemi v nezbytném rozsahu mohly seznámit i osoby se zdravotním postižením. Formu uveřejnění informací stanoví prováděcí právní předpis; § 9 (1) Z informačních systémů veřejné správy nebo jejich částí, které jsou veřejnými evidencemi, rejstříky nebo seznamy, vydávají orgány veřejné správy, které jsou správci nebo provozovateli těchto systémů (dále jen ?správci?), na požádání úplný nebo částečný výpis ze zápisu vedeného v elektronické podobě v tomto informačním systému. (2) Výpis podle odstavce 1 (dále jen ?výpis?) v listinné podobě je veřejnou listinou.

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

Tak to snad jen opravdu IYHO. § 3 Výjimky z ochrany podle práva autorského ve veřejném zájmu Ochrana podle práva autorského se nevztahuje na a) úřední dílo, jímž je právní předpis, rozhodnutí, opatření obecné povahy, veřejná listina, veřejně přístupný rejstřík a sbírka jeho listin, jakož i úřední návrh úředního díla a jiná přípravná úřední dokumentace, včetně úředního překladu takového díla, sněmovní a senátní publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem na vyloučení z ochrany, Takže si to shrneme, u každého informačního systému veřejné zprávy (krom systémů citovaných v § 3 365/2000 Sb.) je jejich správce (orgán veřejné správy) povinen postupovat při uveřejňování informací způsobem umožňujícím dálkový přístup tak, aby byly informace související s výkonem veřejné správy uveřejňovány ve formě, která umožňuje, aby se s těmito informacemi v nezbytném rozsahu mohly seznámit i osoby se zdravotním postižením. I kdyby zmíněná databáze nebyla "veřejně přístupným rejstříkem" (což evidentně je, jak podle 365/2000 Sb. §2 písm. t , tak i podle 254/2001 Sb. §22 odst. 3), stále je její úplný výtisk veřejnou listinou. Správce je povinen na požádání vydat úplný nebo částečný výpis ze zápisu vedeného v elektronické podobě v tomto informačním systému, který pak má status veřejné listiny a na tu se nevztahuje ochrana podle práva autorského. MK

hanoj napsal(a):

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?

Tak to chce příště i druhý pohled, ne jen ten první. §2 t) veřejným informačním systémem informační systém vedený správci uvedenými v § 3 odst. 2 nebo jiný informační systém poskytující služby veřejnosti, který má vazby na informační systémy veřejné správy; § 3 (2) Správci informačních systémů veřejné správy jsou ministerstva, jiné správní úřady a územní samosprávné celky (dále jen ?orgány veřejné správy?). § 5 Orgány veřejné správy (2) Orgány veřejné správy jsou v rámci informačních systémů veřejné správy povinny f) postupovat při uveřejňování informací způsobem umožňujícím dálkový přístup tak, aby byly informace související s výkonem veřejné správy uveřejňovány ve formě, která umožňuje, aby se s těmito informacemi v nezbytném rozsahu mohly seznámit i osoby se zdravotním postižením. Formu uveřejnění informací stanoví prováděcí právní předpis; § 9 (1) Z informačních systémů veřejné správy nebo jejich částí, které jsou veřejnými evidencemi, rejstříky nebo seznamy, vydávají orgány veřejné správy, které jsou správci nebo provozovateli těchto systémů (dále jen ?správci?), na požádání úplný nebo částečný výpis ze zápisu vedeného v elektronické podobě v tomto informačním systému. (2) Výpis podle odstavce 1 (dále jen ?výpis?) v listinné podobě je veřejnou listinou.

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

Tak to snad jen opravdu IYHO. § 3 Výjimky z ochrany podle práva autorského ve veřejném zájmu Ochrana podle práva autorského se nevztahuje na a) úřední dílo, jímž je právní předpis, rozhodnutí, opatření obecné povahy, veřejná listina, veřejně přístupný rejstřík a sbírka jeho listin, jakož i úřední návrh úředního díla a jiná přípravná úřední dokumentace, včetně úředního překladu takového díla, sněmovní a senátní publikace, pamětní knihy obecní (obecní kroniky), státní symbol a symbol jednotky územní samosprávy a jiná taková díla, u nichž je veřejný zájem na vyloučení z ochrany, Takže si to shrneme, u každého informačního systému veřejné zprávy (krom systémů citovaných v § 3 365/2000 Sb.) je jejich správce (orgán veřejné správy) povinen postupovat při uveřejňování informací způsobem umožňujícím dálkový přístup tak, aby byly informace související s výkonem veřejné správy uveřejňovány ve formě, která umožňuje, aby se s těmito informacemi v nezbytném rozsahu mohly seznámit i osoby se zdravotním postižením. I kdyby zmíněná databáze nebyla "veřejně přístupným rejstříkem" (což evidentně je, jak podle 365/2000 Sb. §2 písm. t , tak i podle 254/2001 Sb. §22 odst. 3), stále je její úplný výtisk veřejnou listinou. Správce je povinen na požádání vydat úplný nebo částečný výpis ze zápisu vedeného v elektronické podobě v tomto informačním systému, který pak má status veřejné listiny a na tu se nevztahuje ochrana podle práva autorského. MK

Tomas Kolda kolda na web2net.cz #mfb3b97 23. 10. 2008 10:32

Uz mam pripravenou sqlite databazi s naimportovanyma datama. Napr jen pro linie ma pres 200 MB. Nepouzivam spatial extenze, protoze je zatim python primo nepodporuje a nechci abyste si museli neco doinstalovavat az to budeme ladit. Tu generalizaci bych tam fakt asi dal, protoze jinak bude pomer bodu vod oproti cele czechii nezanedbatelny. Staci presnost 2 metry a myslim, ze spadneme na mene nez polovinu (uvidim). Ale je to o diskuzi. Ja napr. nepotrebuji polohu potucku s presnosti na centimetry. Uvidime jak se domluvime.... Mozna dnes, ale spis zitra bych poslal vyrez nejakeho uzemi se skriptem generujicim OSM. 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. Brehy se prevedou na riverbank a nadrze asi na natural/water. T

Karel Volný kavol na seznam.cz #m63f4f3 23. 10. 2008 10:49

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.

Tomas Kolda kolda na web2net.cz #m223794 23. 10. 2008 11:00

Ja mam take rad presna data. Ale bude se neumerne nafukovat databaze a to vcetne ruznych prevodu do Garmina apod. Z meho hlediska je to jedno, ja si data stejne pri prevodu do sve aplikace generalizuji, ale nevim jak je to s prevodniky do jinych zarizeni. Uvidime jak bude veliky vysledny XML a podle toho rozhodneme... Musi se na to proste s rozumem. Kdyz nekdo mapuje silnici, tak take dava opticky rozumne aproximace. Je to trochu o citu. Ale dle velikosti dat tech linii se mi zda, ze to trochu prehnali (velky pocet mezibodu). Po generalizaci napr. na metr opticky rozdil nikdo neuvidi a na 2 jen pri velkem priblizeni a malem polomeru oblouku. V tomto pripade se tedy skutecne neda mluvit o jakychsi pseudokartogramech... To bych stejne tak mohl zmapovat D1 pomoci vykresovych planu kde bude oblouk vypocitan s milimetrovou presnosti a tim nafouknout databazi o nekolik GB. To ale nema vubec zadny vyznam. Proto si myslim, ze u rek a potoku, kde se tezko da rict kde je vlastne stred, je dvoumetrova presnost az az. T

Stanislav Brabec utx na penguin.cz #m549bba 23. 10. 2008 11:30

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.

Tomas Kolda kolda na web2net.cz #m224efa 23. 10. 2008 11:39

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

Tomas Kolda kolda na web2net.cz #m1b9920 24. 10. 2008 0:33

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 kolda na web2net.cz #m073776 24. 10. 2008 0:46

Jo a jeste ten ciselnik nazvu s primitivni detekci rek a potoku. Muzete navrhovat jak to udelame ve vychozim importu... (sada cp1250) http://www.web2net.cz/osm/dibavod_nazvy.zip T

Jo a jeste ten ciselnik nazvu s primitivni detekci rek a potoku. Muzete navrhovat jak to udelame ve vychozim importu... (sada cp1250) http://www.web2net.cz/osm/dibavod_nazvy.zip T 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 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

Petr Dlouhý petr.dlouhy na email.cz #mbd335a 24. 10. 2008 1:41

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)

Martin Kokeš shr3k na typo3-hosting.com #m370c36 24. 10. 2008 1:48

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

Mám na to stejný názor. Pokud to má být mapa univerzální (s tím, že z ní bude možno exportovat různě podrobné mapy pro různé účely), bylo by podle tohoto návrhu optimální zachovat data tak jak jsou a případně je zpřesňovat už jen ručně podle GPS, či případně v budoucnu pomocí přesnějšího ortofota. Stačí se podívat, co všechno člověk najde v Garminu a mapě TOPO 2 Czech PRO. Pokud bude OSM stejně tak dobrá ne-li lepší (díky znalostem lokálních přispěvatelů), bude to jen dobře. MK

Tomas Kolda kolda na web2net.cz #m468352 24. 10. 2008 7:14

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

Petr Dlouhý petr.dlouhy na email.cz #mf5301e 24. 10. 2008 7:22

On Fri, 24 Oct 2008 01:41:31 +0200, Petr Dlouhý <petr.dlouhy na email.cz> Tak posílám všechny xslt, která používám k porovnávání silnic v OSM s databází RSD. Sjednocení wayí se stejným ref (změňte to na něco, co jednoznačně identifikuje tu řeku) je v souboru "unifySameRef.xsl".

osmrsd_porov.tar.bz2

Petr Dlouhý petr.dlouhy na email.cz #m659290 24. 10. 2008 7:52

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.

Tomas Kolda kolda na web2net.cz #m27973f 24. 10. 2008 8:02

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

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

Petr Dlouhý petr.dlouhy na email.cz #m88adbd 24. 10. 2008 8:23

A které routování s tím nefunguje? Zkoušel jsem yournavigation.org (který vychází z gosmore), a nevadí mu to. Tuhle cestu <http://www.yournavigation.org/?flat=50.099556&flon=14.380929&tlat=50.102068&tlon=14.374784&v=motorcar&fast=1&layer=mapnik> to našlo přestože ty silnice nejsou ani na jedné křižovatce přerušené.

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.

Řekl bych, že pro název nebo ref se relace nehodí, tam by šlo spíš použít hledání, ale asi ne každý o tom ví (a nevím, jak je to v Potlachu). Například u cyklostezek, naopak považuji osobně relaci za jedinou správnou, protože kromě jednoduchého opravování tagu na umožňuje (v novém JOSMu) nechat si stáhnout všechny objekty, které v ní jsou.

On Fri, 24 Oct 2008 08:02:20 +0200, Tomas Kolda <kolda na web2net.cz> wrote: A které routování s tím nefunguje? Zkoušel jsem yournavigation.org (který vychází z gosmore), a nevadí mu to. Tuhle cestu <http://www.yournavigation.org/?flat=50.099556&flon=14.380929&tlat=50.102068&tlon=14.374784&v=motorcar&fast=1&layer=mapnik> to našlo přestože ty silnice nejsou ani na jedné křižovatce přerušené.

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.

Řekl bych, že pro název nebo ref se relace nehodí, tam by šlo spíš použít hledání, ale asi ne každý o tom ví (a nevím, jak je to v Potlachu). Například u cyklostezek, naopak považuji osobně relaci za jedinou správnou, protože kromě jednoduchého opravování tagu na umožňuje (v novém JOSMu) nechat si stáhnout všechny objekty, které v ní jsou.

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

-- Petr Dlouhý

Petr Nejedly Petr.Nejedly na Sun.COM #m73edf0 24. 10. 2008 9:37

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.

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?

Petr Nejedly Petr.Nejedly na Sun.COM #m121658 24. 10. 2008 9:42

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

Tomas Kolda kolda na web2net.cz #md6f121 24. 10. 2008 9:48

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

Tomas Kolda kolda na web2net.cz #mf427d1 24. 10. 2008 9:51

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

Ondrej Novy onovy na nomi.cz #m08b904 24. 10. 2008 10:04

Ahoj,

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

Petr Nejedly Petr.Nejedly na Sun.COM #mebce86 24. 10. 2008 10:07

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

Na porovnani by stacil ten kousek, co jsem psal, cili: [50.152,16.813,50.154,16.817]

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

Pravda, Kocába sedi na katastrální mapu fakt "na milimetr".

Tomas Kolda kolda na web2net.cz #md0b7e1 24. 10. 2008 10:08

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

Petr Nejedly Petr.Nejedly na Sun.COM #m6ff66e 24. 10. 2008 10:12

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

Ano, ale to uz je zajiste exportni format jejich databaze, ne?

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

Druhou variantu volit nemuzes ani kdyby jsi byl na zacatku projektu, protoze to nedokazes udrzet a lidi by zbytecne delali chyby (a chyby na prvni pohled neviditelne). Jediny zpusob, jak jim v tom zabranit, by bylo zcela zakazat sdileni bodu uprostred way. To by vsak bylo velmi restriktivni a znemoznovalo nektera jina soucasna vyuziti (napr. sdileni hranice mezi ruznymi landuse).

Tomas Kolda napsal(a):

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

Ano, ale to uz je zajiste exportni format jejich databaze, ne?

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

Druhou variantu volit nemuzes ani kdyby jsi byl na zacatku projektu, protoze to nedokazes udrzet a lidi by zbytecne delali chyby (a chyby na prvni pohled neviditelne). Jediny zpusob, jak jim v tom zabranit, by bylo zcela zakazat sdileni bodu uprostred way. To by vsak bylo velmi restriktivni a znemoznovalo nektera jina soucasna vyuziti (napr. sdileni hranice mezi ruznymi landuse).

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

-- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

Petr Dlouhý petr.dlouhy na email.cz #mfce7e5 24. 10. 2008 10:13

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.

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

Petr Dlouhý petr.dlouhy na email.cz

Ondrej Novy onovy na nomi.cz #m148892 24. 10. 2008 10:36

Ahoj,

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.

souhlasim, delsi way by zpusobal obtize pri editaci v JOSM (moc dlouhy reky to proste blbe (cti: pomale) kresli. Pak taky by to pri editaci jedinyho node strasne dlouho odesilalo way (moc velkej XML strom). 30 km je imho prijatelnych.

Martin Vidner martin.osm na vidner.net #mc48162 24. 10. 2008 11:27

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

Tomas Kolda kolda na web2net.cz #m735de5 24. 10. 2008 11:29

Tyto data jsou dabavod, coz neni povodi Labe. Melo by se to nejak ridit asi tim zakonem, jak bylo zminovano v tomto threadu. T

Pavel Machek pavel na suse.cz #mfda466 24. 10. 2008 11:55

Ahoj!

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.

Tohle teda nechapu... kterymu routovadlu to vadi? A nemelo by se spis opravit to routovadlo? U navitu jsem problemy se spojovanim nepozoroval...

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

Proc bych mel rozbijet cestu na spoustu malych? IMO to bude dokonce spatny pro routing, protoze potom si bude myslet ze se mu zmenila silnice kdyz jedu rovne... Pavel

BH singularita na gmail.com #m5211a2 24. 10. 2008 14:41

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.

Pak je to nedostatecne routovani. Nebudeme prece sekat hlavni tridu na malinkate kousky kvuli kazde odbocce. Pro nektere aplikace (napr. mapnik) je zase naopak lepsi mit silnice v rozumne mire "co nejvice spojene", protoze ty na kazdy usek cpou extra jmeno. Nekteri lidi to rozsekavaji, nekteri to zase spojiji (osobne spojuji useky silnic druhe tridy tak, aby byly rozseknuty jen krizovatkami s druhou tridou, jinak by bylo fura mrnavych useku) IMHO nedostatecny algoritmus u navigace a ne neco co by se melo opravovat v OSM. V nejhorsim se to da rozsekat takhle automaticky a predradit jako predzpracovani pri generovani pro takovehle "chybne" navigace a rozhodne bych to nedelal rucne v OSM.

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

BH singularita na gmail.com #ma3b6aa 24. 10. 2008 14:48

2008/10/24 Petr Dlouhý <petr.dlouhy na email.cz>:

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.

Kolik bude tech 30 km zhruba bodu? Drzel bych se maxima tak kolem 500-1500 bodu na usek (at to je km kolik chce :), kdyz je toho vic a clovek chce opravit kratky usek reky, tak jednak to dlouho stahuje a po oprave uploaduje, jednak je vyssi riziko konfliktu kdyz dva lidi opravujou tu samou reku na jinych mistech. Martin

Stanislav Brabec utx na penguin.cz #m7ea03c 24. 10. 2008 15:01

BH píše v Pá 24. 10. 2008 v 14:41 +0200:

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.

Je to proposed feature. Ještě jsem nezkoušel, zda to mapnik a osmarender umí. http://wiki.openstreetmap.org/index.php/Relations/Proposed/Collected_Ways nebo obrácený přístup http://wiki.openstreetmap.org/index.php/Relations/Proposed/Segmented_Tag a zčásti podobný http://wiki.openstreetmap.org/index.php/Relations/Proposed/Composite_Tag

Tomas Kolda kolda na web2net.cz #m5bb0bb 26. 10. 2008 18:51

Ahoj, takze jsem skoro dokoncil import. Co je hotove: - Importovany linie jednotlivych toku 5.212.525 bodu 250.612 linii - Importovany nadrze 1.486.406 bodu 72.026 ploch 822 multipolygonu z toho 1.522 der (ostrovu) - Importovany nazvy vcetne identifikatoru pro pripadny merge v budoucnu - Sjednoceny sdilene nody (stejna lokace), ktere neni mozne simplifikovat 187.921 bodu - Export relaci pro polygony. Smer polygonu urcuje outer/inner. - Simplifikace dle zadane hodnoty Neni hotove: - Import brehu pro riverbank - Sjednocovani linii se stejnymi atributy (nazev). Zde nevim zda to udelat, protoze tim ztratime identifikator z dibavodu a tudiz nebude mozny merge v budoucnu. Linie jsou rozsekany vzdy jen na vetveni rek, potoku apod. Statistika simplifikace: - Pri simplifikaci s presnosti 2 metry se vysledny OSM zmensi na 57%. - Pri simplifikaci s presnosti 1 metr se vysledny OSM zmensi na 73% Vystup pri simplifikaci 2 metry ma neco pres 300MB xml. Plna presnost je tedy kolem 500MB. To mi prijde (ano opet zduraznuji) zbytecne. Podivejte se tedy na ty vystupy a dejte mi za pravdu. staci menit promenou error nekde dole ve skriptu. 2 / 10.... je ve stupnich, ale priblizne je to v metrech. Jako vzdy prikladam vyrezanou databazi, a exportovaci skripty. Komplet zatim neposilam, protoze ma zabalena pres 100MB a to bych posilal hodne dlouho. Tak se bavte a hlaste chyby. http://www.web2net.cz/osm/vody_081026.7z Jeste me napadlo oficialne kontaktovat urad s dotazem o tom zakonu. Oni musi oficialne odpovedet a pak bysme 100% vedeli jak to tedy je. Mohl by se toho nekdo ujmout? T

Martin Kokeš shr3k na typo3-hosting.com #m7a8217 27. 10. 2008 19:09

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

Tomas Kolda kolda na web2net.cz #mea043e 27. 10. 2008 19:17

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. No generuju celou CR a pak to nejak uploadnu. Trva to dost dlouho, takze spis az zitra. T

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. No generuju celou CR a pak to nejak uploadnu. Trva to dost dlouho, takze spis az zitra. T Martin Kokeš napsal(a):

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

BH singularita na gmail.com #m5a3af6 27. 10. 2008 20:29

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.

Z katastralnich map (cuzk:km) je presnost nekdy i vyssi, odhadem tak 0.5 m az 1 m.

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%

Lesy z UHULu nafoukli czechii cca na trojnasobek i po generalizaci (IMHO ta generalizace byla mozna az moc generalizovana, misty je to celkem i videt) Ve chvili, kdy i kazda vesnice bude stejne dobra zmapovana jako nektere casti vetsich mest (vsechny ulice vcetne budov) jako treba Praha nebo Tabor, tak se nejakych 6 milionu bodu ztrati :) To sice bude za dlouho, ale na druhou stranu se do mapy tim lepe dokresluje, cim vic veci tam uz je. Kdyz chci do mapy dokreslit "hospodu na rohu 2. baraku v ulici" a ty domky tam jsou uz nakreslene, tak tam proste jen vrznu amenity=restaurant +name = ... a nemusim ten domek lovit treba v uhulu nebo cuzk :) Mensi potoky (tak do 2 metru sirky) jsou z UHULU videt nekdy blbe (pokud jsou zarostle stromy) a nekdy nejsou ani v CUZK, ale da se podle nich dobre dokreslovat (sel jsem po ceste podel potoka), hlavne veci pouzitelne v turisticke mape (lesni cesticky, polnacky, atd ...) Tyhle detaily mozna nebudou videt v "bezne" mape (turisticka, plany mest), ale pomuzou dost ostatnim pri mapovani (ja osobne mapuju v JOSM na urovni ulic v "meritku" odpovidajim tak 1:500 - 1:1000, takze kdyz je neco o metr nebo dva vedle, tak si toho nekdy i vsimnu :),

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

Dal bych tam metrova data. Martin

Petr Dlouhý petr.dlouhy na email.cz #m602534 27. 10. 2008 20:49

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.

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. -- Petr Dlouhý

Martin Kokeš shr3k na typo3-hosting.com #m5bd178 27. 10. 2008 21:29

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

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

Tomas Kolda kolda na web2net.cz #m9e6fda 27. 10. 2008 21:36

Dobre nechal jsem se ukecat. Uploaduji tedy s plnou presnosti a pri updatech se bude lepe detekovat zmeneny (posunuty) nod. Ze stejneho duvodu tedy nebudeme spojovat at mame zachovany dibavod idcka. Soubory budou postupne pribyvat na http://www.web2net.cz/osm/vody/ Mam pomale pripojeni, ale snad do rana to bude cele. Vse je komprimovano pomoci 7z, protoze to vychazi asi na 60% oproti bz2.... lines_[001 - 047].7z - zapakovane xml po 10MB linie. Linie jsou rozvrstveny nahodne po CR bohuzel. Vychazi to z indexu, takze s tim bohuzel nic neudelam. Bylo by nebezpeci udelat chybu pri exportu. Vysledne soubory si asi musite spojit pomoci osmosis a udelat vyrez.... areas_[001 - 013].7z - To same ale pro nadrze. areasWithRelation.7z - Vsechny nadrze, ktere obsahuji relaci. Celkem tedy 585MB v XML. Je to tedy pripravene pro import podobne jako u lesu. Zatim prosim neimportovat, dokud nebudeme vsichni souhlasit. 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

Dobre nechal jsem se ukecat. Uploaduji tedy s plnou presnosti a pri updatech se bude lepe detekovat zmeneny (posunuty) nod. Ze stejneho duvodu tedy nebudeme spojovat at mame zachovany dibavod idcka. Soubory budou postupne pribyvat na http://www.web2net.cz/osm/vody/ Mam pomale pripojeni, ale snad do rana to bude cele. Vse je komprimovano pomoci 7z, protoze to vychazi asi na 60% oproti bz2.... lines_[001 - 047].7z - zapakovane xml po 10MB linie. Linie jsou rozvrstveny nahodne po CR bohuzel. Vychazi to z indexu, takze s tim bohuzel nic neudelam. Bylo by nebezpeci udelat chybu pri exportu. Vysledne soubory si asi musite spojit pomoci osmosis a udelat vyrez.... areas_[001 - 013].7z - To same ale pro nadrze. areasWithRelation.7z - Vsechny nadrze, ktere obsahuji relaci. Celkem tedy 585MB v XML. Je to tedy pripravene pro import podobne jako u lesu. Zatim prosim neimportovat, dokud nebudeme vsichni souhlasit. 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 Petr Dlouhý napsal(a):

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.

Petr Dlouhý petr.dlouhy na email.cz #m1ee08d 27. 10. 2008 21:58

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?

Tomas Kolda kolda na web2net.cz #mb3708e 27. 10. 2008 22:02

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

Tomas Kolda kolda na web2net.cz #m4d8872 27. 10. 2008 22:07

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

BH singularita na gmail.com #mc8d950 27. 10. 2008 22:29

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

Vzhledem k tomu, ze ty data mohli mezitim dalsi lidi zpresnovat, nebo na ne navazovat (napr. nakreslit les nebo silnici podel brehu) tak vymena za presnejsi je pomerne slozita.

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

To lze delat automaticky, vysledky jsou vetsinou vcelku prijatelne.

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

bz2 dump cele planety ma momentalne asi 4.5 gb ... rozbalena czechia ma necelych 600mb, rozbalene vody taky, takze zabalene vody muzou mit radove 50mb .... to si myslim ze OSM snese bez problemu :) Neco jeste usetrime tim, ze soucasne vozdstvo drive nebo pozdeji zase umazem, aby to tam nebylo dvakrat.

-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

Jako OB mapa to asi nepujde nikdy, nepredpokladam ze by nekdo mapoval CR na urovni kazdeho patniku, hustniku, pruseku, pesinky a vetsiho sutru.... Ale slo by to pouzit misto zakladove mapy ... ze ktere se obvykle v novem prostoru zacina.

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.

Podrobnejsi plany mest jsou obvykle v meritcich 1:10000 az 1:20000 ... cili srovnatelne s mene podrobnymi mapami na OB ... 1:10000 je "dolni rozliseni" udavane dibavodem a v nekterych mestech, kde je v centru mnoho malych ulicek a mnoho POIs jako hospody apod. (pravda, by je musel nekdo namapovat, ale nekde uz jsou :) by se klidne uzivilo i 1:5000

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ž

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

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.

Wikipedie narust popularity a velky napor zvladla a ted maj tusim desitky nebo stovky serveru .... myslim si, ze kdyz bude potreba, tak se pro OSM penize taky sezenou :) Martin

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

Vzhledem k tomu, ze ty data mohli mezitim dalsi lidi zpresnovat, nebo na ne navazovat (napr. nakreslit les nebo silnici podel brehu) tak vymena za presnejsi je pomerne slozita.

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

To lze delat automaticky, vysledky jsou vetsinou vcelku prijatelne.

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

bz2 dump cele planety ma momentalne asi 4.5 gb ... rozbalena czechia ma necelych 600mb, rozbalene vody taky, takze zabalene vody muzou mit radove 50mb .... to si myslim ze OSM snese bez problemu :) Neco jeste usetrime tim, ze soucasne vozdstvo drive nebo pozdeji zase umazem, aby to tam nebylo dvakrat.

-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

Jako OB mapa to asi nepujde nikdy, nepredpokladam ze by nekdo mapoval CR na urovni kazdeho patniku, hustniku, pruseku, pesinky a vetsiho sutru.... Ale slo by to pouzit misto zakladove mapy ... ze ktere se obvykle v novem prostoru zacina.

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.

Podrobnejsi plany mest jsou obvykle v meritcich 1:10000 az 1:20000 ... cili srovnatelne s mene podrobnymi mapami na OB ... 1:10000 je "dolni rozliseni" udavane dibavodem a v nekterych mestech, kde je v centru mnoho malych ulicek a mnoho POIs jako hospody apod. (pravda, by je musel nekdo namapovat, ale nekde uz jsou :) by se klidne uzivilo i 1:5000

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ž

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

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.

Wikipedie narust popularity a velky napor zvladla a ted maj tusim desitky nebo stovky serveru .... myslim si, ze kdyz bude potreba, tak se pro OSM penize taky sezenou :) Martin

Martin Kokeš shr3k na typo3-hosting.com #m46fd6f 27. 10. 2008 22:34

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

Požádal jsem o vyjádření p. Kužílka, odborníka na právo a svobodný přístup k informacím: http://www.otevrete.cz/forum/viewtopic.php?p=3447#3447 MK <http://www.otevrete.cz/forum/viewforum.php?f=3>

Tomas Kolda kolda na web2net.cz #mf81797 27. 10. 2008 23:56

Tak dnes uz naposled. Uploaduji databazi do http://www.web2net.cz/osm/vody/ cela bude asi za 10 minut. Je tam i generujici skript. Staci rozbalit databazi a pri prvnim spusteni se vytvori indexy, aby byl soubor na webu mensi.... Na zacatku skriptu je bounding rect, ktery se generuje... Pro celou CR staci odkomentovat whereSql = "" Pri finalnim posilani se nejdrive musi poslat nody, ktere jsou sdilene (krizovatky). Ty napr. poslu ja. Zbytek uz se na ne bude odkazovat. Jinak by JOSM vytvarel sdileny nod znovu a byl by tam vicekrat nebo by mu pri posilani way naopak chybela reference z jineho dilu xml. V rozsekanych souborech je totiz sdileny nod vicekrat referencovany, ale muze byt uvedeny jen v jednom. Mam to uz vymyslene a tezko se to popisuje, proste jsem tim chtel rict, zatim to neuploadujte :) T

Tak dnes uz naposled. Uploaduji databazi do http://www.web2net.cz/osm/vody/ cela bude asi za 10 minut. Je tam i generujici skript. Staci rozbalit databazi a pri prvnim spusteni se vytvori indexy, aby byl soubor na webu mensi.... Na zacatku skriptu je bounding rect, ktery se generuje... Pro celou CR staci odkomentovat whereSql = "" Pri finalnim posilani se nejdrive musi poslat nody, ktere jsou sdilene (krizovatky). Ty napr. poslu ja. Zbytek uz se na ne bude odkazovat. Jinak by JOSM vytvarel sdileny nod znovu a byl by tam vicekrat nebo by mu pri posilani way naopak chybela reference z jineho dilu xml. V rozsekanych souborech je totiz sdileny nod vicekrat referencovany, ale muze byt uvedeny jen v jednom. Mam to uz vymyslene a tezko se to popisuje, proste jsem tim chtel rict, zatim to neuploadujte :) T Tomas Kolda napsal(a):

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

Ondrej Novy onovy na nomi.cz #m6fde57 28. 10. 2008 12:00

Ahoj,

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

s replikaci DB je obecne sileny problem. Replikace master-master (kterou momentalne OSM API 0.5 vyzaduje) neni PLNE funkcni ani pro MySQL, ani pro PostgreSQL. Verze 0.6 API pocita s transakcema, kde je mozne mit master-slave replikaci nad MySQL (pres shipping transakcnich logu). Pak nevadi ze slave ma o trosicku (radove sekundy) starsi data. Resil sem to s adminama, nejaky servery uz jsou snad i objednany, takze se svita snad na lepsi casy. Jinak OSM bezi nad MySQL.