Re: [Talk-cz] pokusny import lesu
Tak mapping party tam asi tezko pujde usporadat :) Ale z UHUL ortofota by to zmapovat jit melo v pohode, vcetne vsech cest a silnic :) Martin 2008/8/4 Michal Kovar [EMAIL PROTECTED]: Toho uz se nekdo rad chopi :) On Mon, 04 Aug 2008 13:24:14 +0200, Kubajz [EMAIL PROTECTED] wrote: Sexy je, ale na muj vkus je moc hrube namletej... Trosku, ale jen nepatrne bych ho zkusil pojemnit. Misty je to opravdu takove otesane. A pak je krasny, jak v UHULu nemaji zaneseny lesy ve vojenskych ujezdech... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj, Petr Nejedly napsal(a): Jiri Klement napsal(a): Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29. Vy jste teda rychlici. Jestlipak jste se na to po sobe aspon trochu podivali? Pred importem jsem vyhazoval cesty z lesu a jine podobne artefakty, co se mi nelibily. Potom odstranuji nektere prebytecne body. Prekvapilo me, ze algoritmus generalizace za sebou zanechal treba tri body v rozmezi 20m na uplne rovne care... Ja tu svoji 015 (co byla na serveru na to tata) stale jeste ucesavam... Mel jsem tam nejake prekryvy se stavajicimi lesy a taky rusim diry na silnici, prekryvy se stavajicimi lesy jsou asi to nejhorsi. Vzhledem k nutnemu vypnuti mappaintu je v tech carach dost bordel... coz je v JOSM docela pakarna*. Take se nabizi uzasna moznost domalovat ty silnice, co v databazi chybi, ale je na ne tunel v lese - takovou silnici podle ortofoto nenamalujete. ja rusim akorat cesty v lese, pokud jsou v ramci jednoho lesa. Vic lesu dohromady nespojuji, protoze to je fakt desna pakarna. Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa? Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les sdilely nody *) sloucit dva polygony: - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way - bud domalovat dve propojovaci waye nebo zmergovat stycne body - join way - spojit dva vysledne skoropolygony - celou dobu davat pozor na relace Neumi to nekdo lepe? ja ne ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Pred importem jsem vyhazoval cesty z lesu a jine podobne artefakty, co se mi nelibily. Potom odstranuji nektere prebytecne body. Prekvapilo me, ze algoritmus generalizace za sebou zanechal treba tri body v rozmezi 20m na uplne rovne care... No ten algoritmus ma svoje vyhody (non-intersection), ale i nevyhody. Tyto body za sebou vznikaji tim, ze se nekde zacne (v kazdem polygonu jsou dva bodiky tesne u sebe) a zbytek se dela viditelnosti. Hranice viditelnosti se nesmi menit a je pevna. Potom zustavaji body, ktere by klasickej DP vyhodil. Ale myslim, ze za ty non-intersect to stalo. Diry bohuzel vycouhnout muzou, protoze se delaji zvlast. T ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
2008/8/6 Kubajz [EMAIL PROTECTED]: Uploaduji kus 32. Pro rekapitulaci by bylo dobre do kazdeho rezervacniho mailu napsat jiz vsechny poslane kusy. Proto: uz tam jsou: 001,003,004,006,007,008,015 a 032 K uz tam jsou: 001,003,004,006,007,008,015,016 a 032 uploaduju 20 -- Michal Grézl http://walley.org ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
2008/8/6 Kubajz [EMAIL PROTECTED]: Uploaduji kus 32. Pro rekapitulaci by bylo dobre do kazdeho rezervacniho mailu napsat jiz vsechny poslane kusy. Proto: uz tam jsou: 001,003,004,006,007,008,015 a 032 K uz tam jsou: 001,003,004,006,007,008,015,016 a 032 uploaduju 20 Rezervujte mi 2 a 5. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ja uploadnu 33 uz tam jsou: 001,003,004,006,007,008,015 a 032 K uz tam jsou: 001,003,004,006,007,008,015,016 a 032 uploaduju 20 -- Michal Grézl http://walley.org ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tu už uploaduju já Pů1vodní zpráva Od: Pavel Machek [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 10:28:07 Ja uploadnu 33 uz tam jsou: 001,003,004,006,007,008,015 a 032 K uz tam jsou: 001,003,004,006,007,008,015,016 a 032 uploaduju 20 Tak to mame 1-8, 15-16, 20, 32-33. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Dne 5. srpen 2008 21:54 Pavel Machek [EMAIL PROTECTED] napsal(a): On Tue 2008-08-05 13:03:30, hanoj wrote: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. Urcite mam jinou versi josm, a urcite nemam mappaint. *** od blizke API 0.6 si budes muset tu novou verzi stahnout. taktedy na tom budes stejne ;) hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
API 0.6 asi neni az tak blizko. Jeden a pul mesice na nem nikdo nepracoval. 2008/8/6 hanoj [EMAIL PROTECTED]: Dne 5. srpen 2008 21:54 Pavel Machek [EMAIL PROTECTED] napsal(a): On Tue 2008-08-05 13:03:30, hanoj wrote: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. Urcite mam jinou versi josm, a urcite nemam mappaint. *** od blizke API 0.6 si budes muset tu novou verzi stahnout. taktedy na tom budes stejne ;) hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tak to mame 1-8, 15-16, 20, 32-33. nekdo psal nekde o 17 tak ja bych uploadnul jeste 18 a 19 -- Michal Grézl http://walley.org ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Mara Michal Grézl napsal(a): Tak to mame 1-8, 15-16, 20, 32-33. nekdo psal nekde o 17 tak ja bych uploadnul jeste 18 a 19 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Dovolil bych si vzit DVE a to 11 a 12 a zprehlednit tabulku :) 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 14 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 22 23 24 25 26 27 28 29 30 31 32 UPLOADED 33 UPLOADED Původní zpráva Od: Marek Musil [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 12:19:25 Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Mara Michal Grézl napsal(a): Tak to mame 1-8, 15-16, 20, 32-33. nekdo psal nekde o 17 tak ja bych uploadnul jeste 18 a 19 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 Původní zpráva Od: noone02 [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:01:56 Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak ty uz tam taky jsou. To je bordel... K Petr Schonmann napsal(a): vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 Původní zpráva Od: noone02 [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:01:56 Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
megabordel :) Původní zpráva Od: Kubajz [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:32:36 on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak ty uz tam taky jsou. To je bordel... K Petr Schonmann napsal(a): vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 Původní zpráva Od: noone02 [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:01:56 Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
2008/8/6 Petr Schonmann [EMAIL PROTECTED]: megabordel :) navic uplne celej zelenej, doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to pak po sobe muzete zase smazat kdyz to tam bude 2x;)) -- Michal Grézl http://walley.org ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tabulku jsem upravil, protoze uploaduji 13 a 14 Kubajz napsal(a): on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak ty uz tam taky jsou. To je bordel... K Petr Schonmann napsal(a): vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 Původní zpráva Od: noone02 [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:01:56 Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ja jsem to zpetne zjistil. Ono neni fer upravovat citovanou cast dopisu - pro me to vypadalo, ze to tam napsal uz Petr Schonmann. Analyzou jeho prispevku jsem pak dorbny rozdil zjistil a uz jsem v klidu. K noone02 napsal(a): Tabulku jsem upravil, protoze uploaduji 13 a 14 Kubajz napsal(a): on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak ty uz tam taky jsou. To je bordel... K Petr Schonmann napsal(a): vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 Původní zpráva Od: noone02 [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:01:56 Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj! megabordel :) navic uplne celej zelenej, doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to pak po sobe muzete zase smazat kdyz to tam bude 2x;)) No, mel jsem tady neprijemny crash masiny :-(. Takze tam par nodu bude 2x. Doufam ze to chytne nejakej lint... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Validator v JOSM to najde a umi i opravit... K Pavel Machek napsal(a): Ahoj! megabordel :) navic uplne celej zelenej, doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to pak po sobe muzete zase smazat kdyz to tam bude 2x;)) No, mel jsem tady neprijemny crash masiny :-(. Takze tam par nodu bude 2x. Doufam ze to chytne nejakej lint... Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tak jsem douplodoval, takze si beru dalsi dve 21, 22 Aktualni stav je tedy doufam tento: 001-022, 031-033 2008/8/6 Kubajz [EMAIL PROTECTED]: Validator v JOSM to najde a umi i opravit... K Pavel Machek napsal(a): Ahoj! megabordel :) navic uplne celej zelenej, doufam ze si nechavate uploadnute osm s vracenymi id z databaze, at to pak po sobe muzete zase smazat kdyz to tam bude 2x;)) No, mel jsem tady neprijemny crash masiny :-(. Takze tam par nodu bude 2x. Doufam ze to chytne nejakej lint... Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tak uz se zacinaji objevovat vyrenderovana data. Treba tady: http://www.openstreetmap.org/?lat=49.7497lon=16.2061zoom=12layers=0B0FTF 2008/8/6 Kubajz [EMAIL PROTECTED]: Beru 30, takze: 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 26 27 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED Kubajz napsal(a): Abych se vyhl sprostemu slovu, pouziji terminus technicus - zvysim entropii a obsazuji v tabulce dalsi - tentokrat 31 :) 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10UPLOADED 11UPLOADED 12UPLOADED 13UPLOADED 14UPLOADED 15UPLOADED 16UPLOADED 17UPLOADED 18UPLOADED 19UPLOADED 20UPLOADED 21 22 23 24 25 26 27 28 29 30 31UPLOADED 32UPLOADED 33UPLOADED Petr Schonmann napsal(a): megabordel :) Původní zpráva Od: Kubajz [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:32:36 on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak ty uz tam taky jsou. To je bordel... K Petr Schonmann napsal(a): vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 Původní zpráva Od: noone02 [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:01:56 Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
A nejen v Osmarenderu. Dokonce i v mapniku uz jsou asi dva pruhy pres CR: http://www.openstreetmap.org/?lat=49.955lon=14.979zoom=9layers=B00FTF K Jiri Klement napsal(a): Tak uz se zacinaji objevovat vyrenderovana data. Treba tady: http://www.openstreetmap.org/?lat=49.7497lon=16.2061zoom=12layers=0B0FTF 2008/8/6 Kubajz [EMAIL PROTECTED]: Beru 30, takze: 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 26 27 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED Kubajz napsal(a): Abych se vyhl sprostemu slovu, pouziji terminus technicus - zvysim entropii a obsazuji v tabulce dalsi - tentokrat 31 :) 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10UPLOADED 11UPLOADED 12UPLOADED 13UPLOADED 14UPLOADED 15UPLOADED 16UPLOADED 17UPLOADED 18UPLOADED 19UPLOADED 20UPLOADED 21 22 23 24 25 26 27 28 29 30 31UPLOADED 32UPLOADED 33UPLOADED Petr Schonmann napsal(a): megabordel :) Původní zpráva Od: Kubajz [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:32:36 on se pak opravil, ze si bere 13 a 14, ale pokud jsem cetl tabulku, tak ty uz tam taky jsou. To je bordel... K Petr Schonmann napsal(a): vzdyt jsem si je bral ja... Mimochodem pri uploadu 33 nejdou nektere nody uploadovat. Skonci odezvou od serveru ch 412 Původní zpráva Od: noone02 [EMAIL PROTECTED] Předmět: Re: [Talk-cz] pokusny import lesu Datum: 06.8.2008 13:01:56 Marek Musil napsal(a): Pridam se a beru si 009 a 010 Tedy obsazene jsou: 1-10, 15-20, 32-33 Beru si 011 a 012 Obsazene jsou 001-012, 015-020, 032-033 ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz S pozdravem Mail: [EMAIL PROTECTED] http://fatbozz.towerofglass.net ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Beru 23 a 24 Stav je tedy následující link - http://www.web2net.cz/osm/lesy_001.osm.bz2 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 UPLOADED 24 UPLOADED 25 26 27 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ok, vemu 25-27... 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 UPLOADING 26 UPLOADING 27 UPLOADING 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Radeji to upresnim podle konvence, co drzime od zacatku... Zbyvaji tedy posledni dve - 28 a 29. 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 UPLOADED 24 UPLOADED 25 UPLOADED 26 UPLOADED 27 UPLOADED 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED Pavel Machek napsal(a): Ok, vemu 25-27... 1UPLOADED 2UPLOADED 3UPLOADED 4UPLOADED 5UPLOADED 6UPLOADED 7 UPLOADED 8UPLOADED 9UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 UPLOADING 26 UPLOADING 27 UPLOADING 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ok, vemu 25-27... 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 UPLOADING 26 UPLOADING 27 UPLOADING 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - End forwarded message - -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29. Takze by mely byt vsechny casti rozebrany. On Wed, Aug 6, 2008 at 7:27 PM, Pavel Machek [EMAIL PROTECTED] wrote: Ok, vemu 25-27... 1 UPLOADED 2 UPLOADED 3 UPLOADED 4 UPLOADED 5 UPLOADED 6 UPLOADED 7 UPLOADED 8 UPLOADED 9 UPLOADED 10 UPLOADED 11 UPLOADED 12 UPLOADED 13 UPLOADED 14 UPLOADED 15 UPLOADED 16 UPLOADED 17 UPLOADED 18 UPLOADED 19 UPLOADED 20 UPLOADED 21 UPLOADED 22 UPLOADED 23 24 25 UPLOADING 26 UPLOADING 27 UPLOADING 28 29 30 UPLOADED 31 UPLOADED 32 UPLOADED 33 UPLOADED -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - End forwarded message - -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Jiri Klement napsal(a): Ja jsem zrovna douplodoval, takze beru posledni dve - 28 a 29. Vy jste teda rychlici. Jestlipak jste se na to po sobe aspon trochu podivali? Ja tu svoji 015 (co byla na serveru na to tata) stale jeste ucesavam... Mel jsem tam nejake prekryvy se stavajicimi lesy a taky rusim diry na silnici, coz je v JOSM docela pakarna*. Take se nabizi uzasna moznost domalovat ty silnice, co v databazi chybi, ale je na ne tunel v lese - takovou silnici podle ortofoto nenamalujete. Kdyz uz jsme u toho, jak byste resili silnici na kraji lesa? Zatim jsem to nedelal, ale primo to krici po tom, aby way a prilehly les sdilely nody *) sloucit dva polygony: - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way - bud domalovat dve propojovaci waye nebo zmergovat stycne body - join way - spojit dva vysledne skoropolygony - celou dobu davat pozor na relace Neumi to nekdo lepe? -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Petr Nejedly writes: *) sloucit dva polygony: - vybrat dva stycne body na prvnim polygonu, split way, smazat jednu way - vybrat dva stycne body na druhem polygonu, split way, smazat jednu way - bud domalovat dve propojovaci waye nebo zmergovat stycne body - join way - spojit dva vysledne skoropolygony - celou dobu davat pozor na relace Neumi to nekdo lepe? Nepsal jste uz nekdo plugin do JOSM? Nebo pripadne nekoukal na API? Neprijde mi to jako slozita uloha, pokud je pristup k objektum. Stacilo by udelat nejaky tool... Me delali problem hlavne ty relace. JOSM je pri splitu kopiruje a pak si clovek musi davat pozor jak polygon rozdelil, aby nechal diry ve spravnych outer. Neumite v JOSMu schovat vse krome lesu? ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ja jsem pro. Uz vcera se mi to libilo a tohle je jeste lepsi. Uz se tesim, az to tam bude :) Jen by me zajimalo, co se stane se stavajicimi lesy, ktere uz na serveru jsou - budou smazany nebo budou pres sebe? On Tue, 05 Aug 2008 07:48:32 +0200, Tomas Kolda [EMAIL PROTECTED] wrote: Dik za rady. Zaporne idcka mam, otaguju uhulem. Jen to tedy splitnu a zkusim JOSMem vecer naimportovat prvni dvacetinu co to udela. Mam tedy importovat tu druhou variantu? T Petr Nejedly writes: Pavel Machek napsal(a): Ahoj! tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Byl by .osm.bz2? Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Ja jsem silnice importoval normalne josm-kem. Coz m.j. znamena generovat zaporna ID. -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
To jsem si myslel :) On Tue, 05 Aug 2008 09:43:15 +0200, Michal Grézl [EMAIL PROTECTED] wrote: 2008/8/5 Michal Kovar [EMAIL PROTECTED]: Ja jsem pro. Uz vcera se mi to libilo a tohle je jeste lepsi. Uz se tesim, az to tam bude :) Jen by me zajimalo, co se stane se stavajicimi lesy, ktere uz na serveru jsou - budou smazany nebo budou pres sebe? Stavajici lesy nijak nemenit!!! Je jich tam tak malo, ze se lehce opravi rucne. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Druha se mi zda subjektivne hezci. Jsem pro otagovat to source=uhul:wms Importovat pravdepodobne po nejakych rozumne velkych celcich skrz JOSM. Dobra prace! K Tomas Kolda napsal(a): Dik za rady. Zaporne idcka mam, otaguju uhulem. Jen to tedy splitnu a zkusim JOSMem vecer naimportovat prvni dvacetinu co to udela. Mam tedy importovat tu druhou variantu? T Petr Nejedly writes: Pavel Machek napsal(a): Ahoj! tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Byl by .osm.bz2? Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Ja jsem silnice importoval normalne josm-kem. Coz m.j. znamena generovat zaporna ID. -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj! 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi oblasti (napr. okres)? Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni efektivne data v CR dale editovat napric platformami. Pokud tato jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha pracovat s ctvercem o hrane 20km neni az tak neprirozena. Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s necim o hrane 20km fakt nebude problem. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
On Tue 2008-08-05 10:59:41, Petr Nejedly wrote: Pavel Machek napsal(a): Ahoj! 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi oblasti (napr. okres)? Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni efektivne data v CR dale editovat napric platformami. Pokud tato jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha pracovat s ctvercem o hrane 20km neni az tak neprirozena. Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s Opravdu? Jo. Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. No, ja u prvniho renderovani nebyl. Kdyz jsem se vratil, bylo hotovo, a prvni operace byla zoom. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
No ja jsem se taky nedockal zobrazeni v JOSM... Je nekde k dostani JOSM-ng v jaru? Onehda jsem se to pokousel zbuildovat a nejak mi to neslo... Diky, K Petr Nejedly napsal(a): Pavel Machek napsal(a): Ahoj! 2) a co na to JOSM, jaka bude jeho pouzitelnost v nejakem mensi oblasti (napr. okres)? Tak to si nejsem jisty. Pri nacteni vetsi oblasti ma JOSM docela problemy. Kdyby se to dalo v JOSM nejak filtrovat, bylo by to asi lepsi. *** Nez to uploadnem, mela by existovat jistota, ze budeme schopni efektivne data v CR dale editovat napric platformami. Pokud tato jistota (metoda) nebude, tak bych si nehazel klacky pod nohy. Touha pracovat s ctvercem o hrane 20km neni az tak neprirozena. Vzhledem k tomu ze jsem cely ten import nahral do josm najednou, tak s Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. BTW: josm-ng nahral vpohode, celou CR vyrendroval za ~300ms a moje lokalni, necommitnuta verze maluje i diry v multipolygonech... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) Tomas Kolda napsal(a): Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout. Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) T hanoj writes: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se ke svemu vybranemu kousku dopise. Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval kvuli testovani SemanticWiki. Login tam neni nutny. 2008/8/5 Michal Kovar [EMAIL PROTECTED]: Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) Tomas Kolda napsal(a): Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout. Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) T hanoj writes: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, kdyz to tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad opravi... T Tomas Kolda writes: Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. Klidne bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. Nasel jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi co napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, hromadne to tam muzu dat vzdy http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy T Jiri Klement writes: Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se ke svemu vybranemu kousku dopise. Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval kvuli testovani SemanticWiki. Login tam neni nutny. 2008/8/5 Michal Kovar [EMAIL PROTECTED]: Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) Tomas Kolda napsal(a): Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout. Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) T hanoj writes: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Unika mi pointa tyhle prenatalni kontroly. K cemu to bude? Mista, ktera lidi zajimaji, budou opravena. Mista, na ktere se*e pes muzou zustat tak jak jsou. On Tue, 05 Aug 2008 20:16:54 +0200, Jiri Klement [EMAIL PROTECTED] wrote: Me zase vychazi, ze vetsina lidi pise ze prvne zkontrolovat. Nebo muzeme udelat kompromis, oblasti co si nikdo nevezme za 2 tydny se pak nahraji bez kontroly. 2008/8/5 Tomas Kolda [EMAIL PROTECTED]: Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, kdyz to tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad opravi... T Tomas Kolda writes: Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. Klidne bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. Nasel jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi co napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, hromadne to tam muzu dat vzdy http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy T Jiri Klement writes: Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se ke svemu vybranemu kousku dopise. Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval kvuli testovani SemanticWiki. Login tam neni nutny. 2008/8/5 Michal Kovar [EMAIL PROTECTED]: Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) Tomas Kolda napsal(a): Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout. Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) T hanoj writes: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake problemy, ktere by se pozdeji hure resily. 2008/8/5 Michal Kovar [EMAIL PROTECTED]: Unika mi pointa tyhle prenatalni kontroly. K cemu to bude? Mista, ktera lidi zajimaji, budou opravena. Mista, na ktere se*e pes muzou zustat tak jak jsou. On Tue, 05 Aug 2008 20:16:54 +0200, Jiri Klement [EMAIL PROTECTED] wrote: Me zase vychazi, ze vetsina lidi pise ze prvne zkontrolovat. Nebo muzeme udelat kompromis, oblasti co si nikdo nevezme za 2 tydny se pak nahraji bez kontroly. 2008/8/5 Tomas Kolda [EMAIL PROTECTED]: Aha udelal jsem spatne tag source. Takze musim pregenerovat. Jinak, kdyz to tak pocitam je tu povetsinou psano, ze mam uploadit. Nevim kdo je tu nejvetsi autorita, takze to tam asi zacnu nahravat a pak se to snad opravi... T Tomas Kolda writes: Login do OSM wiki nemam, takze jsem to tam dal a pripsal si cislo 1. Klidne bych s tim nepospichal, ale at je to poradne. Bylo by dobre napr. dat pravidla, ze cesta v lese sirsi nez 15 metru by se mela zachovat atp. Nasel jsem tam i chyby, takze ty by se meli opravit dle ortho. Nebo nekdo vi co napsat do wms pluginu at chodi ty zelene bitmapy? Preci jen bude mnohem jednodussi opravit to ted nez potom... Kdyz nas to nebude bavit, hromadne to tam muzu dat vzdy http://jttt.110mb.com/wiki/index.php/OpenStreetMapLesy T Jiri Klement writes: Jestli tu bude kazdy psat kterou cast si vezme, tak z toho vznikne poradny zmatek. Ja bych dal seznam casti nekam na wiki a kazdy at se ke svemu vybranemu kousku dopise. Nevim jestli vsichni maji login na osm wiki, tak by se treba mohla pouzit wiki na jttt.110mb.com/wiki , kterou jsem si vcera naistaloval kvuli testovani SemanticWiki. Login tam neni nutny. 2008/8/5 Michal Kovar [EMAIL PROTECTED]: Aby z toho nebyl zbytecnej logistickej zmatek. Ja bych to resil jako redneck. Napraskat to na server tak jak to lezi a vcelky delnice si to pak rozeberou :) Uz se na to tesim jak malej fakan na Playstation :) Tomas Kolda napsal(a): Tak posledni dotaz. Vzniklo mi asi 33 souboru velikosti 5MB v OSM formatu. Nechceme pred tim nez se vse posle do OSM soubory rucne poopravit? Zrusit zbytecne cesticky v lesich nebo naopak hodne viditelne osklivosti? Kazdy by si mohl vzdy vzit jeden soubor (napr. poslat email ze zacina delat na 23), vycistit ho a pak uploadnout. Co rikate? Nebo zacinat uploadit... Pockam tak 2 hodky na odpovedi :) T hanoj writes: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list
Re: [Talk-cz] pokusny import lesu
On Tue 2008-08-05 13:03:30, hanoj wrote: Opravdu? Coz o to, nahrat to do josm problem nebyl, SAXu je to jedno a vysledny dataset zabiral kolem 200MB RAM, ale jak doslo na prvni vyrenderovani ve wireframe modu, pocitac funel a funel a stale nebylo hotovo. Dle stacktrace byl asi nejvetsi problem v tom, jak SimplePaintVisitor sestavuje jednu velikou Path2D. MapPaint to same, vyrenderovani jsem se nedockal. *** me se to taky nahrat cele nepovedlo, resp. povedlo ale trvaloto asi 5min a pri zoom to spadlo. Josm s xmx 1024, Pentium 4, Ubutnu 7.10, java 1.5. *** Pavel ma asi neco nejak jinak, ale jeho sdilnost je nevelka. Urcite mam jinou versi josm, a urcite nemam mappaint. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj, takze soubory ke koukani/uploadovani jsou: http://www.web2net.cz/osm/lesy_001.osm.bz2 az 033 Dale jsem zkusil uploadnout 001 (takze ten uz v OSM je). Trvalo to asi 3 hodiny. Napadlo me totiz, ze send je vetsina casu. Pote staci z JOSMu ulozit uz aktualizovana IDcka a muze se v pohode editovat bez stahovani dat (vyzkousel jsem). Takze ten kdo uploadne a nechce se mu editovat chyby nejblizsi dobe, tak by mel ulozit aktualni IDcka a poskytnout je k editaci, aby se jednoduseji ihned opravovalo. Asi to jde nejak vypreparovat z planet.osm, ale to ja nevim jak. Tohle jsou krom toho pouze tyto nove lesy. Muj (jiz neaktualni) send je. lesy_001_send.osm.bz2 Jestli Vas napada lepsi zpusob sem s nim... Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi maximum). T Pavel Machek writes: Ahoj! Me to pripadlo lepsi v tom, ze se odstrani alespon nejkriklavejsi chyby v mistech, ktere nikoho kdo prispiva do osm nezajimaji. Kdyz uz to nikdo nechce alespon zbezne kontrolovat, tak bych alespon pockal alespon den, nez se zacne uploadovat. Treba nekdo objevi nejake problemy, ktere by se pozdeji hure resily. No, co jsem na to koukal tak upload samotny bude trvat vyrazne vic nez den. Urcite by bylo dobry nekam dat .tar.bz2 s tim co se bude uploadovat, a prvni uploadovat nejaky frekventovany misto a zkouknout... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Petr Nejedly napsal(a): Tomas Kolda napsal(a): Tuto sekci si tedy zatim beru na starost a po opraveni hrubych chyb pujdu na dalsi. Vymyslel jste tedy nekdo postup? Mozna by vice lidi ladovalo rychleji, ale ja bych to delal nejmene mesic (3 hodky denne je pro me asi maximum). Vice lidi laduje rychleji, uz jenom proto, ze si pro sebe utrhnou vetsi cast (vic kousku) sdileneho zdroje (OSM databaze), ale take proto, ze kazdy ma cas jine 3 hodiny ;-) Beru si za ukol 015 a cpu to tam... Pekna prace , beru si na upload dily 006, 007. Diky ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Jiri Klement napsal(a): No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany. Myslim ze osmarender to opravdu neresi. Proste renderuje najednou dostatecne velkou dlazdici (+ stahuje o dost vetsi oblast nez chce renderovat) a doufa, ze vetsi les nebude. Na druhou stranu, OSMAPI takhle spatne napsany je Jak se tohle da resit? Napada me sestavit z ways polygon a u kazdeho polygonu ulozit jeho bounding box. Ale uz jenom vytvareni polygonu bude problem, protoze way muze byt jak hranice polygonu tak jenom cara, v zavislosti na tom, jake ma tagy. Ty uvozokvky mely byt spis kolem toho spatne, ale ono je to jeste horsi nez jsem myslel. OSMAPI dokonce nevrati nic ani v pripade, ze pozadam o bbox protnuty cestou, jejiz vsechny nody jsou vne toho bboxu. -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. K P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade pro algoritmus? Tomas Kolda napsal(a): Ahoj, takze generalizovane lesy jsou zde: http://www.web2net.cz/osm/lesy.osm.bz2 naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... http://www.web2net.cz/osm/viewer_080803.zip Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. Statistika: 2.761 multipolygonu 82.160 polygonu 1.605.820 nodu Tak nekdo pls zkouknete a muzem to zacit soupat do osm. T Tomas Kolda writes: Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi neverim Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod 1.5mil bodu s chybou 25 metru se asi nedostanem... T Pavel Machek napsal(a): Ahoj! Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz [EMAIL PROTECTED] wrote: MSVCR80.dll -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
MSVCR80.dll a MSVCP80.dll == fixme:spoolsv:serv_main (0 (nil)) fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for 800a fixme:actctx:parse_depend_manifests Could not find dependent assembly LMicrosoft.VC80.CRT err:module:import_dll Library MSVCR80.dll (which is needed by LC:\\windows\\system32\\MSVCP80.dll) not found err:module:import_dll Library MSVCP80.dll (which is needed by LE:\\Desktop\\viewer\\viewer.exe) not found err:module:import_dll Library MSVCR80.dll (which is needed by LE:\\Desktop\\viewer\\viewer.exe) not found err:module:LdrInitializeThunk Main exe initialization for LE:\\Desktop\\viewer\\viewer.exe failed, status c135 === K Michal Kovar napsal(a): Me ta prohlizecka jede a je ukrutne rychla. Co to chce za knihovnu? On Mon, 04 Aug 2008 11:59:14 +0200, Kubajz [EMAIL PROTECTED] wrote: Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. K P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade pro algoritmus? Tomas Kolda napsal(a): Ahoj, takze generalizovane lesy jsou zde: http://www.web2net.cz/osm/lesy.osm.bz2 naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... http://www.web2net.cz/osm/viewer_080803.zip Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. Statistika: 2.761 multipolygonu 82.160 polygonu 1.605.820 nodu Tak nekdo pls zkouknete a muzem to zacit soupat do osm. T Tomas Kolda writes: Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi neverim Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod 1.5mil bodu s chybou 25 metru se asi nedostanem... T Pavel Machek napsal(a): Ahoj! Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Jeste vecer kdyztak poslu verzi z Mingw, ten ma mnohem mensi zavislosti. Jak to tedka prohlizim, moc se mi nelibi prilisna generalizace nejakych mist. Zkusim to s 12metrovou presnosti, a kdyz bude hezci a vetsi treba jen o 25% tak bych se za ni primluvil... Algoritmus jsem nakonec naimplementoval. Ma slozitost (m*n) a tak i po slusne optimalizaci pocita CR 2 hodiny. T Kubajz writes: Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. K P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade pro algoritmus? Tomas Kolda napsal(a): Ahoj, takze generalizovane lesy jsou zde: http://www.web2net.cz/osm/lesy.osm.bz2 naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... http://www.web2net.cz/osm/viewer_080803.zip Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. Statistika: 2.761 multipolygonu 82.160 polygonu 1.605.820 nodu Tak nekdo pls zkouknete a muzem to zacit soupat do osm. T Tomas Kolda writes: Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi neverim Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod 1.5mil bodu s chybou 25 metru se asi nedostanem... T Pavel Machek napsal(a): Ahoj! Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tak chytry jsem byl taky, ale porad se tomu nechce Neco delam blbe, ale je fakt, ze do wine jsem nikdy poradne nevidel... K Michal Kovar napsal(a): snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz [EMAIL PROTECTED] wrote: MSVCR80.dll ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime knihoven a nainstalovani do systemu. K Michal Kovar napsal(a): snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz [EMAIL PROTECTED] wrote: MSVCR80.dll ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
No rekni, jestli ten spenat mezi silnicema neni sexy! :)) On Mon, 04 Aug 2008 13:09:49 +0200, Kubajz [EMAIL PROTECTED] wrote: Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime knihoven a nainstalovani do systemu. K Michal Kovar napsal(a): snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz [EMAIL PROTECTED] wrote: MSVCR80.dll ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ono nejde o to kam, ale o to, ze kopiruju jen tyhle dve. V tom baliku od M$ je vic souboru, na kterych jsou tyhle dve knihovny zavisle. Michal Kovar napsal(a): Kam ty knihovny kopirujes? :) On Mon, 04 Aug 2008 12:55:56 +0200, Kubajz [EMAIL PROTECTED] wrote: Tak chytry jsem byl taky, ale porad se tomu nechce Neco delam blbe, ale je fakt, ze do wine jsem nikdy poradne nevidel... K Michal Kovar napsal(a): snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz [EMAIL PROTECTED] wrote: MSVCR80.dll ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Toho uz se nekdo rad chopi :) On Mon, 04 Aug 2008 13:24:14 +0200, Kubajz [EMAIL PROTECTED] wrote: Sexy je, ale na muj vkus je moc hrube namletej... Trosku, ale jen nepatrne bych ho zkusil pojemnit. Misty je to opravdu takove otesane. A pak je krasny, jak v UHULu nemaji zaneseny lesy ve vojenskych ujezdech... K Michal Kovar napsal(a): No rekni, jestli ten spenat mezi silnicema neni sexy! :)) On Mon, 04 Aug 2008 13:09:49 +0200, Kubajz [EMAIL PROTECTED] wrote: Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime knihoven a nainstalovani do systemu. K Michal Kovar napsal(a): snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz [EMAIL PROTECTED] wrote: MSVCR80.dll ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Sexy je, ale na muj vkus je moc hrube namletej... Trosku, ale jen nepatrne bych ho zkusil pojemnit. Misty je to opravdu takove otesane. A pak je krasny, jak v UHULu nemaji zaneseny lesy ve vojenskych ujezdech... K Michal Kovar napsal(a): No rekni, jestli ten spenat mezi silnicema neni sexy! :)) On Mon, 04 Aug 2008 13:09:49 +0200, Kubajz [EMAIL PROTECTED] wrote: Aaaa uz to vidim taky - pomoci winetricks se to podarilo snadno... sh ./winetricks vcrun2005 a to zajisti stahnuti distribuce runtime knihoven a nainstalovani do systemu. K Michal Kovar napsal(a): snadna pomoc http://www.dll-files.com/dllindex/dll-files.shtml?msvcr80 http://www.dll-files.com/dllindex/dll-files.shtml?msvcp80 On Mon, 04 Aug 2008 12:16:37 +0200, Kubajz [EMAIL PROTECTED] wrote: MSVCR80.dll ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz __ Informace od NOD32 3301 (20080727) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tomas Kolda napsal(a): Jeste vecer kdyztak poslu verzi z Mingw, ten ma mnohem mensi zavislosti. Jak uz je to OK - vyreseno... to tedka prohlizim, moc se mi nelibi prilisna generalizace nejakych mist. Zkusim to s 12metrovou presnosti, a kdyz bude hezci a vetsi treba jen o 25% Primlouvam se za ni okamzite... Takhle je to hezke, ale rekl bych, ze bychom si to mohli dovolit. tak bych se za ni primluvil... Algoritmus jsem nakonec naimplementoval. Ma slozitost (m*n) a tak i po slusne optimalizaci pocita CR 2 hodiny. T Kubajz writes: Prohlizecku bohuzel nespustim (wine shani nejake knihovny), ale souhlasim s Michalem Kovarem - kde to bude nekoho trapit, tam to nekdo upravi a kde to nikoho trapit nebude, tam to zustane tak, jak to tam je. K P.S.: Diky za namahu. - podarilo se Ti nakonec implmentovat ten upgrade pro algoritmus? Tomas Kolda napsal(a): Ahoj, takze generalizovane lesy jsou zde: http://www.web2net.cz/osm/lesy.osm.bz2 naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... http://www.web2net.cz/osm/viewer_080803.zip Jak jsem zkousel vyzmizikovat ty cesty v lesich, tak to dela obcas chyby. Jinak je to asi o 7% mene nodu. Tohle je bez problemu, mozna bych to tedy pouzil. Kdyz to nekde bude extra osklive, doopravil bych rucne. Statistika: 2.761 multipolygonu 82.160 polygonu 1.605.820 nodu Tak nekdo pls zkouknete a muzem to zacit soupat do osm. T Tomas Kolda writes: Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi neverim Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod 1.5mil bodu s chybou 25 metru se asi nedostanem... T Pavel Machek napsal(a): Ahoj! Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj! takze generalizovane lesy jsou zde: http://www.web2net.cz/osm/lesy.osm.bz2 naimportoval jsem to do prohlizecky at muzete rychle zkouknout (je to ve vyssich zoomech bez generalizace, takze mozna trochu pomalejsi... Vypada to pekne. Naimportoval jsem to do josm (coz chvili trvalo), ale po zazoomovani se s tim pracovat da... tj. s jednotlivymi okresy problem urcite nebude. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj! tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Byl by .osm.bz2? Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Ja jsem silnice importoval normalne josm-kem. Kdyz spadne spojeni, staci znovu zmacknout upload, josm to zvladne. Pruser by asi byl kdyby padl pocitac nebo josm -- coz se mi nastesti neprihodilo. Doporucoval bych velky .OSM rozdelit na takovych 20 dilu, a proste to uploadovat rucne josm... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
On Mon 2008-08-04 23:24:25, Pavel Machek wrote: Ahoj! tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Byl by .osm.bz2? Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Ja jsem silnice importoval normalne josm-kem. Kdyz spadne spojeni, staci znovu zmacknout upload, josm to zvladne. Pruser by asi byl kdyby padl pocitac nebo josm -- coz se mi nastesti neprihodilo. Doporucoval bych velky .OSM rozdelit na takovych 20 dilu, a proste to uploadovat rucne josm... Jo... urcite by bylo dobry pridat nejaky znacky... landuse=forest, source=uhul... a asi i neco k bodum. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Pavel Machek napsal(a): Ahoj! tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Byl by .osm.bz2? Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Ja jsem silnice importoval normalne josm-kem. Coz m.j. znamena generovat zaporna ID. -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Dik za rady. Zaporne idcka mam, otaguju uhulem. Jen to tedy splitnu a zkusim JOSMem vecer naimportovat prvni dvacetinu co to udela. Mam tedy importovat tu druhou variantu? T Petr Nejedly writes: Pavel Machek napsal(a): Ahoj! tak dnes jeste jednou. Udelal jsem generalizaci na 20metru + odstraneni ostrych vycnelku (30stupnu a rozvor max. 50metru). Minimalni plochu jsem urcil na 60x60metru. Jine varianty byly moc bodu... Takto je to: 2.567 multipolygonu 75.940 polygonu 1.747.590 nodu Mne se to opticky zda hezci nez to predesle. Zkuste ohodnotit. Nyni jiz zkompilovane pomoci MINGW, takze snad bez problemu. http://www.web2net.cz/osm/viewer_080804.zip Byl by .osm.bz2? Pak bych potreboval poradit jakym zpusobem uploadovat takove mnozstvi dat. Ma OSM transakce? Mam zaruceno, ze jedna davka, pokud spadne spojeni se rollbackne? Mate nejake zkusenosti, nastroje apod? Staci velky OSM rozdelit po polygonech a pak necim uploadnout? Bude to takto bezpecnejsi? Ja jsem silnice importoval normalne josm-kem. Coz m.j. znamena generovat zaporna ID. -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj! Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Pavel Machek napsal(a): Ahoj! Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany. Na druhou stranu, OSMAPI takhle spatne napsany je *) http://www.openstreetmap.org/?lat=48.49457lon=8.2033zoom=16layers=B00TTF -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. At se propadnu do zapadniho nemecka*, jestli jsou ty renderery takhle spatne napsany. Myslim ze osmarender to opravdu neresi. Proste renderuje najednou dostatecne velkou dlazdici (+ stahuje o dost vetsi oblast nez chce renderovat) a doufa, ze vetsi les nebude. Na druhou stranu, OSMAPI takhle spatne napsany je Jak se tohle da resit? Napada me sestavit z ways polygon a u kazdeho polygonu ulozit jeho bounding box. Ale uz jenom vytvareni polygonu bude problem, protoze way muze byt jak hranice polygonu tak jenom cara, v zavislosti na tom, jake ma tagy. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Jako, ze by renderer neudelal obycejny test na bounding box? Tomu asi neverim Jinak dneska asi uz poslu vystup z generalizace tak muzete zkouknout. Pod 1.5mil bodu s chybou 25 metru se asi nedostanem... T Pavel Machek napsal(a): Ahoj! Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... No... pokud je fakt _obrovska_ tak myslim zacnou problemy. Jako ze rendery nerendruji, protoze nemaji jak zjistit ze dana dlazdice je cela uprostred lesa. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj, aplikoal bych vertex reduction jako soucast DP a DP bych zkusil obohatit o napady z tohoto paperu: http://www.dca.fee.unicamp.br/~ting/Publications/P2001-2005/wu-roci-2003-rfm.pdf coz by znamenalo sehnat jeste jeden, dva algoritmy v pythonu nebo je napsat/konvertovat z jineho jazyka. Slozitost by se vicemene nezvysila a meli bychom jistotu, ze mame neprotinajici se polygony. K Tomas Kolda napsal(a): Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. http://www.web2net.cz/osm/lesy.7z po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri vyrabeni jinych polygonu. Mejte se T Kubajz napsal(a): Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho predesleho pokusu s uhulem. Je to tragedie - duplicitni body, prekryvajici se polygony a tech bodu... K Petr Nejedly napsal(a): [EMAIL PROTECTED] napsal(a): V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me navigace a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. To je zase moje agenda ;-) Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale zeleny ;-) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
V odkazech na konci clanku je jedno pekne url, ktere se zabyva shromazdovanim algoritmu pro geometrii. K Tomas Kolda napsal(a): Paradni publikace, diky za tip. Zkusim to naimplementovat a pak poslu vysledek. Jinak geometricke algoritmy se vzdy hodi, tak jestli znas nejake pekne misto, kde jsou po kupe, dej vedet. T Kubajz napsal(a): Ahoj, aplikoal bych vertex reduction jako soucast DP a DP bych zkusil obohatit o napady z tohoto paperu: http://www.dca.fee.unicamp.br/~ting/Publications/P2001-2005/wu-roci-2003-rfm.pdf coz by znamenalo sehnat jeste jeden, dva algoritmy v pythonu nebo je napsat/konvertovat z jineho jazyka. Slozitost by se vicemene nezvysila a meli bychom jistotu, ze mame neprotinajici se polygony. K Tomas Kolda napsal(a): Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. http://www.web2net.cz/osm/lesy.7z po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri vyrabeni jinych polygonu. Mejte se T Kubajz napsal(a): Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho predesleho pokusu s uhulem. Je to tragedie - duplicitni body, prekryvajici se polygony a tech bodu... K Petr Nejedly napsal(a): [EMAIL PROTECTED] napsal(a): V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me navigace a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. To je zase moje agenda ;-) Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale zeleny ;-) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tak jsem vcera ze srandy zkusil, potracnout celou cr. Akorat jsem blbe pocital, takze cela CR ma 1GB. Potrace si dela vnitrne kopii, takze nez neco zacne pocitat uz je na dvou. Nakonec velmi neusporne uklada vysledne vektory (dostane se tak na 4-5GB RAM). Doma mam bohuzel jen 32 bit stroj, takze koncim tak na max. 1/4 republiky. Zkusim to dneska pustit na 64bit, mozna to nejak procesne. Jako nejvetsi problem asi vidim ty cesticky v lesich. To bude nejvetsi problem pro generalizaci. Polygony se budou muset pospojovat a cesticky nejak odstranit. Je jich docela dost a vektor vypada blbe. T Kubajz napsal(a): [EMAIL PROTECTED] napsal(a): Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne neni o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna neni zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se zbytecne rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma jen 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 bodu. 50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu bude ale problem s dirama. Pokud ma polygon diru, musi se rozseknout sikovne. Coz uz je aspon pro me trochu vyssi divci... V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me navigace a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. jo to je mozny. To nevim... T Ahoj, [EMAIL PROTECTED] napsal(a): Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom zapoti... Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec e-mailu. jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si klidne bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase rozdelovat, ale byly rozdeleny nejak predem. Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. Binding do pythona nepotrebuji - cas behu potrace cas spusteni aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :) No jak myslis. Ja preferuji na tyto prace python, protoze ho precte skoro kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis samozrejmne dal praci studovanim SVG...) ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak se s tim dela, tak to mam jinde hotove... Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel alespon o cem mluvim? stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a sirku a vysku obrazku si nechej 2000
Re: [Talk-cz] pokusny import lesu
Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho predesleho pokusu s uhulem. Je to tragedie - duplicitni body, prekryvajici se polygony a tech bodu... K Petr Nejedly napsal(a): [EMAIL PROTECTED] napsal(a): V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me navigace a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. To je zase moje agenda ;-) Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale zeleny ;-) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tak jsem to pokoril, po par upravach stacilo 1.5GB. Vysledek je zde. http://www.web2net.cz/osm/lesy.7z po rozbaleni je tam python skript, ktery generuje osm. Vygeneruje asi 1.2GB osm soubor. Je to tim, ze je polygon v nejvyssi presnosti, bez uprav. Ze zdrojaku se vycte i format a zpusob zpracovani toho textaku. Do funkce getPolygon se pote musi dopsat pripadna generalizace nebo jakymkoliv jinym toolem. Zkuste si vyriznout par polygonu (staci vnejsi smycku ukoncit napr. po deseti iteracich) a uvidite. Dobre napady na zpusob generalizace vitam. Daji se pak pouzit i pri vyrabeni jinych polygonu. Mejte se T Kubajz napsal(a): Taky argument :) Pockame, co se podari Tomasovi s potracem a pak se uvidi. Dneska jsem zrovna mel v Praze Jinonicich videt kus importu meho predesleho pokusu s uhulem. Je to tragedie - duplicitni body, prekryvajici se polygony a tech bodu... K Petr Nejedly napsal(a): [EMAIL PROTECTED] napsal(a): V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me navigace a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. Kdyz uz tady vsichni odhalujeme svoji agendu :-) tak pro srovnani, nejvetsi polygon v nemecku je les o ~4000 nodech, 30x60km. Neprijde mi to zas tak strasne. A rozhodne bych byl nerad, kdyby se umele rezalo na kusy mensi nez 2-3km. To je zase moje agenda ;-) Pro vysvetleni, pri zobrazovani velkych zoomu v JOSMng filtruju objekty pod 3px (catecne na urovni datovych struktur, zbytek pred renderovanim). A ty 2-3km je tak akorat, aby pohled na celou republiku byl jeste stale zeleny ;-) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby to generovalo malo bodu a bude to. K Kubajz napsal(a): Ahoj, [EMAIL PROTECTED] napsal(a): S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. diky za podporu :) Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? bitmapa T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj, to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o pocet bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy algoritmus. Jestli chces muzu poskytnout python binding na potrace vcetne douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym kodem se pak prozene cela CR a bude hotovo. Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim totiz odpada problem se spojovanim podel tilu apod T Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby to generovalo malo bodu a bude to. K Kubajz napsal(a): Ahoj, [EMAIL PROTECTED] napsal(a): S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. diky za podporu :) Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? bitmapa T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom zapoti... Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Binding do pythona nepotrebuji - cas behu potrace cas spusteni aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :) K [EMAIL PROTECTED] napsal(a): Ahoj, to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o pocet bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy algoritmus. Jestli chces muzu poskytnout python binding na potrace vcetne douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym kodem se pak prozene cela CR a bude hotovo. Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim totiz odpada problem se spojovanim podel tilu apod T Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby to generovalo malo bodu a bude to. K Kubajz napsal(a): Ahoj, [EMAIL PROTECTED] napsal(a): S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. diky za podporu :) Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? bitmapa T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org
Re: [Talk-cz] pokusny import lesu
Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom zapoti... Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si klidne bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... Binding do pythona nepotrebuji - cas behu potrace cas spusteni aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :) No jak myslis. Ja preferuji na tyto prace python, protoze ho precte skoro kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis samozrejmne dal praci studovanim SVG...) Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel alespon o cem mluvim? Dik T K [EMAIL PROTECTED] napsal(a): Ahoj, to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o pocet bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy algoritmus. Jestli chces muzu poskytnout python binding na potrace vcetne douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym kodem se pak prozene cela CR a bude hotovo. Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim totiz odpada problem se spojovanim podel tilu apod T Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby to generovalo malo bodu a bude to. K Kubajz napsal(a): Ahoj, [EMAIL PROTECTED] napsal(a): S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. diky za podporu :) Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? bitmapa T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu
Re: [Talk-cz] pokusny import lesu
Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne neni o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna neni zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se zbytecne rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma jen 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 bodu. V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me navigace a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. T Ahoj, [EMAIL PROTECTED] napsal(a): Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom zapoti... Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec e-mailu. jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si klidne bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase rozdelovat, ale byly rozdeleny nejak predem. Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. Binding do pythona nepotrebuji - cas behu potrace cas spusteni aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :) No jak myslis. Ja preferuji na tyto prace python, protoze ho precte skoro kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis samozrejmne dal praci studovanim SVG...) ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak se s tim dela, tak to mam jinde hotove... Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel alespon o cem mluvim? stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a sirku a vysku obrazku si nechej 2000 http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=Les_OPRLSTYLES=defaultFORMAT=image/pngTRANSPARENT=TRUEBBOX=14.5,50,14.6,50.1WIDTH=2000HEIGHT=2000 Dik T neni zac K K [EMAIL PROTECTED] napsal(a): Ahoj, to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o pocet bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy algoritmus. Jestli chces muzu poskytnout python binding na potrace vcetne douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym kodem se pak prozene cela CR a bude hotovo. Z ceho nakonec generujes? Spojil jsi cele Cechy do jedne bitmapy? Tim totiz odpada problem se spojovanim podel tilu apod T Tak jsem prisel na to, jak se v potracu vypina generovani krivek. Ted uz tedy prevod bitmapy na vektory je zcela trivialni. Musim rict, ze to generuje moc hezke obrazky. Jeste si pohraju s vyladenim parametru, aby to
Re: [Talk-cz] pokusny import lesu
[EMAIL PROTECTED] napsal(a): Uz jsme toho nakecali dost, takze poznamka na zaver. Les samozrejmne neni o velikosti 0.1x0.1, ale lesu, ktere lezi na hranach tilu uz mozna neni zanedbatelne mnozstvi. Muze to byt libovolne maly les, ktery se zbytecne rozsekne. Naopak jak jsem psal, proc vadi stahnout velky les, ktery ma jen 10bodu? Rozsekaval bych jen polygony, ktere maji vice jak napr. 50 bodu. 50 je asi malo, ale rekl bych, ze to nebude spatnej pristup. Trochu bude ale problem s dirama. Pokud ma polygon diru, musi se rozseknout sikovne. Coz uz je aspon pro me trochu vyssi divci... V dusledku je to asi jedno, ale tak nejak pocitove nemam rad sekani po ctvercich. Je to asi dane tim, ze pak data pouzivam do me navigace a kazdy zbytecny zasah do polygonu zvetsuje databazi, index a graficky preprocesing vubec. jo to je mozny. To nevim... T Ahoj, [EMAIL PROTECTED] napsal(a): Zatim jsem delal pouze ten tile 0.1 na 0.1 stupne pri 2000x2000px. Nevim, jak je na tom potrace se zpracovavanim vetsich obrazu a lepit ty dlazdice dohromady mi taky neprijde uplne uzasny, protoze to bude strasne narocny na pamet. Uplne vidim imagemagick, jak se pri tom zapoti... Tohle se prave moc hezky resi tim bindingem, protoze mu uz predhodim jednobitovou bitmapu (nemusim ji generovat). Proste se nactou vsechny tiles pomoci PIL a vytvori obrovskej BLOB, kterej se predhodi potrace (vychazi to kolem 500MB). To, ze se procesor trosku zapoti je myslim to je pouze vstup. Pak potrebujes jeste hafo pameti na samotne zpracovani, ale da se to tak udelat. To samozrejme, ze ano. Pokud budes chtit vsechny dlazdice, tak je to na jeden radek na konzoli. Viz konec e-mailu. jedno. Bude se to delat jen jednou, ale bude to bez chyb spojovani. Spojovani jsem si uz tolikrat uzil a vzdy vznikaly problemy. At si klidne bezi hodinu, ale bez chyb. A za hodinu to ani nenapises... tady by vicemene problemy se spojovanim nevznikaly, protoze me primarne nejde o to, aby se vysledek spojil dohromady. Me jde o to, aby maximalni velikost utvaru v OSM nepresahla 0.1x0.1 stupne. Uz jsem takhle strihal nektere reky, dalnice atp. Stava se totiz, ze si potrebujes stahnout malou vesnicku a kvuli tomu, ze ji proteka reka se ti stahne milion bodu, ktere vubec nepotrebujes. S lesem by to dopadlo uplne stejne. Takze mi primarne slo o to, aby se ty lesy pak nemusely rucne zase rozdelovat, ale byly rozdeleny nejak predem. Udelal bych to po dlazdicich a pri generalizaci atp. bychom slucovali body, ktere budou blizko u sebe. A rozsekane bych ty lesy pak nechal podel tech dlazdic (duvody uz jsem psal minule - treba takove krivoklatsko by se stahlo v podstate cele kdyz by se clovek podival na kousek ulice v Beroune). Jak jsem povidal vyse, spojovani je des. Ohledne sekani podle dlazdic, tak to neni nejlepsi. Vznikaly by zbytecne ctverce. Tobe totiz ani nevadi, ze je area obrovska pokus se sklada z 10 bodu Podle dlazdic Ti naopak budou vznika usekle vycnelky z tilu... zbytecne 4 body tam vnziknou pouze ve velmi malo oblastech. Nevim o uzemi v CR, kde by byl les bez diry na uzemi 0.1x0.1 stupne. Binding do pythona nepotrebuji - cas behu potrace cas spusteni aplikace, takze to prozenu normalne pres prikazovej radek a svgcka pak zpracuju jednoduchym parserem v jave. Dnesek jsem stravil studovanim formatu SVG, abych pochopil, co ty cisilka a pismenka uvnitr znamenaji :) No jak myslis. Ja preferuji na tyto prace python, protoze ho precte skoro kazdej a vyviji se mnohem rychleji. A nemusis studovat SVG ;-). Java je pekna, ale na takove vecicky je asi zbytecna... Krom toho kazdy dalsi mezikrok (meziformat) zvysuje pravdepodobnost chyb v procesu. Kdyz mas moznost ziskat raw data z potrace, nebranil bych se tomu (i kdyz sis samozrejmne dal praci studovanim SVG...) ja ho sice prectu, ale delal jsem v nem tak malo, ze nez nastuduju, jak se s tim dela, tak to mam jinde hotove... Muzes nekam hodit tak 5*5 tilu, ze bych se podival jak vypadaji a vedel alespon o cem mluvim? stahni si, kolik potrebujes, akorat dodrz vzdy rozmer bboxu 0.1x0.1 a sirku a vysku obrazku si nechej 2000 http://geoportal2.uhul.cz/cgi-bin/oprl.asp?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSRS=EPSG:4326LAYERS=Les_OPRLSTYLES=defaultFORMAT=image/pngTRANSPARENT=TRUEBBOX=14.5,50,14.6,50.1WIDTH=2000HEIGHT=2000 Dik T neni zac K K [EMAIL PROTECTED] napsal(a): Ahoj, to je super zprava, ze na tom delas. Mozna bych se vubec nestaral o pocet bodu. Ty se odstrani generalizaci, kde je budes mit vic pod kontrolou. Preci jen do potracove zdrojaky jsou slozitejsi nez jednoduchy algoritmus. Jestli chces muzu poskytnout python binding na potrace vcetne douglas-pluckera. Pak bysme mohli vyseknout rozumne velkou bitmapu (30x30km) a na te zdrojaky odladit ku oblibe cele konference. Vyslednym kodem se pak
Re: [Talk-cz] pokusny import lesu
Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se nasel nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se rekne algoritmus a je to. *** protoze je to tak zasadni rozsireni, kdy je treba najit takovy konsenzus, aby byl optimalizovan prinos pro stavajici i budouci uzivatele geodat osm. Technicky postup a prace je jedna zasluzna cast, dalsi je predhozeni vysledku ku nahledu ostatnim. Historie se nemusi pokazde opakovat. hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
On Sun 2008-07-13 22:04:08, Tomas Kolda wrote: Vubec nechapu proc je kvuli tomu tolik reci a nic se nedeje. Kdyz se nasel nekdo kdo to chce dokoncit tak at to tedy udela s tim, ze se rekne algoritmus a je to. Staci tedy rict co je treba: 1. Spojit vsechny typy lesu do jednoho typu forest (v nejvetsi presnosti) 2. Udelat generalizaci na potrebnou uroven (Douglas-Plucker neni uplne super na polygony). 3. Rozsekat velke polygony na mensi. 4. Zkontrolovat nekolik uzemi a uploadovat. Ja bych mohl pomoci s nekolika vecma. Jen bych potreboval data. Kdyz da nekdo aktualni link kde jsou, pripadne s nejakym popisem formatu (pokud to neni osm) tak bych to klidne udelal. Podle me dokud nekdo nerekne ja to udelam, tak to neudela nikdo. At tedy nekdo rekne, dostane 14 dni a bude vysledek. Pripadne se muzou zapojit ostatni. Zatim data zda-se jsou na: http://kubajz.kbx.cz/junk/uhul/output/ -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Na traceovani bitmap je spousta kvalitniho softu - bohuzel jsem neprisel na to, jak nacpat EPS nebo DXF do OSM. A pritom by to byla tak jednoducha, pekna a cista prace. Editacni funkce a moznosti JOSM jsou v porovnani s profi grafickym softem hrozne primitivni. Kdybych nebyl grafik, asi by me to netrapilo, ale protoze jsem, tak jsem tim desne frustrovanej :) On Mon, 14 Jul 2008 10:49:11 +0200, [EMAIL PROTECTED] wrote: S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz __ Informace od NOD32 3263 (20080711) __ Tato zprava byla proverena antivirovym systemem NOD32. http://www.nod32.cz -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj, [EMAIL PROTECTED] napsal(a): S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. diky za podporu :) Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? bitmapa T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Ahoj, [EMAIL PROTECTED] napsal(a): No dobra muzeme bitmapu. Ono obecne duplicity nevadi, to odstrani mergovani a simplifikace, ale chybejici data by mohl byt problem. Jen mi prijde skoda tahat takovou spoustu dat (bitmapy nejsou zrovna nejuspornejsi). PNG ma mene nez rozbalene XML, ktere leze z WFS, tudiz nemohu souhlasit... Opravdu jsou ty data tak strasne nepouzitelny? Nezna nekdo Ano jsou. Zrovna jsem se dival na cast Krcskeho lesa, kterou importoval Pavel a krome toho, ze lezi v Polabi ma prazvlastni tvar. Se starym WFS byl ten problem, ze daval data pouze v JTSK a musely se prevadet do wgs84, coz pridavalo dalsi stupen mozne chyby, protoze Krovak nebyl v libproj zrovna spolehlive implementovan - lisil se verzi od verze. nekoho v UHULu, aby se zeptal jak se dostat na ten WFS? Vektor je vektor... Bitmapa nam pridava krok 0, zbytek je stejny. Rekl bych ze naopak. Parsovani a tahani nekomprimovaneho XML, prevod do jineho typu souradnic, mergovani je prace navic. Podle meho nazoru ta bitmapa spoustu veci resi elegantnim zpusobem (mergovani, prevod souradnic a prvotni simplifikaci). Navic pro praci se bitmapa snadno vizualizuje, na XML je potreba osmarender, ktery je dost pomaly. T Ahoj, [EMAIL PROTECTED] napsal(a): S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. diky za podporu :) Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? bitmapa T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam budou dvakrat - je to z duvodu toho, ze puvodni WFS pracovalo trochu zvlastne s BB oblasti. Kdyz tam zasahoval jen maly kousek lesa, tak jej nezobrazil a kdyz tam zasahoval vetsi, tak uz jo. A mohlo se stat, ze takhle les zobrazil ve dvou dlazdicich. K Pavel Machek napsal(a): On Sun 2008-07-13 19:00:26, Kubajz wrote: Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... Bohuzel respektovat nazor vetsiny na konferenci (a nemyslim ze to byla vetsina) v tomto pripade znamena nemapovat lesy. A je dost smutny kdyz v praze jsou nakresleny jednotlivy domky v Dejvicich, a pak v ni jaksi chybi Sarecky les. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz ___ Talk-cz mailing list
Re: [Talk-cz] pokusny import lesu
Ahoj, [EMAIL PROTECTED] napsal(a): Tak jo, zkusime tedy ty png. Pokud se tedy do toho nikdo nepusti, tak to klidne nejak zkusim pristi tyden. Jakou budem tahat podrobnost? 1 pixel na ja jsem se do toho pustil, tak mi pockej do konce tydne a predam kdyztak vse, co jsem do te doby vytvoril. V sobotu odjizdim na dovolenou, takze pak 14 dni na tom nebudu moci delat ani nahodou. 5 metru? To by vychazelo tak na priblizne 300x200 tilu po 256x256 pixelu. Poslete mi sem akorat link na ty WMS data at alespon vim odkud pripadne tahat? Muj pripadny postup: 1. Stahnout tiles stahuji z WMS po kroku 0.1 stupne v rozliseni 2000x2000 bodu. To dava prijatelnou presnost a neni to prehnane. 2. Prevest na jednobitovou bitmapu. Mozna by to slo i cele spojit (asi 500MB) 3. Prohnat potracem ale ten vraci krivky. Co s tim dal? Ja bych se klonil k variante bez potrace, pokud neexistuje moznost prehodit ho do rezimu rovnych car. Pokud bychom totiz vzali pouze body a ignorovali ridici body/tecny, tak bychom se dopustili velmi hrube chyby. 4. Vyhodit plochy/diry mensi nez X tech IMO moc neni, ale muze se to udelat. 5. Provest generalizaci (15m chyba) 6. Opravit polygony (self-intersection) z principu nemaji 7. Rozsekat polygony na mensi (max. Y nodu) celkem dobrej napad, na to jsem zatim nepomyslel 8. Poslat jich par ke kontrole urcite :) Spis vsechny. Chyby se projevi casto na specifickych datech a kazdy z nas zkouma trochu jinou oblast CR. 9. Poslat vse omarkovane do OSM asi ano, ale to bych nechal na diskuzi, az to bude hotove. 10. Smazat pripadne uz nakreslene lesy, ktere nemaji mark (mozna rucne zkontrolovat) lesu je ted tak malo, ze je popr. odstranime rucne. Dik T Ahoj, [EMAIL PROTECTED] napsal(a): No dobra muzeme bitmapu. Ono obecne duplicity nevadi, to odstrani mergovani a simplifikace, ale chybejici data by mohl byt problem. Jen mi prijde skoda tahat takovou spoustu dat (bitmapy nejsou zrovna nejuspornejsi). PNG ma mene nez rozbalene XML, ktere leze z WFS, tudiz nemohu souhlasit... Opravdu jsou ty data tak strasne nepouzitelny? Nezna nekdo Ano jsou. Zrovna jsem se dival na cast Krcskeho lesa, kterou importoval Pavel a krome toho, ze lezi v Polabi ma prazvlastni tvar. Se starym WFS byl ten problem, ze daval data pouze v JTSK a musely se prevadet do wgs84, coz pridavalo dalsi stupen mozne chyby, protoze Krovak nebyl v libproj zrovna spolehlive implementovan - lisil se verzi od verze. nekoho v UHULu, aby se zeptal jak se dostat na ten WFS? Vektor je vektor... Bitmapa nam pridava krok 0, zbytek je stejny. Rekl bych ze naopak. Parsovani a tahani nekomprimovaneho XML, prevod do jineho typu souradnic, mergovani je prace navic. Podle meho nazoru ta bitmapa spoustu veci resi elegantnim zpusobem (mergovani, prevod souradnic a prvotni simplifikaci). Navic pro praci se bitmapa snadno vizualizuje, na XML je potreba osmarender, ktery je dost pomaly. T Ahoj, [EMAIL PROTECTED] napsal(a): S tim naprosto souhlasim. Sjednocene typy a zjednodusit na napr. 15m chybu v Douglas-Pluckeru. diky za podporu :) Daji se tedy pouzit ty xml data od Vas? Jestli ne tak se musi rozpoznat nejaka bitmapa z wms serveru uhulu? Pochopil jsem to tak, ze ten vektor jiz na UHUL neni. ta data, co jsem tehdy vytahl z WFS nemuseji byt korektni a trpi spoustou neduhu (napr. duplicity bodu aj.), takze neni dobre z nich vychazet. Na webu jsem je pro jistotu jiz znepristupnil. Uhul ma nejaky problem v nastaveni WFS serveru, takze vktorova data jiz nelze stahnout. Nicmene stale lze stahnout bitmapy pres WMS v pozadovanem rozliseni. Na vektorizaci jsem pouzival potrace na buildup area. Zkousel jsem na potrace jsem narazil dnes asi pred hodinou. Zkusim, co to provede na obrazku z UHUL WMS. Da se mu zabranit v tom, aby vytvarel krivky a misto toho to udelal z usecek (hranate)? vytvorit bitmapu o nejakem rozliseni s tim, ze se na kazdou adresu udelal pixel, blur a vzal pixely s hodnotou vyssi nez neco. Vysledek se prohnal potrace a vzniknul vektor. Bohuzel vysledek se mi nelibil tolik jako rucni vyber, takze jsem od toho nakonec upustil. Hezci bylo vytvorit kolem adresy sestiuhelnik o nejake plose a polygony vektorove zmergovat a simplifikovat pro vyhlazeni zoubku. Pouzival jsem algoritmy popsane v predchozim mejlu. S pouzitim dat z CSU vznikla pekna mapka. Bohuzel asi nejde pouzit kvuli licenci. Ale z UIR by take mozna neco pekneho vzniklo... Jaky je tedy navrh? XML nebo bitmapa? bitmapa T Pokud si to dobre pamatuji, tak nazor byl ano, ale ve zjednodusenem stavu. Preci neni mozne mit tam lesy v rozliseni 5m s rozlisenim poddruhu lesu. Navic jsem zjistil i chybu v puvodni implementaci, ze se muze stat, ze nektere lesy nebudou importovany a nektere lesy tam
Re: [Talk-cz] pokusny import lesu
Ahoj, Kubajz napsal(a): ja jsem se do toho pustil, tak mi pockej do konce tydne a predam kdyztak vse, co jsem do te doby vytvoril. V sobotu odjizdim na dovolenou, takze pak 14 dni na tom nebudu moci delat ani nahodou. Super! Jasne pockam urcite, prace je dost i jinde. Akorat to nejak pak posli do konference at se na tom da pokracovat. Muj pripadny postup: 1. Stahnout tiles stahuji z WMS po kroku 0.1 stupne v rozliseni 2000x2000 bodu. To dava prijatelnou presnost a neni to prehnane. Pokud dobre pocitam tak to rozliseni vychazi priblizne na tech 5m na pixel, takze ok. 2. Prevest na jednobitovou bitmapu. Mozna by to slo i cele spojit (asi 500MB) 3. Prohnat potracem ale ten vraci krivky. Co s tim dal? Ja bych se klonil k variante bez potrace, pokud neexistuje moznost prehodit ho do rezimu rovnych car. Pokud bychom totiz vzali pouze body a ignorovali ridici body/tecny, tak bychom se dopustili velmi hrube chyby. Ja mam zkusenosti s potrace. Je bezproblemovej. Pouzivam binding do pythona, takze se s nim pracuje velmi pohodlne. Krivky se daji bud vypnout nebo je proste zpracovat, to neni problem, protoze simplifikace je vyrusi... Jestli existuje neco lepsiho (lakewalker neznam), tak se holt pouzije neco lepsiho... Pohodlnejsi ale bude zprocesovat to cele jako jedinou obrovskou bitmapu, coz potrace zvladne. Diry samorzejmne umi take. 4. Vyhodit plochy/diry mensi nez X Toto muze byt potreba, protoze vektorizator muze vytvaret malicke polygony jako artefakty tech IMO moc neni, ale muze se to udelat. 5. Provest generalizaci (15m chyba) 6. Opravit polygony (self-intersection) z principu nemaji Jak uz jsem psal. Vadne polygony vznikaji pri generalizaci. Nastava to malokdy, ale nastava. Napr. generalizovat dobre vltavu v praze pro velka meritka je opravdu orisek, jak je videt na nekterych navigacich. 7. Rozsekat polygony na mensi (max. Y nodu) celkem dobrej napad, na to jsem zatim nepomyslel Bud se neco napise nebo se da pouzit CGAL. Ten to nejak ma. Reseni na miru bude mozna lepsi... Zbytek OK. Kdyz budes chtit s necim pomoct, jsem k dispozici. T ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
Re: [Talk-cz] pokusny import lesu
Pavel Machek napsal(a): Ahoj! Importoval jsem okoli klanovic a kus vychodni Prahy... v oblastech je malo lesu a dost jinych dat, takze tech dat nebylo tolik, a Praha se trochu zazelena... Dlazdice jsou vyjmenovany na wiki. Pavel Hm - bylo by celkem dobre respektovat nazor vetsiny na konferenci. Ta data pro jistotu smazu, aby to nekoho nelakalo... ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
