[Talk-cz] pokusny import lesu

Středa Červenec 16 13:08:51 UTC 2008

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,
>
> 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
>
>