[Talk-cz] pokusny import lesu
Kubajz
kubajz na kbx.cz
Středa Červenec 16 13:28:36 UTC 2008
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
>
Další informace o konferenci talk-cz