[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=WMS&VERSION=1.1.1&REQUEST=GetMap&SRS=EPSG:4326&LAYERS=Les_OPRL&STYLES=default&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=14.5,50,14.6,50.1&WIDTH=2000&HEIGHT=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 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 >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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