« zpět na výpis měsíce |

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

Vlákno 21.10. - 1.11.2008, počet zpráv: 74


21.10.2008 11:48:42 (#1)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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

21.10.2008 12:53:46 (#2)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Klidne se toho ujmu, jaky source tomu chcete priradit? T Martin Kokeš napsal(a): zobrazit citaci
> 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 >

21.10.2008 01:27:51 (#3)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
Tomas Kolda píše v Út 21. 10. 2008 v 12:53 +0200: zobrazit citaci
> 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í. -- Stanislav Brabec http://www.penguin.cz/~utx

21.10.2008 01:30:24 (#4)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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 Stanislav Brabec napsal(a): zobrazit citaci
> 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í. > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081021/ab0a4018/attachment.html>

21.10.2008 01:47:26 (#5)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> 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 zobrazit citaci
> > 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!

21.10.2008 06:38:30 (#6)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >> > > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081021/3fa039f2/attachment.html>

21.10.2008 06:45:28 (#7)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Petr Nejedly napsal(a): zobrazit citaci
> Tomas Kolda napsal(a): > >> Klidne se toho ujmu, jaky source tomu chcete priradit? >> > > Že by "source=pla:dibavod"? > Nicméně: V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na vytištěném > listu takto: "(c) Zpracováno s použitím dat Povodí Labe, státní podnik" > > Toto je podmínka, kterou těžko v OSM splníme. To by chtělo vyjasnit. > > Zdroj: http://www.pla.cz/planet/ram.aspx?id=21 >
Další otázkou je zda nezkusit využít přímo DIBAVOD celý. http://www.vuv.cz/oddeleni-gis/17/o-projektu-dibavod.html MK

21.10.2008 07:12:25 (#8)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Martin Kokeš napsal(a): zobrazit citaci
> 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

21.10.2008 07:21:51 (#9)
gravatar

Tomas Kolda

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

21.10.2008 07:46:59 (#10)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Tomas Kolda napsal(a): zobrazit citaci
> 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

21.10.2008 09:00:52 (#11)
gravatar

Jiri Klement

<jiri.klement at gmail.com>
140
zobrazit citaci
> 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. -- Jirka

21.10.2008 09:23:41 (#12)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Jiri Klement napsal(a): zobrazit citaci
>> 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

21.10.2008 09:31:37 (#13)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
Jiri Klement píše v Út 21. 10. 2008 v 21:00 +0200: zobrazit citaci
> > 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: zobrazit citaci
> 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

21.10.2008 09:59:21 (#14)
gravatar

BH

<singularita at gmail.com>
306
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 ... zobrazit citaci
>> 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 ... zobrazit citaci
> 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

22.10.2008 02:33:33 (#15)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou > podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i > louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, > ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek > rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti.
Tak jsem v ramci treningu skouknul DIBAVOD-A16 (brehove linie toku *) a to da zhruba 1M bodu, 18MB v .osm.bz2 *) neobsahuje vodni nadrze ani linie tenkych toku, tu jsou v jinych datovych souborech, viz: http://www.vuv.cz/oddeleni-gis/index.php?id=27 -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

22.10.2008 04:44:21 (#16)
gravatar

Martin Kokeš

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

22.10.2008 04:51:53 (#17)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Martin Kokeš napsal(a): zobrazit citaci
> Petr Nejedly napsal(a): >> Tomas Kolda napsal(a): >> >>> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou >>> podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i >>> louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, >>> ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek >>> rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti. >>> >> Tak jsem v ramci treningu skouknul DIBAVOD-A16 (brehove linie toku *) >> a to da zhruba 1M bodu, 18MB v .osm.bz2 >> >> *) neobsahuje vodni nadrze ani linie tenkych toku, tu jsou v jinych >> datovych souborech, viz: http://www.vuv.cz/oddeleni-gis/index.php?id=27 >> > > Já jsem se dival v ArcExploreru na ty vodní nádrže a rozhodně nelze > říct, že by tam byly nějaké zbytečné "louže". Proto navrhuju stejně jako > u břehových linií případnou korekci (odstranění zbytečných nodů) nechat > na ručním zpracování.
No ja jsem se mezitim mrknul i na A01 (osy vsech toku) a to bylo bratru 5M bodu a vsechno siroko daleko (cela republika) modre. A kdyz jsem se koukal zblizka na horni tok moravy (od pramene po obec Horni Morava, cili asi 8km), bylo tam spousta potucku ;-) -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

22.10.2008 05:05:30 (#18)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Petr Nejedly napsal(a): zobrazit citaci
> 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

22.10.2008 08:02:53 (#19)
gravatar

hanoj

<ehanoj at gmail.com>
718
Dne 21. říjen 2008 19:12 Martin Kokeš <shr3k na typo3-hosting.com> napsal(a): zobrazit citaci
> 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? zobrazit citaci
>, 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

22.10.2008 08:48:58 (#20)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
hanoj napsal(a): zobrazit citaci
> 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. zobrazit citaci
>> , 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

23.10.2008 10:32:00 (#21)
gravatar

Tomas Kolda

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

23.10.2008 10:49:52 (#22)
gravatar

Karel Volný

<kavol at seznam.cz>
563
Dne úterý 21 říjen 2008 Martin Kokeš napsal(a): zobrazit citaci
> Jiri Klement napsal(a): > >> V tom pripade jdu na to. Dibavod obsahuje celou CR s neuveritelnou > >> podrobnosti. Problem bude vyfiltrovani dat, protoze obsahuji snad i > >> louze :) Bude potreba udelat nejakou simplifikaci a pridani jen toku, > >> ktere maji alespon nazev. No to se muzeme domluvit. Zkusim udelat vzorek > >> rek, vodnich nadrzi a obrysu brehu (riverbank) v nejake oblasti. > > > > Pokud budou ty data presna, tak bych je prilis nezjednodusoval. To > > same pro ruzne potucky, skoro zadny nema oficialni nazev, ale jsou to > > dulezite orientacni body. > > Mám stejný názor. Myslel jsem si také, že tu děláme mapy a ne jakési > pseudokartogramy... :-)
+1 prolítnul jsem si maily o konkrétních velikostech ... s lehkým přimhouřením oka se dá říci, že Mooreův zákon stále funguje, takže co se nám dnes zdá z hlediska zpracování nepředstavitelně veliké a podrobné bude za chvíli "uboze jednoduché" nejsem sice přítelem vynucování hardwarových upgradů, nicméně neměli bychom se tomu bránit za cenu zahazování kvalitních dat, nýbrž zkvalitněním jejich zpracování (a teď si jdu zamést před vlastním prahem a dát si do úkolů při zprovozňování svého generátoru dlaždic, že nemám plýtvat přenosovou kapacitou na stahování celého snapshotu, když lze - pokud vím - získat jen rozdílové aktualizace) just my €0.02 ;-) K.

23.10.2008 11:00:32 (#23)
gravatar

Tomas Kolda

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

23.10.2008 11:30:39 (#24)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
Tomas Kolda píše v Čt 23. 10. 2008 v 10:32 +0200: zobrazit citaci
> 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. -- Stanislav Brabec http://www.penguin.cz/~utx

23.10.2008 11:39:41 (#25)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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. > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081023/f28fa89c/attachment.html>

24.10.2008 12:33:55 (#26)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081024/47b915ca/attachment.html>

24.10.2008 12:46:14 (#27)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081024/71e24f98/attachment.html>

24.10.2008 01:41:31 (#28)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
On Fri, 24 Oct 2008 00:33:55 +0200, Tomas Kolda <kolda na web2net.cz> wrote: zobrazit citaci
> 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) zobrazit citaci
> > 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):
-- Petr Dlouhý

24.10.2008 01:48:13 (#29)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Petr Dlouhý napsal(a): zobrazit citaci
> 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

24.10.2008 07:14:14 (#30)
gravatar

Tomas Kolda

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

24.10.2008 07:22:51 (#31)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
On Fri, 24 Oct 2008 01:41:31 +0200, Petr Dlouhý <petr.dlouhy na email.cz> wrote: 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". zobrazit citaci
> 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) > >
-- Petr Dlouhý ------------- další část --------------- A non-text attachment was scrubbed... Name: osmrsd_porov.tar.bz2 Type: application/bzip2 Size: 1953 bytes Desc: [žádný popis není k dispozici] URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081024/321d6e45/attachment.bin>

24.10.2008 07:52:29 (#32)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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. zobrazit citaci
> 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ý

24.10.2008 08:02:20 (#33)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >> >> > > > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081024/6f407b28/attachment.html>

24.10.2008 08:23:12 (#34)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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é. zobrazit citaci
> 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. zobrazit citaci
> > 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ý

24.10.2008 09:37:19 (#35)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> 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 "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

24.10.2008 09:42:52 (#36)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> 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 -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

24.10.2008 09:48:37 (#37)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
V tom pripade se pouziva to co jsem psal v druhem odstavci (sekani ways pomoci algoritmu, jenz urcuje zda tam krizovatka je ci neni). Komercni navigacni data napr. multinet jsou skutecne rozsekana po castech (format GDF). Jestli je to v OSM takto zavedene, tak proc ne. Asi tento zpusob zpracovani zavedli, protoze je tak kreslena vetsina silnic. Osobne bych volil druhou variantu, ale na to uz je pozde... T Petr Nejedly napsal(a): zobrazit citaci
> 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? > >

24.10.2008 09:51:30 (#38)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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 Petr Nejedly napsal(a): zobrazit citaci
> Tomas Kolda napsal(a): > >> Ahoj, >> >> takze jsem dodelal import. Dost me zdrzel prevod souradnic, ale melo by >> to byt ok. Pro zvedave k presnosti posilam vysek databaze v okoli >> prehrady. Zatim je tam jen waterway a vzdy river, ale nazvy uz tam >> jsou.Polygony a brehy jeste dodelavam. >> >> Podivejte na super prehnanou presnost u nekterych potucku, presne jak >> jsem rikal. >> >> http://www.web2net.cz/osm/dibavod.zip >> > > Mohl bys, prosim, zkusit udelat kousek na hornim toku Moravy? > Mapoval jsem ho podle ortofoto, ale nakonec jsem to doladil podle katastru, > a muj pokusny import DIBAVODu mel stejny tvar krivek, ale byl o par (desitek) metru mimo.... > http://www.openstreetmap.org/?lat=50.15321&lon=16.81535&zoom=17&layers=B000FTF > >
------------- další ?ást --------------- HTML p?íloha byla odstran?na... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081024/9a022971/attachment.html>

24.10.2008 10:04:18 (#39)
gravatar

Ondrej Novy

<onovy at nomi.cz>
81
Ahoj, On Fri, Oct 24, 2008 at 09:48:37AM +0200, Tomas Kolda wrote: zobrazit citaci
> 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). -- S pozdravem/Best regards Ondrej Novy Email: onovy na nomi.cz Jabber: onovy na njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207

24.10.2008 10:07:19 (#40)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> 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] zobrazit citaci
> 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". -- Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation!

24.10.2008 10:08:35 (#41)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Ja to delam presne obracene, pro grafiku spojuji entity se stejnymi atributy a navigacni data beru tak jak jsou. Proste to pro OSM upravim... A stejne tak se to bude muset udelat pro Garmin, jak rikas. A timto bych uzavrel tenhle offtopic :) T Ondrej Novy napsal(a): zobrazit citaci
> Ahoj, > > On Fri, Oct 24, 2008 at 09:48:37AM +0200, Tomas Kolda wrote: > >> V tom pripade se pouziva to co jsem psal v druhem odstavci (sekani ways >> pomoci algoritmu, jenz urcuje zda tam krizovatka je ci neni). Komercni >> navigacni data napr. multinet jsou skutecne rozsekana po castech (format >> GDF). >> Jestli je to v OSM takto zavedene, tak proc ne. Asi tento zpusob >> zpracovani zavedli, protoze je tak kreslena vetsina silnic. Osobne bych >> volil druhou variantu, ale na to uz je pozde... >> > > ber to tak, ze z aktualni varianty do tve varianty se to da kdykoliv > zkonvertovat 'online' (napr. pri buildovani routovacich dat - tak to dela > Garmin - ma ulozeny cary jako spojnice + routovaci graf zvlast, mimo jine > proto v Garminu nefunguje aktualne routovani nad OSM :). > Obracene to jde hur (nemuzu jen tak spojovat automaticky veci). > >
------------- další ?ást --------------- HTML p?íloha byla odstran?na... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081024/6bc3e24b/attachment.html>

24.10.2008 10:12:33 (#42)
gravatar

Petr Nejedly

<Petr.Nejedly at Sun.COM>
111
Tomas Kolda napsal(a): zobrazit citaci
> 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? zobrazit citaci
> 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). zobrazit citaci
> 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!

24.10.2008 10:13:55 (#43)
gravatar

Petr Dlouhý

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

24.10.2008 10:36:58 (#44)
gravatar

Ondrej Novy

<onovy at nomi.cz>
81
Ahoj, On Fri, Oct 24, 2008 at 10:13:55AM +0200, Petr Dlouhý wrote: zobrazit citaci
> 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. -- S pozdravem/Best regards Ondrej Novy Email: onovy na nomi.cz Jabber: onovy na njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207

24.10.2008 11:27:02 (#45)
gravatar

Martin Vidner

<martin.osm at vidner.net>
34
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>: zobrazit citaci
> 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.

24.10.2008 11:29:15 (#46)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Tyto data jsou dabavod, coz neni povodi Labe. Melo by se to nejak ridit asi tim zakonem, jak bylo zminovano v tomto threadu. T Martin Vidner napsal(a): zobrazit citaci
> Petr Nejedly uz psal, ale asi to zapadlo: > V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na > vytištěném listu > takto: "(c) Zpracováno s použitím dat Povodí Labe" > http://www.pla.cz/planet/ram.aspx?id=21 > > 2008/10/24 Tomas Kolda <kolda na web2net.cz>: > >> PS: Jeste poprosim nekoho komu neprijdou zakony dost sifrovane at nezavisle >> potvrdi tu moznost pouziti. Ja se v pravni hantyrce neorientuji... Jen >> abysme to pak cele nemuseli revertovat. >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081024/879aed4d/attachment.html>

24.10.2008 11:55:32 (#47)
gravatar

Pavel Machek

<pavel at suse.cz>
144
Ahoj! zobrazit citaci
> 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... zobrazit citaci
> 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 -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

24.10.2008 02:41:10 (#48)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> 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. zobrazit citaci
> 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

24.10.2008 02:48:10 (#49)
gravatar

BH

<singularita at gmail.com>
306
2008/10/24 Petr Dlouhý <petr.dlouhy na email.cz>: zobrazit citaci
> 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

24.10.2008 03:01:51 (#50)
gravatar

Stanislav Brabec

<utx at penguin.cz>
152
BH píše v Pá 24. 10. 2008 v 14:41 +0200: zobrazit citaci
> > 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 -- Stanislav Brabec http://www.penguin.cz/~utx

26.10.2008 06:51:57 (#51)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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

27.10.2008 10:48:06 (#52)
gravatar

Pavel Machek

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

27.10.2008 05:15:09 (#53)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
Je to strasne velike, takze s uploadem cekam az nekdo alespon rekne, ze ten vyrez je prijatelnej... T Pavel Machek napsal(a): zobrazit citaci
>> Petr Nejedly uz psal, ale asi to zapadlo: >> V případě tisku si zpracovatel vyhrazuje uvedení copyrightu na >> vytištěném listu >> takto: "(c) Zpracováno s použitím dat Povodí Labe" >> http://www.pla.cz/planet/ram.aspx?id=21 >> > > No, pokud jsem to spravne pochopil, tak nam to povodi Labe pisemne > dovolilo pouzit :-). Mohli bychom se jich jeste extra zeptat... > > Je nekde ke stazeni v osm formatu dibavod pro celou republiku? > Zajimalo by me treba okoli Rican... > Pavel >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081027/c183475d/attachment.html>

27.10.2008 06:18:59 (#54)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
On Mon, 27 Oct 2008 17:15:09 +0100, Tomas Kolda <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). zobrazit citaci
> Je to strasne velike, takze s uploadem cekam az nekdo alespon rekne, ze > ten vyrez je prijatelnej... > > T >
-- Petr Dlouhý

27.10.2008 07:09:30 (#55)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
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> 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). ------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081027/49ea8b52/attachment.html>

27.10.2008 07:17:23 (#56)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081027/8496b3d7/attachment.html>

27.10.2008 07:54:26 (#57)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> Jo, mě ten výřez přišel v pořádku. Osobně bych tu generalizaci nedělal (až
Mrknul jsem na to a vypada to ok. Jak se bude resit kolize se soucasnymi daty? (dost vodstva uz tam mame, vetsinou asi s mensi presnosti, takze nejspis by to chtelo po importu ty stary data nejak selektivne promazat (mozna smazat vicemene vse, ale zase treba tam nekde budou nejake mistni nazvy vodnich ploch nebo ruzne male pozarni nadrze co v dibavodu byt nemusi ...)) Mozna soucasna data oznacit nejakym tagem "mozna duplicita, po kontrole smazat" zobrazit citaci
> 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
I tak presnejsi nez nadrze co jsem obkreslil z UHULu ... ale zase tolik neusetrime a mensi nepresnost nez ty 2 metry by byla uz celkem videt. Asi bych naimportovat ty "jednometrova" data. zobrazit citaci
> 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).
V tom vyrezu jsou brehy jen pro nadrze, pro reky uz ne ... ani pro ty vetsi jako treba Vltava :) Martin

27.10.2008 08:29:42 (#58)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> 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. zobrazit citaci
> 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 :), zobrazit citaci
> 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

27.10.2008 08:49:04 (#59)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
On Mon, 27 Oct 2008 19:17:23 +0100, Tomas Kolda <kolda na web2net.cz> wrote: zobrazit citaci
> > 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ý

27.10.2008 09:29:37 (#60)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Petr Dlouhý napsal(a): zobrazit citaci
> 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

27.10.2008 09:36:36 (#61)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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. > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081027/aeea27a9/attachment.html>

27.10.2008 09:58:47 (#62)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
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? zobrazit citaci
> > 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ý

27.10.2008 10:02:29 (#63)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >> >> > > >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081027/444b6fc6/attachment.html>

27.10.2008 10:07:42 (#64)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081027/39b046fa/attachment.html>

27.10.2008 10:29:53 (#65)
gravatar

BH

<singularita at gmail.com>
306
zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> 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. zobrazit citaci
> -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. zobrazit citaci
> 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 zobrazit citaci
>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 .... zobrazit citaci
> 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

27.10.2008 10:34:01 (#66)
gravatar

Martin Kokeš

<shr3k at typo3-hosting.com>
135
Tomas Kolda napsal(a): zobrazit citaci
> - 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>

27.10.2008 11:56:22 (#67)
gravatar

Tomas Kolda

<kolda at web2net.cz>
133
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): zobrazit citaci
> 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 >
------------- další část --------------- HTML příloha byla odstraněna... URL: <https://lists.openstreetmap.org/pipermail/talk-cz/attachments/20081027/770cd212/attachment.html>

28.10.2008 12:00:20 (#68)
gravatar

Ondrej Novy

<onovy at nomi.cz>
81
Ahoj, On Mon, Oct 27, 2008 at 10:29:53PM +0100, BH wrote: zobrazit citaci
> 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. -- S pozdravem/Best regards Ondrej Novy Email: onovy na nomi.cz Jabber: onovy na njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207

29.10.2008 03:06:09 (#69)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Mon 2008-10-27 17:15:09, Tomas Kolda wrote: zobrazit citaci
> Je to strasne velike, takze s uploadem cekam az nekdo alespon rekne, ze > ten vyrez je prijatelnej...
Ten vyrez vypada moc hezky... me se nejvic libi puvodni varianta, ale ani po generalizaci to neni spatne... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

29.10.2008 03:10:18 (#70)
gravatar

Pavel Machek

<pavel at suse.cz>
144
On Mon 2008-10-27 19:54:26, BH wrote: zobrazit citaci
> > Jo, mě ten výřez přišel v pořádku. Osobně bych tu generalizaci nedělal (až > > Mrknul jsem na to a vypada to ok. Jak se bude resit kolize se > soucasnymi daty? (dost vodstva uz tam mame, vetsinou asi s mensi > presnosti, takze nejspis by to chtelo po importu ty stary data nejak > selektivne promazat (mozna smazat vicemene vse, ale zase treba tam > nekde budou nejake mistni nazvy vodnich ploch nebo ruzne male pozarni > nadrze co v dibavodu byt nemusi ...)) > > Mozna soucasna data oznacit nejakym tagem "mozna duplicita, po kontrole smazat"
Pri importu bych aktualni data nemazal. Oznacit by se mohli -- ale na druhou stranu proc, ta nova oznacena jsou a stara se tak poznaji snadno. Procisteni bych nechal na principu 'kdo co vytvoril to taky smaze' respektive 'kdyz jsem neco vytvoril tak se rozhodnu jestli je lepsi to moje nebo dibavod, a to horsi smaznu'... U lesu to fungovalo. (a chtit po jednom cloveku aby krome importu delal procistovani cely republiky je imo nesmysl). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

30.10.2008 06:54:46 (#71)
gravatar

BH

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

30.10.2008 07:00:48 (#72)
gravatar

Petr Dlouhý

<petr.dlouhy at email.cz>
607
On Thu, 30 Oct 2008 18:54:46 +0100, BH <singularita na gmail.com> wrote: zobrazit citaci
>> Procisteni bych nechal na principu 'kdo co vytvoril to taky smaze' >> respektive 'kdyz jsem neco vytvoril tak se rozhodnu jestli je lepsi to >> moje nebo dibavod, a to horsi smaznu'... U lesu to fungovalo. (a chtit >> po jednom cloveku aby krome importu delal procistovani cely republiky >> je imo nesmysl). > > Ja osobne si teda nepamatuju kde vsude jsem dokresloval nejake vodstvo > ... bylo to na celkem dost mistech. U lesu to sice funguje celkem > dobre, ale myslim ze i ted jsou stale v mape jeste duplicitni lesy :) > > I kdyz napadlo mne reseni (ktere by mohlo nakonec resit vice veci > najednou) - vezme se cela czechie, z ni se vyfiltruje veskere vodstvo > a na vystup se zkopiruje to, kde se neco protina/prekryva (coz nebude > zas uplne jednoduche, minimalne ne pokud to ma dobehnout v rozumnem > case :). To si pak muzou pootvirat lidi treba v JOSM, jit na misto kde > tenhle skript vyplivl kolizi, stahnout si tam normalni data a nejak to > resit. Podobny soubor by se mohl udelat i pro lesy, eventuelne pro > "chybna data" - typicke preklepy typu highway=residental, neoznacene > ways (casto je nekdo zapomnel otagovat a ways bez tagu jsou jaksi k > nicemu), body a ways obsahujici nejake FIXME, highway=road (ty to chce > upresnit) apod .... > > Martin >
Pokud těch dat není mnoho (cca do 100MB nekomprimovaně, na ty překlepy to stačit bude určitě), tak stačí použít xapi. Tedy například: http://xapi.openstreetmap.org/api/0.5/*[highway=residental][bbox=12.06,48.57,18.97,51.06] zobrazit citaci
> _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz
-- Petr Dlouhý

30.10.2008 07:38:48 (#73)
gravatar

BH

<singularita at gmail.com>
306
To jde, pokud podminka je jednoducha, ale pokud chci neoznacene ways, ktere ale nejsou casti relation, tak na to uz asi xapi ponekud nestaci. A ani nepredpokladam, ze by to dokazalo najit prekryvajici se lesy :) Cas od casu si takhle z xapi vyzadam typicke preklepy pro cely svet a hromadne to opravim (residental -> residential, town_hall -> townhall, atd ...), ale napadlo mne napsat nejakou komplexnejsi kontrolu (vyhledove s mnoha podminkami a kontrolou i kombinaci tagu) Martin zobrazit citaci
> Pokud těch dat není mnoho (cca do 100MB nekomprimovaně, na ty překlepy to > stačit bude určitě), tak stačí použít xapi. > Tedy například: > http://xapi.openstreetmap.org/api/0.5/*[highway=residental][bbox=12.06,48.57,18.97,51.06]

1.11.2008 10:24:58 (#74)
gravatar

hanoj

<ehanoj at gmail.com>
718
Dne 30. říjen 2008 19:38 BH <singularita na gmail.com> napsal(a): zobrazit citaci
> To jde, pokud podminka je jednoducha, ale pokud chci neoznacene ways, > ktere ale nejsou casti relation, tak na to uz asi xapi ponekud > nestaci. A ani nepredpokladam, ze by to dokazalo najit prekryvajici se > lesy :) > > Cas od casu si takhle z xapi vyzadam typicke preklepy pro cely svet a > hromadne to opravim (residental -> residential, town_hall -> townhall, > atd ...), ale napadlo mne napsat nejakou komplexnejsi kontrolu > (vyhledove s mnoha podminkami a kontrolou i kombinaci tagu)
*** Pokud mi nekdo prevede dve datove sady na ESRI Shapefile nebo neco podobneho, neni problem v nejakem GIS udelatku vratit seznam objektu, ktere se prekryvaji, krizi, etc... hanoj

« zpět na výpis měsíce