> 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 >>>>>> 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 >>>>>> [email protected] >>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Talk-cz mailing list >>>>> [email protected] >>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Talk-cz mailing list >>>> [email protected] >>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>>> >>>> >>> _______________________________________________ >>> Talk-cz mailing list >>> [email protected] >>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >>> >>> >>> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> [email protected] >> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz > > _______________________________________________ Talk-cz mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
