|  |  | | Olomouc ortho 6. 7. 2002 / 13:39 | |
| | Zdravím všechny létavce. Jak už jsem uvizoval, podařilo se mi sehnat kompletní Olomouc, včetně orthomapy, výškových souřadnic a ulic ve vektorech. To samé mám pro Tábor. Vše v měřítku 1:5000. Velikost orthomapy pro Olomouc je cca 250 MB. Na ukázku tu mám jeden shot (kvůli velikosti zmenšeno na 1/2). Nemá někdo se zkušenostmi ve vytváření orthomap zájem o ten Tábor?
 |
| |
|
 |  | | | Re: Olomouc ortho 6. 7. 2002 / 21:37 | Jirka Prokeš |
| | | Jak daleko jsi s Olomoucí? Já mám letiště tak na 25% hotové. Pak přijde na řadu okolí. |
| |
|
 |  | | | | Re: Re: Olomouc ortho 7. 7. 2002 / 09:52 | |
| | Já osobně bych dělal asi jen ortho. Letitě můžeš klidně udělat ty .... Když bude hezké ...
Jinak ta orthomapa je v měřítku cca 35-40 cm/pix a má velikost zhruba 235 MB! |
| |
|
| | | | | | Re: Re: Re: Olomouc ortho 7. 7. 2002 / 11:20 | Marky Parky |
| | Ze vas to bere hazet do vzduchu takovyhle nicotny cisla.
CR nagenerovana na zaklade satelitnich snimku 10m/pix bude mit 3Giga a to bude teprve stahovani  ))))))))
Ale jinak jen do toho. A v souvislosti s timhle me napada jedna vec.
Ortofotopraha od petra bednare ma okraje dodelavane tak, aby pekne zapadla do defaultni krajiny. Jenze kdyz behem sveho testovani delam se ctvercem kolem Berouna a Plzenske dalnice, tyhle okraje najednou naopak prekazi. Chtelo by se tedy nejak domluvit jak s timto nalozit, nez zacnete se zbytecnou Photoshopovou drinou.
Predpokladam totiz, ze tyhle mesta budou v layerech nad pripadnou foto CR, aby ji doplnili tam, kde neni ( a ni nemuze byt ) dost presna.
|
| |
|
| | | |  | | | Re: Re: Re: Re: Olomouc ortho 7. 7. 2002 / 12:25 | |
| | No co se týče ztahování 3GB, to mě taky nebere. Pro mě osobně to není problém, ale jsem jeden z mála.
K tomu přidávání přechodů do default textur FSka: mě se default textura krajně nelíbí a tak jenom čekám kdy už se budu dívat na něco přirozenějšího ... Já osobně bych přechody nepřidával. |
| |
|
| | | | | | | Re: Re: Re: Re: Olomouc ortho 7. 7. 2002 / 12:38 | |
| | | kdyz se u vysledneho souboru s texturou napriklad 011221333233132Su.bmp s velikosti 43762 B a rozmery pixlu (4,0 - 4,2) x 4,8 m odstrani zakladni obrazek s rozmerem 256 a necha se tam jen rada mipmap od 128 niz, vznikne soubor s velikosti 10994 B. FS pak znazornuje pri nejvetsim priblizeni pixly (8,0 - 8,4) x 9,6 m, coz presnym leteckym snimkum samozrejme hodne ublizi, ale tem druzicovejm by mozna ani nemuselo? Rozmer druzicoveho snimku CR pro FS2002 by se zmensil z 3 GB pod 1 GB. Moc jem to nezkousel, mam problem, ze u tech textur 128x128 mi zatim nejak nechce fungovat fs2k2 voda, ale na nejake dulezite misto je vyzdycky mozne vratit puvodne vytvoreny kvadrant 256x256? |
| |
|
| | | | | | | | Re: Re: Re: Re: Re: Olomouc ortho 7. 7. 2002 / 13:31 | Marky Parky |
| | Je to super napad, ale aby tam nebylo nejake uskali. Takze mi prosim zkus neco vysvetlit, mozna tomu nerozumim.
Protoze ty satelitni snimky maji presnost 10m/pixel, zmenil jsem si .INF soubor takhle:
CellXDimensionDeg = 0.000147058824
CellYDimensionDeg = 0.000090909090
Takze by me zajimala jedna vec.
Ten ctverec 256x256 ma konstatni velikost vuci zemepisnym souradnicim nebo vuci rozliseni textury?
Konkretni priklad: Kdyz dam texturu 512x512 s rozlisenim 10m/pixel tak po resamplovani s vyse uvedenym nastavenim dostanu 4 textury 256x256 v rozliseni 10m/pixel nebo 16 textur 256x256 v rozliseni 5m/pixel kvuli LOD13???
Pokud je to ten prvni pripad, neusetrime nic, pokud ten druhy, usetrime 2Giga a je to super napad..... no a republiku rozdelenou do 10 casti po 100 mega uz nebude problem odsosat. Snad.
|
| |
|
| | | | | | | | | Re: Re: Re: Re: Re: Re: Olomouc ortho 7. 7. 2002 / 17:46 | |
| | resampler by nageneroval 3 GB, nadelat z tech 43 kB texturek ty hrubsi 11 kB by se muselo nejak automaticky, ja jsem to zatim zkousel jen rucne v Imagetool pro par kvadrantu, coz by ale pro 60 tisic kousku delat rucne neslo.
Pixl 10 m ma uhlove rozmery na poledniku 0.00008983 a na rovnobezce totez lomeno cos(lat), tj. napriklad pro 50. rovnobezku 0.00013975. Soucasny resampler obecne bere vstupni data z matic, kde v radcich jsou body na rovnobezkach a ve sloupcich body na polednikach elipsoidu WGS84.
Mapy a ortofotomapy jsou v rovinnych projekcich, kde pri pohledu na vetsi plochu je patrna konvergence poledniku smerem k severu a vyklenuti rovnobezek uprostred mapy smerem dolu, takze presnejsi by bylo takovy obrazek napred v nejakem grafickem programu pretransformovat tak, aby se z poledniku staly svisle rovnobezne cary a z rovnobezek vodorovne rovnobezne cary.
U takhle upraveneho obrazku pak plati CellDimensions presne pro celou plochu, a proc je pritom rovnou neudelat presne pro LOD12? (CellDimensions 120/2^20; 90/2^20). Resampler by to sice presne dvakrat zahustil, protoze u typu vstupnich dat Custom dela jedine LOD13, ale tim dodatecnym vynechanim zbytecneho nejvetsiho obrazku 256x256 a posunutim mipmapy 128x128 nahoru by se to zase vratilo nazpatek. Ale nevim, jestli by to takhle mohlo fungovat bez vetsich uskali, to by se muselo vyzkouset.
Jinak ten automaticky generovany autogen na druhou vypada fakt skvele! Jaka je vlastne vnitrni struktura tech anotacnich souboru, je to nekde popsane?
Diky, Vlada |
| |
|
| | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 8. 7. 2002 / 00:18 | Marky Parky |
| | Hlavicka:
Longint - hustota 1-2 patra
Longint - hustota 3-5 patra
Longint - hustota 6-8 patra
Longint - hustota 9-12 patra
Longint - pocet domu
Longint - pocet bloku vegetace
Longint - unknown
Longint - unknown
Longint - typ prvnich stromu
Longint - typ druhych stromu
Longint - pomerne zastoupeni druhu stormu
Longint - hustota zalesneni
Single - sirka prvnich stromu
Single - vyska prvnich stromu
Single - sirka druhych stromu
Single - vyska druhych stromu
Pote okamzite nasleduji jednotlive zaznamy tolikrat, kolik je ulozeno v hlavicce
Domky:
Single - prvni roh souradnice X
Single - prvni roh souradnice Y
Single - vektor prvni strany souradnice X
Single - vektor prvni strany souradnice Y
Single - delka
Single - sirka
Vegetace:
Single - prvni roh souradnice X
Single - prvni roh souradnice Y
Single - delka
Single - sirka
Vysvetlivny por nepascalisty:
Longint - 4 byte signed integer
Single - 4 byte real ( float )
Co se tyka promenych single, tak souradnice se urci tak, ze cele sirce bitmapy odpovidat delka 1 a souradnice 0,0 jsou uprostred bitmapy.
Nazorne:
souradnice v pixelech / souradnice agn
[0,0] / [-0.5,-0.5]
[127,127] / [0,0]
[255,255] / [0.5,0.5]
A nazorne zapis pro vegetaci - ctverec s rohy
[ 0,0 ][ 128,0 ][ 128,256 ][ 256,0 ]
bude zapsan jako
-0.5;-0.5;0.5;1;
dum o souradnicich
[ 0,0 ][ 128,0 ][ 128,256 ][ 256,0 ]
bude zapsan jako
-0.5;-0.5;1;0;0.5;1;
a dum o souradnicich
[ 128,0 ][ 256,128 ][ 128,256 ][ 0,128 ]
bude zapsan ( priblizne ) jako
0;-0.5;1;1;0.7;0.7
Myslim ze je to pochopitelne pro kohokoliv, kdo by na zaklade toho chtel programovat treba lepsi editor nez je ten mrkvosofti ( alespon aby nepadal ), ja se spokojim s autoautogen utilitkou.
|
| |
|
| | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 8. 7. 2002 / 22:22 | |
| | Super! Jeste se v tom editoru mluvi taky o moznosti natahnout pro domecky jine nez defaultni textury a pouzit defaultni vegetaci bez urceni dvojice druhu stromecku, to by tam taky nekde melo figurovat. Ja nemam ambice pro tohle neco programovat, jen me zajimalo, jak daleko je poznani v tomhle smeru. Mozna v CFS3 budou uz tri druhy stromecku (a v 2k4 logicky ctyri).
Jinak spatna zprava pro moznost pouziti redukovanych satelitnich textur 128x128 soubezne s kvalitnimi leteckymi 256x256 - zda se mi, ze pri nastaveni Terrain Texture Size na "High" to chce 256x256, a ty redukovane to neukazuje uplne dobre (nekdy misto nich default textury nebo jen cerne ctverce) a v nastaveni na "Medium" to sice ukazuje ty male soubory 128x128 dobre, jenze pak i ze sousednich neosizenych textur 256 to ukazuje asi jenom mipmapu 128, no ale mozna se mylim a je to jinak.
Velke diky za vysvetleni te struktury a preju peknou dovolenou daleko od pocitace!
Vlada Stoje |
| |
|
| | | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 12. 7. 2002 / 10:19 | Marky Parky |
| | Co se tyka dovolene, tak abstak uz byl silnejsi nez laska k prirode, takze jsem se pripojil v kavarne. Jo a pocitac sebou mam, chybi jen internet .....
Ty redukovane textury - je to skoda. Chtelo by to mozna rozbehat LOD12, pak bychom dosahli stejneho zmenseni. Opravdu to nejde??? Beee
Momentalne pracuju na updatu kde budou dvojice 3 pressetu, ktere se budou moci rychle naklikavat k prislusne texture.
Bude to "vesnice", "mesto", "sidliste"
a "listnace", "smisene",¨"jehlicnany" + samozrejme custom nastaveni.
Az se vratim, budu to uz mit odladene, takze nabidnu.
Nevim jestli jsem to psal, ale stavajici verze by mela byt jako beta k dispozici na flightsim.periskop.cz/autoautogen.zip |
| |
|
| | | | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 14. 7. 2002 / 20:08 | |
| | mam dojem ze LOD12 v 2k2 asi zatim nejde, aspon ne klasicky a tak, aby vedle nej byl zaroven videt i LOD13. Navrzeny nahradni zpusob s texturkami 128x128 jsem uz skusil i pro Prahu VFR pomoci prevodu v davkach, tj. napred pomoci imagetool -batch do bmp, pak pomoci PictureTry do 515 obrazku 128x128 a pak znovu pomoci imagetool do dxt1, vznikly soubory velike 11 kB, dohromady to ma 5 MB. U mne na TNT2 to pri TerrainTexture Size "High" blbne, ale na "Medium" to funguje dobre i s autogenama. Tenhle pokus nikomu nedoporucuju, pri pohledu zblizka dolu je to samozrejme hodne znat, kdyz se pixly zvetsi z 5 na 10 m.
Popsany princip by ale pripadne bylo mozny pouzit pro druzicove snimky napriklad tak, ze pokud by pri jejich zpracovani nevznikly detaily pod 10 m, v archivech pro download by mohly byt textury 128x128 s velikosti 11 kB a teprve pri instalaci by se zvetsily na 256x256 s velikosti 43 kB, tak aby to pak fungovalo soubezne s naplno znazornovanymi leteckymi snimky v Terrain texture Size "High".
U automatickeho generovani autogenu se jenom sklanim v hlubokem obdivu, vubec tomu nerozumim, jak automaticky ve fotografiich vyhodnotit domecky a lesiky, ktere je navic potreba nahradit dostatecne malym poctem obdelniku, to jsou nejake figly pocitacove grafiky a automatickeho vyhodnocovani obrazu? Je to moc zajimavy, jsem zvedav, jak ta utilitka autoautogen bude fungovat!
Vlada Stoje |
| |
|
| | | | | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 15. 7. 2002 / 10:04 | Marky Parky |
| | Mno uz jsem se o necem podobnem bavil s Petrem Bednarem na Pivu v souvislosti s night a winter texturama pro Prahu.
Slo o to, ze nas napadlo nedistribuovat balik 6ti verzi textur velkej 100 MB, ale distribuovat balik 3 textur ( summer, night a hardwinter ) a ty zbyle rozkopirovat prave nejakym prilozenym batchem.
No a soucasne s tim mne napadly dve veci.
a) Textury muzeme distribuovat presne jak rikas 128x128 a pridat k nim treba SW verzi AlchemyWorkhsopu a bat, kterej je roztahne a pak prekonvertuje roztazene do DXT
b) Nejenom stahnout textury na 128x128, ale muzem je distrubuovat jako JPEG, myslim, ze ztrata kvality nebude viditelna vzhledem ke snizeni objemu dat.
Jo a prosimte jeste mi vysvetli.
Proc je v kazdem navodu a resamplovani nejake hledani leveho horniho rohu LOD13 ctverce????
Pouzil jsem nasedujici postup:
a) odectu z tech satelitnich snimku presnou zem. delku a sirku leveho horniho rohu.
b) napisu ji do INF soubouru
c) do INF souboru dam velikost cele mapy bez nejakeho orezavani
d) do INF souboru dam velikost pixelu spocitanou na zaklade souradnic vynesenych v tom staelitnim snimku.
e) perfektve to ve FS licuje, kontroloval jsem to ve slew modu ve FSce
Jinak vyhodnotit z fotografie automaticky domecky a stromy snad zatim nedokaze ani NASA, ale finta je v tom, ze nevyhodnocuju tu fotku, ale presne nalicovanou mapu, na ktere jsou prave jen domecky a oblasti vegetace. Celou 256x256 bitmapu mam rozdelenou na 64x64 ctvercu a v kazdem znich vyhodnocuju pocet zelenych pixelu. Tim vytvorim docela dost presny les.
S domkama je to slozitejsi, ted jsem ve stadiu, ze na zaklade mnozstvi sedych pixelu a uhlu, ktery svira seda s bilou nagenerovat nejakou jakous takou zastavbu, ovsem presna analyza bude jeste fuska.
|
| |
|
| | | | | | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 15. 7. 2002 / 18:44 | |
| | v navodech k resampleru asi byla vetsinou snaha zjednodusit definovani rozsahu vystupu rozsahem vstupu (UseSourceDimensions = 1), a tihle "perfekcionisti" (ahoj vsichni!) chteji mit mermomoci ve svych vecech absolutni poradek, proto dokonce orezavaji zdrojove fotky presne na hranice vystupnich kvadrantu LOD13. Je to podle mne tak jak pises, kdyz se fotka neoreze, vykroji si z ni v takovem pripade resampler vsechny plne pokryte kvadranty sam. Taky je snad mozne zadat UseSourceDimensions = 0 (to je default) a pro definovani rozsahu vystupu napsat do Destination napriklad
NorthLat = 50.09
SouthLat = 50.06
WestLong = 14.39
EastLong = 14.43,
cimz by se teoreticky mely nagenerovat i z velikanske fotky Prahy jenom ctyri texturky kolem Karlova mostu, ktere jsou v uvedenych velmi pribliznych hranicich cele obsazeny.
Komprimovani fototextur asi nepujde moc prehanet za hranici uchovani kvality obrazku, nakonec kazdy zajemce i s pripojenim pres modem si najde cestu, jak se ke stovkam MB dostat, pokud ale jde neco hodne zkomprimovat bez znatelne ztraty kvality, hodi se to vzdycky. To vypada zajimave co jste vymysleli s Petrem Bednarem na Pivu!
S autoautogeny to je fakt super napad, diky moc za vysvetleni, tesim se na dalsi vyvoj!
Vlada Stoje |
| |
|
| | | | | | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 16. 7. 2002 / 12:09 | Rudy |
| | Stale si myslim, ze algoritmy resampleru ani zdaleka nedosahuji kvalit napr. Photoshopu. Proto to "udelejsisamamejtopodkontrolou"  |
| |
|
| | | | | | | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 16. 7. 2002 / 18:08 | Marky Parky |
| | Mas samozrejme pravdu.
Na druhou stranu karta pri vykreslovani da te texture tak "na frak", ze ten rozdil asi viditelny nebude. Zvlast pri prepisu 10m/pix do LOD13. ( Opacne by to asi znat bylo ).
|
| |
|
| | | | | | | | | | | | | | | | | Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Olomouc ortho 17. 7. 2002 / 06:36 | Rudy |
| | | Mas pravdu, ale je to asi tak, jako gdyz pojedeme z A do B kazdej jinou cestou a mozna i jynym dopravnim prostredkem. Vysledek je stejnej, oba jsme tam, kde chteli, ne? |
| |
|
| | | | Re: Olomouc ortho 10. 7. 2002 / 12:19 | Karel |
| | Cus Jirko ja bych si tu Orto foto tabora vzal. Zatim delam sice na
LKSO,ale az dokoncim vrhl bych se na ten Tabor... Jak je to velke.
Muzes mi to hodit na FTP,nebo to muzu nasosat pres ICQ ,nebo volis
radeji osobni kontakt a CD. Jsem jeste tak do konce tydne v Praze.
Pak ti budu asi pristi cvrtek. Pak uz asi mesic ne...Cus
Karel
|
| |
|
|
