[Talk-cz] pokusny import lesu

Kubajz kubajz na kbx.cz
Čtvrtek Červenec 17 06:39:27 UTC 2008


Ahoj,

Tomas Kolda napsal(a):
> 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,
ja jsem si to myslel, ale nechtel jsem to rozmlouvat...
> mozna to nejak procesne. Jako nejvetsi problem asi vidim ty cesticky v 
> lesich. To bude nejvetsi problem pro generalizaci.
Co zkusit sloucit body,  ktere jsou od sebe vzdaleny mene nez xxx? 
Nepomohlo by to? Popripade by se i rucne nechala upravit ta bitmapa - 
stetcem v gimpu to bude mozna rychlejsi :)
> Polygony se budou muset pospojovat a cesticky nejak odstranit. Je jich 
> docela dost a vektor vypada blbe.

>
> T
>
> Kubajz napsal(a):
>> kolda na web2net.cz 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,
>>>>
>>>> kolda na web2net.cz 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
>>>>>>
>>>>>> kolda na web2net.cz 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,
>>>>>>>>>
>>>>>>>>> kolda na web2net.cz 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 na openstreetmap.org
>>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                   
>>>>>>>>>>>                     
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Talk-cz mailing list
>>>>>>>>>> Talk-cz na openstreetmap.org
>>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                 
>>>>>>>>>>                   
>>>>>>>>> _______________________________________________
>>>>>>>>> Talk-cz mailing list
>>>>>>>>> Talk-cz na openstreetmap.org
>>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>               
>>>>>>>>>                 
>>>>>>>> _______________________________________________
>>>>>>>> Talk-cz mailing list
>>>>>>>> Talk-cz na openstreetmap.org
>>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>             
>>>>>>>>               
>>>>>>> _______________________________________________
>>>>>>> Talk-cz mailing list
>>>>>>> Talk-cz na openstreetmap.org
>>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>>>>
>>>>>>>
>>>>>>>           
>>>>>>>             
>>>>>> _______________________________________________
>>>>>> Talk-cz mailing list
>>>>>> Talk-cz na openstreetmap.org
>>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>>>
>>>>>>
>>>>>>
>>>>>>         
>>>>>>           
>>>>> _______________________________________________
>>>>> Talk-cz mailing list
>>>>> Talk-cz na openstreetmap.org
>>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>>
>>>>>       
>>>>>         
>>>> _______________________________________________
>>>> Talk-cz mailing list
>>>> Talk-cz na openstreetmap.org
>>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>>
>>>>
>>>>     
>>>>       
>>> _______________________________________________
>>> Talk-cz mailing list
>>> Talk-cz na openstreetmap.org
>>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>>   
>>>     
>>
>>
>> _______________________________________________
>> Talk-cz mailing list
>> Talk-cz na openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>>
>>   
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Talk-cz mailing list
> Talk-cz na openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
>   





Další informace o konferenci talk-cz