ĢISnet

Tuvāk iepazīties ar OSSIM piespieda vajadzība – saskāros ar (kārtējo) problēmu ArcGIS rastra apstrādes dzinējā (droši vien tajā, kurš pakaroties parasti braši sauc sevi par “erdas.c”). Tomēr šoreiz gan šis darbu it kā paveica, pat ja nepieklājīgi ilgā laikā, tomēr ne tā kā biju cerējis…

Bija nepieciešams savienot kopā vienā mozaīkā 26 tifus, kuri, kā jau pēc skaita var noprast, atbilda Latvijas rajoniem un bija izgriezti no kādas vecu karšu čupiņas. Problēma tā, ka šīs vecās kartes vietām bija tik greizas, ka tām nebija iespējams nogriezt liekās malas līdz ar rajona robežu, jo robežas vienkārši nebija (ar roku) tik precīzi iezīmētas. Nolēmu griezt viņām visu apkārt ar 200m buferi. Tas savukārt nozīmēja, ka lai pēc tam šādus “buferainus” rajonus samontētu vienā lielā Latviju pārsedzošā mozaīkā, būtu nepieciešams malas sablendēt, tā lai pārejas no viena rajonu uz otru būtu pēc iespējas mazāk vizuāli mokošas. Šī operācija ArcGIS producēja rezultātu, kas nepārprotami liecināja par rastra dzinēja nespēju sablendēt neregulāras malas un norādīja uz tieksmi visas darbības veikt pa paliela izmēra kvadrantiem, pie viena nerespektējot norādīto nodata vērtību. Šīs mozaīkas zināmu negatīvu emociju uzplūdā izdzēsu, tādēļ diemžēl nav ko ielikt parādīt:( Neveikli, bet atkārtot šo kļūdu radīšanas rituālu vairāku stundu garumā, lai pievienotu šim rakstam, man tomēr nebija pacietības.

Rezultātā nolēmu, ka jau sen bija laiks izmēģināt ossim piedāvātās visnotaļ interesantās iespējas, jo uzmetot aci viņu dokumentācijas (un reizē arī promocijas:)  materiāliem dažādu rastru malu smuka sapludināšana bija palikusi atmiņā kā viena no OSSIM stiprajām funkcijām.

Tiem, kas vēl nekad nav dzirdējuši par OSSIM ir vērts ielūkoties pēc smukiem piemēriem šeit – mozīkošana, rektifikācija, blendēšana, rastra algebra, koreģistrācija un citas rastra apstrādes lietas GIS un tālizpētes vajadzībām ir šīs programmas stiprā puse – gan tīri “metriskiem” gan kosmētiskiem darbiem. Tāds man bija palicis iespaids, līdz atdūros pret problēmu.

Pēc imagelinker instalācijas atvēru visus failus un attiecīgi izvēlējos tos savienot ar feather mozaīkošanas metodi… kas tos visus smuki sablenderēja vienā lielā čupā, nepārprotami norādot man, ka kaut kas nav kārtībā ar telpisko piesaisti.

Lasot dokumentāciju, gudrāks netiku, jo pēc tās varēja noprast, ka viss ir lieliski – OSSIM saprot ģeoreferencējumu gan ar World failiem (TFW) gan ar GeoTIFF galveni (header). Tomēr realitātē izskatījās, ka tā tomēr nav – pārbaudīju abus variantus un tikpat nesekmīgi. OSSIM pašu izmantoto .geom failu pielabošana arī nedeva neko tuvu tam ko vajadzētu un pēc dažādām īpatnībām liecināja, ka to būtība ir tuvāka WKT vai *.prj failu idejai. Dažādu listserveru pārmeklēšana arī neliecināja, ka kādam būtu bijušas jebkādas, vērā ņememas, problēmas ar ģeoreferencējuma izmantošanu šajās programmās. Vienīgais, kas pastāvīgi liecināja par to, ka kaut kas nav pareizi, bija tas, ka imagelinker uzstāja uz koordinātu rādīšanu grādos nevis taisnleņķa vienībās… Sākumā pieņēmu, ka tā ir koordinātu attēlojuma īpatnība, jo paļāvos uz to kas it kā rakstīts dokumentācijā.

Pēc pāris dienām veicot citus darbus ar gdal_translate pamanīju ko agrāk neredzētu GeoTIFF galvenes ierakstā. Vai nu nebiju to agrāk ievērojis, vai arī šī bija tieši jaunajai GDAL 1.6.0 versijai raksturīga iezīme – ierakstot GeoTIFFā koordinātu sistēmas definīciju (wkt veidā) un tai atbilstošās koordinātas rastra ģeoreferencējumam, blakus bija ierakstītas arī to ekvivalentās ģeogrāfiskās koordinātas WGS84 sistēmā. Un tik tiešām – palaižot  imagelinker un mēģinot atvērt failus ar šāda veida ierakstiem GeoTIFF galvenē, to atrašanās vieta tika atpazīta korekti un to savienošana mozaīkā un malu blendēšana notika tieši tā kā vajadzīgs.

Ossim feather mosiac piemērs - 3 rajonu robežu satikšanās vieta

Ņemot vērā, ka oriģinālās kartes zīmētas ar roku un to ievilkšana nebūt nebija ne vienkārša, ne arī rezultātā uzskatāma par precīzu (cik nu ar roku zīmētas šāda mēroga kartes var tikt vispār uzskatītas par precīzu), kā arī dažādās papīra krāsas u.c. faktorus, tad iegūtais rezultāts šķiet tīri labs.

Nozīmīgākais secinājums – OSSIM strādā tikai ar grādīgām koordinātām.

Ja dati ir taisnleņķa koordinātās kā biežāk lietotās LKS-92 variācijas, tad tos var veiksmīgi atvērt izlaižot caur gdal_translate ar -a_srs ESRI::lks92.prj vai līdzīgu parametru, izmantojot jaunāko GDAL versiju.

Tā piemēram, ja ir tif fails kuram ir koordinātas rakstītas pavadošajā TFW failā, vai arī GeoTIFF galvenē (bet bez sistēmas definīcijas un ģeogrāfiskajām), tad padarīt šādu failu lasāmu iekš OSSIM var ļoti vienkārši:

gdal_translate -a_srs ESRI::lks92.prj D:\originali\fails.tif D:\prieks_ossim\fails.tif

Šajā piemērā izmantoto lks92.prj failu var iegūt paņemot no kāda shp faila, ar vēlamo koordinātu sistēmas variantu, un pārsaucot to pavadošo prj failu. Var arī norādīt ceļu uz to “pa taisno”. Aiz -a_srs protams var lietot arī EPSG:3059 kodu vai arī ceļnorādi uz normālu WKT failu, bez “ESRI::” priedēkļa, atbilstoši gdal_translate komandlīnijas sintaksei.

Kopumā šī komandrinda izskatās pat pārāk ikdienišķa, bet ir svarīgi atcerēties, ka telpiskā piesaiste ar TFW failiem nedarbosies, ja vien to vienības nebūs grādos. Ieraksti GeoTIFF galvenē ar taisnleņķa koordinātām derēs tikai tad, ja papildus korektam koordinātu sistēmas aprakstam un kontrolpunktu vai rastra stūru (un parasti arī centra) koordinātām šajā sistēmā, blakus būs to ekvivalenti ģeogrāfiskajās koordinātās. Tas ir tas ko OSSIM tur grib redzēt.

Piedāvāju divus GeoTIFF headeru paraugus, no kuriem viens derēs priekš OSSIM un otrs ne.

NEDERĪGS:
===================
Files: Cesu_raj.tif
Size is 5394, 4329
Coordinate System is `’
Origin = (544323.930160628630000,6378822.251804904100000)
Pixel Size = (17.103548917954736,-17.103548917954736)
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  544323.930, 6378822.252)
Lower Left  (  544323.930, 6304780.989)
Upper Right (  636580.473, 6378822.252)
Lower Right (  636580.473, 6304780.989)
Center      (  590452.202, 6341801.620)
Band 1 Block=5394×1 Type=Byte, ColorInterp=Red
Band 2 Block=5394×1 Type=Byte, ColorInterp=Green
Band 3 Block=5394×1 Type=Byte, ColorInterp=Blue

DERĪGS:
===================
Driver: GTiff/GeoTIFF
Files: Cesu_raj.tif
Size is 5229, 4120
Coordinate System is:
PROJCS[“GRS_1980_Transverse_Mercator”,
GEOGCS[“GCS_GRS_1980”,
DATUM[“unknown”,
SPHEROID[“unnamed”,6378137,298.2572221010002]],
PRIMEM[“Greenwich”,0],
UNIT[“degree”,0.0174532925199433]],
PROJECTION[“Transverse_Mercator”],
PARAMETER[“latitude_of_origin”,0],
PARAMETER[“central_meridian”,24],
PARAMETER[“scale_factor”,0.9996],
PARAMETER[“false_easting”,500000],
PARAMETER[“false_northing”,0],
UNIT[“metre”,1,
AUTHORITY[“EPSG”,”9001″]]]
GeoTransform =
544323.9301606286, 17.0819490198102, 0.7130616081995298
6375166.605759162, 0.699109972412019, -17.08278689995598
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (  544323.930, 6375166.606) ( 24d44’23.77″E, 57d31’0.77″N)
Lower Left  (  547261.744, 6304785.524) ( 24d46’32.18″E, 56d53’3.83″N)
Upper Right (  633645.442, 6378822.252) ( 26d13’55.90″E, 57d31’55.76″N)
Lower Right (  636583.255, 6308441.170) ( 26d14’33.19″E, 56d53’58.29″N)
Center      (  590453.593, 6341803.888) ( 25d29’51.12″E, 57d12’37.54″N)
Band 1 Block=5229×1 Type=Byte, ColorInterp=Red
NoData Value=0
Metadata:
LAYER_TYPE=athematic
Band 2 Block=5229×1 Type=Byte, ColorInterp=Green
NoData Value=0
Metadata:
LAYER_TYPE=athematic
Band 3 Block=5229×1 Type=Byte, ColorInterp=Blue
NoData Value=0
Metadata:
LAYER_TYPE=athematic

No šiem piemēriem var secināt vienu ļoti nozīmīgu lietu – ģeoreferencējums ar “plikām” taisnleņķa koordinātām nav ģeoreferencējums OSSIM izpratnē. Un tas, principā, ir ļoti ļoti pareizi. Taču droši neesmu vienīgais, kas risinot šāda rakstura problēmas šad tad rīkojies pēc principa – ka tik darbojas, par to cik tieši korekta ir telpiskā piesaiste un koordinātu sistēmas definīcija (un vai tāda ir vispār) uztraukšos vēlāk. Šī nu ir laba mācība citreiz tā nedomāt – ceru ka noderēs arī citiem:)

Vēl dažas atziņas par OSSIM lietošanu.

Jāatzīst, ka, līdzīgi kā ArcGIS, arī OSSIM šai gadījumā nerespektēja nodata definīciju 255 (balts fons). Nācās visu pārdzīt uz melnu… tas diemžēl nozīmē ne tikai nodata definīciju (kas būtu sīkums), bet arī reālos krāsu pikseļus failos. Par laimi OSSIM par to jau ir padomāts un to var ātri un diezgan vienkārši izdarīt ar pixelflip utilītu, kas nāk kopā ar imagelinker instalāciju. Pēc tam atliek tikai pārdefinēt nodata (uz 0 – melns).

Gala produkta eksportēšanā noder atcerēties, ka pirms to uzsāk ir svarīgi pietuvināt to līdz “full resolution” un tikai tad mēģināt saglabāt citādi rezultāts būs tikpat maziņš kā uz to brīdi ekrānā apskatāmā pārskata bildīte. OSSIM diezgan burtiski uztver šādas lietas, kas citās programmās tiktu uztvertas tikai kā šobrīdējais skats. Tas nozīmē arī, ka resampleris (kurus OSSIM piedāvā ļoti plašā klāstā) ir jāizvēlas pirms gala produkta eksportēšanas, citādi var sanākt vilties ieraugot, ka rezultāts resamplēts ar kaut ko patiesi atbaidošu, piemēram, nearest neighbour.

Visumā varu teikt, ka iespaids par imagelinker ir pozitīvs. Ir, protams, arī dažas īpatnības. Kā daudzām programmām ir vienkārši lietas ko ir labāk zināt – korekta koordinātu sistēmas definīcija un grādīgās koordinātās; melns nodata; WYSIWYG pieeja eksprotēšanai.

Tāpat arī šķiet, ka OSSIM ļoti uzstājīgi defaultējas uz WGS84 elipsoīdu papildus grādīgajām koordinātām. Tā kā OSSIM pamatā esošā tehnoloģija tika radīta masveidīgai satelītu uzņēmumu apstrādei militārām vajadzībām 90to gadu sākumā, tad tas principā nav nekāds pārsteigums, bet ir labi to neizmirst – īpaši pārbaudot gala produktu un tā koordinātu sistēmas aprakstu. Tas vienmēr būs eksportēts ar WGS84 referencelipsoīdu koordinātu sistēmas definīcijā, neskatoties uz to ka oriģinālam sistēmas definīcija būs bijusi atšķirīga. Tādēļ, ja vēlaties uzturēt korektu koordinātu sistēmu gala datiem, kas ir visnotaļ saprātīgi, tad gala produktu var nākties reprojicēt.

Patiesībā OSSIM vēsture ir tīri interesanta lasāmviela.

Pozitīvi liekas tas, ka programmas uzbūve konceptuāli ir ļoti vienkārša, bet piedāvā veikt ļoti ļoti noderīgas darbības, dara to ātri (lai neteiktu momentā) un rada iespaidu par ļoti stabilu rastra apstrādes dzinēja bāzi uz kuru tas viss balstās. Manuprāt milzīga priekšrocība ir tas, ka piemēram, mozaīku veidošanas rezultātu var apskatīties uzreiz pēc funkcijas izvēles un fragmentu atzīmēšanas. Rezultātu var apskatīt, pabīdīt, novērtēt savienojumu vietas, pamainīt resamplerus un tikai tad, kad rezultāts apmiemrina, uzsākt gala produkta eksportēšanu. Šī, principā ir killer fīča priekš mozaīkošanas, īpaši jau attiecībā pret risinājumiem, kas prasa uzstādīt visus parametrus pirms darba sākšanas, pēc tam nezcik dienas/stundas kaut ko dara un tad vēl nākas secināt – eh rezultāts nav gluži tāds kā vajag, un sākt atkal ar mazliet citiem parametriem. Un tas ir tad ja uzdevums tiek paveikts nepakaroties. Šādā kontekstā OSSIM ir lielisks rīks.

Lai saprastu ko tieši var paveikt ar OSSIM ir visnotaļ vērts ieskatīties dokumentācijas sadaļā. No šīs sadaļas man patika video piemērs par equation editor, kas lieliski demonstrē rastra dzinēja iespējas. Baltas krāsas nomaiņai uz melnu lieti noderēja command line utilities dokumentācija. Taču katrs darbs jau ir savādāks un katram derēs kas cits.

Birkas: OSSIM, raster data

Autors - Jānis Jātnieks. Šis ieraksts tika ievietots 2009. gada 4. marts, 23:29 kategorijā Apmācība, Programmatūra, Viedoklis . Jūs varat sekot šī ieraksta komentāriem izmantojot RSS 2.0 barotni. Komentēt vai trackback no savas lapas.