ĢISnet » Apmācība

Objektu skaits platības vienībā. Skaitam laukumus.

Māris Nartišs — Tue, 06 Jul 2010 12:11:17 +0000

Objektu skaits platības vienībā ir diezgan izplatīts rādītājs, kas sniedz priekšstatu par lietām un parādībām. Mēs esam pieraduši salīdzināt valstis vadoties pēc iedzīvotāju skaita uz kvadrātkilometru. Topogrāfiskajām kartēm eksistē standarti, kas nosaka cik mērījumu punktiem ir jābūt katrā kartes kvadrātkilometrā. Nosakot dažādas saudzējamas teritorijas viens no kritērijiem ir saudzējamo objektu (augu u.c.) skaits uz platības vienību.
Šie visi gadījumi darbojas ļoti labi, ja objekti ir kā punkti (novērojumu vietas), bet ko darīt, ja skaitāmie objekti ir laukumi? Risinājums liekas tik vienkāršs – saskaitam centroīdu skaitu katrā kvadrātā un gatavs. Bet ko darīt, ja viens laukums var atrasties vairākos kvadrātos? Kuram kvadrātam tad tas tiks pieskaitīts?

Ideja par centroīdu skaitīšanu nebija nemaz tik peļama, vienīgi ir nepieciešams, lai laukumveida objektam būtu pa vienam centroīdam katrā no kvadrātiem, kas tiek izmantoti skaitīšanai. Šādu datu slāni var iegūt veicot divu laukumveida objektu slāņu ģeometriju šķelšanu (intersection). Pēc šķelšanas veikšanas, katrs kvadrātā esošais skaitāmais laukums būs kļuvis par patstāvīgu objektu ar savu centroīdu, kurus tad atliek tik saskaitīt. Tālāk dots piemērs kā to paveikt GRASS vidē izmantojot Spearfish datu paraugkopu.

Vispirms mums ir nepieciešams kilometru tīkls kuru mēs izmantosim skaitīšanai. Sākumpunkts ir brīvi novietots, viena elementa izmērs ir 1000×1000 m.
v.mkgrid map=soil_grid grid=7,9 position=coor coor=595000,4920000 box=1000,1000

Tagad veicam šķelšanu. Rezultējošajā datu kopā būs iekļauti tikai tie objekti, kuri pārklājas datu kopās A un B. Teritorijās, kur gan A, gan B objekti viscaur pārklājās, rezultāts būs identisks kā apvienošanas (union) darbībai.
v.overlay ainput=soil_grid atype=area binput=soils@PERMANENT btype=area output=soil_on_grid operator=and

Tagad mums ir centorīdi, kurus varam skaitīt. Pirms veicam skaitīšanu, nepieciešams iestatīt korektu rastra izšķirtspēju. Visvienkāršāk ir to izdarīt kā pamatu ņemot iepriekš izveidoto tīklu.
g.region vect=soil_grid res=1000
Pašu skaitīšanu ir visvienkāršāk veikt ar r.in.xyz palīdzību. Eksportējam datus ar v.out.ascii palīdzību, kas punktu režīmā eksportēs tikai laukumu centroīdus. Šo eksportu padodam r.in.xyz kā ievadu. Šis triks darbosies labi jebkurā normālā čaulā, savukārt Windows lietotājiem nāksies šo soli veikt divos piegājienos – saglabāt izvadi kā failu un tad ielādēt atkal no tā paša faila. Lai pasākumu padarītu interesantāku, skaitīsim tikai augsni, kuras kods ir “VaB”. Noskaidrot ko šis kods nozīmē, paliek kā mājas darbs lasītājiem pašiem.
v.out.ascii input=soil_on_grid format=point fs='|' dp=2 layer=1 where="b_label='VaB'" | r.in.xyz input=- output=VaB_count method=n

Dažas piezīmes par komandu – v.out.ascii pēc noklusējuma kā atdalītāju izmanto pipe | simbolu, kam ir speciāla nozīmē čaulā – pipe savieno vienas komandas izvadi ar otras komandas ievadi. Šī iemesla dēļ šo simbolu ir nepieciešams ievietot apastrofos, lai čaula ignorētu tā nozīmi. Principā tādēļ, ka fs parametra vērtība pēc noklusējuma jau ir ‘|’, to var arī nenorādīt, taču | nelikšana apastrofos ir pietiekami izplatīta kļūda, lai tai īpaši pievērstu uzmanību.
Ja v.out.ascii nenorādītu atribūtu filtru (where parametrs), tad tiktu skaitīti visi objekti (visas augsnes).
r.in.xyz kā ievades fails ir norādīta mīnusa zīme -, kas nozīmē standarta ievadi (tastatūra, cita programma).

Ja viss ir izdarīts pareizi, rezultātām vajadzētu izskatīties līdzīgi kā parādīts attēlā. Katram tīkla kvadrātam tagad tajā ietilpstošo “VaB” augsnes laukumu skaits ir kā īpašība, ko ir iespējams izmantot vizualizācijā.
Protams, arī šī pieeja nav perfekta – ja viena objekta divi vai vairāki “ragi” ienāk iekš kvadrāta, tie tiks pieskaitīti vairāk kā vienu reizi. To varētu novērst vispirms veicot vaicājumu datu bāzei un atlasot tikai unikālos kvadrātu/objektu daļu pārus.

Koordinātu informācijas pārnešana uz datu bāzi QuantumGIS vidē

Māris Nartišs — Sat, 14 Nov 2009 15:32:27 +0000

Runājot ar vienu QuantumGIS lietotāju, man tika stāstīts, ka QGIS esot labi, taču pietrūkstot tādas vienkāršas lietas, kā ģeometrijas informācijas ielādēšana atribūtu datu tabulā. Pirmā doma izdzirdot šādu vēlmi, bija piedāvāt GRASS ĢIS esošo rīku v.to.db, kas ļauj pārnest daudzus parametrus no vektoriem uz datu bāzi. Ja nepieciešams datu bāzē ielādēt informāciju par poligona platību, kompaktumu, robežas fraktāļa dimensiju, perimetru, līnijas garumu, kategorijai atbilstošo objektu skaitu, objekta koordinātām (līnijām – sākuma vai beigu punktam), līnijas slīpumu, līnijas taisnuma pakāpi vai azimutu, tad nekas cits neatliktu, kā vien ķerties pie “smagās artilērijas”. Tomēr lielai daļai ĢIS programmu lietotāju pietiek ar punktu XY(Z) koordinātām, kas ir nepieciešamas kā ievades informācija kādai no ne-ĢIS modelēšanas programmām. Tā nu izrādās, ka QuantumGIS programmas jaunākajos laidienos iekļautā vektordatu apsrtādes rīku kopa “fRīki” spēj veikt šādu vienkāršu darbību. Tālāk seko īsa vizuāla pamācība kā ielādēt punktu XY informāciju datu bāzē.

Lai ielādētu atribūtu tabulā informāciju par punktu koordinātēm, ir nepieciešams veikt sekojošas darbības:

Pirmkārt ir nepieciešams pievienot jaunam projektam vektordatu slāni, kurš satur interesējošos punktus;

Otrkārt – ja projekta koordinātu sistēma nesakrīt ar ielādētā faila koordinātu sistēmu (pēc noklusējuma tā arī būs), ir nepieciešams norādīt pareizu projekta koordinātu sistēmu, vai arī ieslēgt automātisko pārprojecēšanu;

Trešajā solī ir nepieciešams startēt fTools atbilstošo rīku (Vektori -> Ģeometrijas rīki -> Eksportēt/pievienot ģeometrijas kolonnas);

Izvēlamies vektordatu slāni, kurš mūs interesē. Norādam kur saglabāt rezultējošo failu. Iedarbinam rīku ar “Labi” podziņu. Tas arī viss. Ja visas darbības tika veiktas pareizi, tad vajadzētu būt izveidotam jaunam vektordatu slānim (Shapefile), kura atribūtu tabula satur punktu X un Y vērtības.

Atliek tik pārliecināties, ka atribūtu tabula satur divas jaunas kolonas ar X un Y vērtībām.

Grāmatas #1

Pēteris Brūns — Fri, 03 Apr 2009 05:47:13 +0000

Ikdienā par tehniskām lietām un to pielietojumu nākas lasīt interneta plašumos, tomēr reizēm paņemt rokā grāmatu, iespējams, ir pat efektīvāk nekā blisināties ekrānā. Nu jau kādu laiku atpakaļ saņēmu divas pasūtītās grāmatas – viena klasificējam kā bilžu grāmata un vieglā lasāmviela, otrā jau vairāk no smagā gala. Abas grāmatas labi pārstāv aprakstītās nozares lietas un ir orientētas praktiķiem, abām grāmatām ir internetā pieejami aprakstīto piemēru dati un koda gabali, lai katrs var darboties līdz un pārbaudīt lietas praksē. Protams literatūrā aprakstītā programmatūra arī ir brīvi pieejama. Te nu būs neliels, subjektīvs ieskats abās grāmatās.

Desktop GIS: Mapping the Planet with Open Source Tools by Gary E. Sherman

Man šī grāmata nedaudz atgādināja tādu kā soli pa solim ievadu ĢIS lietās un kartogrāfijā, pie tam ar bezmaksas rīkiem. Slinks pasniedzējs varētu pat pamatus mācīt 1:1 no šīs grāmatas, jo grāmatā apskatītās lietas ir viegli sportiskā ievada līmenī. Zinot lokālās studentu īpatnības, kvorumam, šīs grāmatas saturs būtu smagā viela visiem bakalaura studiju gadiem, kaut apskatītas ir tikai pamat lietas. Visus gan jābrīdina – grāmata satur jau dažas vēsturiskas lietas (piem. QGIS jau ir mainījies), bet kopumā grāmatas lietderību tas nemazina, vienīgi var mazliet mulsināt. Grāmatā apskatītas zināmākās atvērtā koda ĢIS aplikācijas (QGIS, uDig, gvSIG, gdal/ogr, GRASS GIS u.c.). Grāmatas tēmu klāsts sākas no ievada ĢIS datos un to formātos/konvertācijās, datu apstrādē (geoprocessing) līdz vienkāršiem aprakstiem par savu aplikāciju veidošanu grāmatā apskatītajām programmām. Diezgan daudz tiek apskatīta datu transformācija starp koordinātu sistēmām. Un pavisam nejauši atklājām, ka ar šo grāmatu var dižoties arī Māris, jo grāmatā ir viņa izstrādātā GRASS GIS spraudņa pielietošanas piemērs.

Applied Spatial Data Analysis with R

Šī ir grāmata no Use R sērijas. Par šo grāmatu šķiet man ir lielākais prieks. Sāku lasīt un, ziniet, nevar ne atrauties, jo uzrakstīta valodā, kas tā vien velk dziļāk. Pats trakākais, ka šīs lasāmvielas iespaidā jau sāku apdomāt vēl dažu šīs sērijas grāmatu pasūtināšanu, lai labāk varētu orientēties R plašumos. Grāmata orientēta uz publiku, kura ir labi pazīstama ar iepriekš aprakstītajā grāmatā apskatītajām pamat lietām, turklāt ir nojēga par to, ko viņi gribētu darīt ar viņu rīcībā esošiem datiem. Lasāmviela un rīks esošiem vai topošiem spēka lietotājiem, kuriem ar masu aplikāciju standarta funkcijām telpisko datu analīzē ir kļuvis par īsu vai daži esošie komerciālie rīki uzliek šaubu ēnu iegūtajiem rezultātiem. Izpratne par statistikas pamat lietām ir diezgan stipri vēlama un var atvieglot lasīšanas un tēmas apgūšanas tempus, jo terminoloģija reizēm ir gana specifiska. (Grāmata, kuru iespējams negribēšu laist ārā no redzes loka).

Jā, es zinu, ir pilns internets ar veiklām pamācībām un citiem dokumentiem, bet ar tiem nevar nosist mušu.

Iepazīšanās ar OSSIM

Jānis Jātnieks — Wed, 04 Mar 2009 21:29:46 +0000

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.

Telpisko datu digitālā apstrāde

Pēteris Brūns — Thu, 26 Feb 2009 06:59:17 +0000

Nesen pamanījām apmeklētājus no Kārļa Kalvišķa vadītā kursa “Telpisko datu digitālā apstrāde” lapas . Smuki apkopots materiāls par ĢIS un kartogrāfijas pamatlietām latviešu valodā. No šī kuras lapas var paceļot arī tālāk pa Latvijas Universitātes Bioloģijas fakultātes resursiem, kuros ir apkopota daudz un dažāda informāciju par kartogrāfiju, ĢIS un ĢIS aplikācijām. Resurs, kurā var paceļot laikā, apmaldīties un atrast labas lietas ;)

Te būs mazs izgriezums no kursa ceļveža:

Mērķa sasniegšanai studenti pēc teorētisko zināšanu iegūšanas tiek apmācīti veikt datu ievadi, apstrādi un analīzi izmantojot tam atbilstošu programnodrošinājumu. Kursa ietvaros tiks izmantota brīvi lietojamā programmatūra, līdz ar to visus uzdevumus būs iespējams pildīt pie jebkura pieejama datora. Brīvo programmu lietošana sekmē iegūto iemaņu pielietojamību pēc studiju beigšanas.

Iepazīsti kaimiņus

Pēteris Brūns — Thu, 14 Aug 2008 09:17:19 +0000

Vector1 ir ieraksts par pieejamajiem Krievijas datiem. Brīvi ir pieejami diezgan apjomīgi dati par Krieviju ArcInfo formātā. Labi izmantojami kā mācību meteriāls, vispārīgai pētniecībai un pārskatu karšu gatavošanai, jo satur diezgan plaša rakstura datus par Krievijas teritoriju (reljefs, klimats, veģetācija, augsnes un citas datu kopas).

Špikeri

Pēteris Brūns — Mon, 30 Jun 2008 08:54:52 +0000

Reti kurš atceras visas aplikāciju komandas un funkcijas, reizēm arī dokumentāciju lāga nevar sprast aiz slinkuma vai pirkstu līkuma. Tādēļ lieti noder fiksās piezīmes ar piemēriem, kurus pēc vajadzības pielabojot var lietot ar ctrl+c un ctrl+v metodi vai vismaz saprast kā kas darāms. Markus Neteler ir uzrakstījis disvus špikerīšus par gadal un ogr lietošanu. Nedzudz jau iepriekš bija dažas mūsu pašu piezīmes par datu pārprojicēšanu/stumdīšanu un maskēšanu, kas vairāk orientētas uz lokalajām īpatnībam un vajadzībām.

Karšu zīmēšana ar zīmuļiem

Māris Nartišs — Sun, 15 Jun 2008 07:11:49 +0000

Tā nu reiz ir sanācis, ka pašlaik savu tiešo pienākumu pildīšanas laikā sanāk mācīt studentiem zīmēt tematiskās kartes. Viesis, kas bija ieradies palūkāt kā studenti apgūst prakstiskās zināšanas lauka apstākļos, bija izbrīnīts, ka studenti kartes taisa analogā veidā – ar roku zīmē uz pauspapīra un iekrāso ar parastajiem zīmuļiem. Tas man kārtējo reizi lika aizdomāties par daļā mūsdienu sabiedrības valdošo pāroptimistisko attieksmi pret tehnoloģijām. Skarbā patiesība ir tāda, ka modernas tehnoloģijas nerisina mūsu problēmas. Jaunu datoru un dārgas programmatūras iegāde nedos gaidīto rezultātu, ja vien nebūs cilvēks, kas prot to likt lietā. Šajā gadījumā ar vārdiem “likt lietā” netiek domātas tās prasmes, kuras, diemžēl, tiek tik plaši iedresētas skolās un augstskolās, kur studenti iemācās vispirms spiest uz “šīs pogas” un pēctam uz “tās”. Reaģēšana uz noteiktu kairinājumu noteiktā veidā labāk iederas Pavlova suņiem nevis cilvēkiem, kuri vēlāk izliekas par savas nozares speciālistiem. Svarīgākais ir spēt atbildēt uz jautājumu “kapēc” nevis “kā”. Kamēr tehnoloģija tiks turēta augstāk par ideju, tikmēr rezultāti būs tādi, kādi tie ir. Labāk lai studenti zīmē kartes ar zīmuļiem, kas ir ne tikai vieglāk un ātrāk, bet arī krietni pamācošāk, jo uzmanība tiek koncentrēta uz saturu nevis instrumentiem un formu, nekā kļūst par Pavlova suņiem.

Padomājis par šo visu, es viesim norādīju, ka šajā gadījumā pats process ir svarīgāks par rezultātu. Un viņš tapa apskaidrots.

Atvērto ĢIS aplikāciju spēju salīdzinājums

Pēteris Brūns — Thu, 20 Mar 2008 09:15:49 +0000

Stefan Steiniger ir uztaisījis feinu salīdzinajumu un pārskata tabulu par atvērta koda Desktop ĢIS aplikāciju spējām un iespējām. Lieti noderēs tiem, kas neko no tā nezin vai balstās uz ticamākiem un mazāk ticamiem nostāstiem un sāgām. Tiem, kas šīs aplikācijas ir lietojuši nekā jauna nebūs, pārējiem gan būtu vērts iepzīties. Jebkurā gadījuma labs informācijas apkopojums salīdzināšanai.
Īpaši derīgs tiem fantastiem, kas cer ka izslavetajā GRASS GIS varēs zīmēt ūber kartes un atrisinās visas dzīves problēmas. Pirms izvēlēties aplikāciju iepzīstieties ar tās sniegtajām iespējām un noskaidrojiet vai šīs iespējas atbilst jūsu prasībām, lai pēc pirmajiem izmeiģinājumiem nevietā nav jāspļaudās.

Lietojam ĢISnet WMS servisus ar QGIS 0.9

Māris Nartišs — Wed, 27 Feb 2008 17:31:59 +0000

Dažu iepriekšējo rakstu komentāros atsevišķi personāži izteica neapmierinātību ar savu neprasmi izmantot ĢISnet piedāvātos WMS servisus. Lai šo problēmu labotu, piedāvājam noskatīties ekrānfilmiņu, kurā ir parādīts kā izmantot ĢISnet topogrāfisko karšu WMS servisu ar QuantumGIS programmas palīdzību.
Filmiņā ir redzams kā pievienot ĢISnet topogrāfisko karšu servisu pie QGIS pieejamo WMS servisu saraksta, kā izvēlēties interesējošos karšu slāņus un kā noteikt ezera platību, par pamatu ņemot topogrāfisko karti mērogā 1:50’000. Filmiņas tapšanā ir izmantota QGIS 0.9.2 programmas testēšanas versija. Filmiņa ir Ogg formātā izmantojot Theora video datu kompresijas tehnoloģiju. Filmiņas izmērs ir 16 Mb. Spied te, lai skatītos.