Pirmkārt laikam jau ir jāsāk ar to, ka jānoskaidro kas tad īsti ir “trace tool”. ArcView 10.0 pie datu rediģēšanas rīkiem ir pieejams “trace” rīks, ar ko tiek saprasta iespēja atkārtot kāda jau esoša objekta (līnijas, laukuma) daļu kā jaunveidojamā objekta daļu – t.i. zīmējot izmantot jau esošās līnijas. Inkscape un citās zīmēšanas programmās savukārt ar “trace” saprot rastra attēla objektu kontūru automātisku vai pusautomātisku vektorizēšanu. Savukārt manis iepriekš paustais komentārs ArcGIS vidē ir attiecināms uz “Freehand” rīku, kas “trasē” “zīmuļa” pārvietošanos brīvā telpā, t.i. nesekojot esošiem objektiem.

Ja kādam vēl ir šaubas, vai brīvās zīmēšanas (freehand) rīks ir ļaunums, piedāvāju aplūkot zemāk redzamos ekrānattēlus no ArcView vides. Kā redzams attēla kreisajā pusē, brīvās zīmēšanas rīks ļauj veidot skaistas līnijas, taču, ieslēdzot virsotņu rediģēšanas rīku, ir saprotams kā tas tiek panākts, jo kļūst redzams liels skaits virsotņu, kas tiek izmantotas līnijas atveidošanai. Ja skaistas līnijas pašas par sevi nav noziegums (jo kartogrāfija taču ir māksla!), tad te uzreiz ir jāatceras šādas pieejas ēnas puses – katra virsotne nozīmē koordinātu pāri datu failā (izmērs!). Otra būtiska ēnas puse atklājas tad, ja mēģina šādu “smuko” līniju rediģēt – labajā pusē ir redzams cik daudzas virsotnes (zaļie klucīši) ir jāpārvieto, jādzēš, lai mainītu šīs līnijas izskatu. Te nu ir vietā jautājums – kas svarīgāks – skaists izskats vai datu lietojamība. Šāds brīvās zīmēšanas rīks pagaidām QuantumGIS programmā nav pieejams un tas arī ir tas, ko es personīgi centīšos nepieļaut, ka tāds tur tiek ieviests.

Kas attiecas uz “trace” rīku, tad te pašlaik QuantumGIS standarta rīkkopā nekā līdzīga nav un tādēļ nav ko salīdzināt. Tomēr gan ArcView, gan QGIS satur vēl kādu instrumentu, kas var būt noderīgs zīmējot laukumveida objektus. ArcView vidē meklējams ir rīks ar nosaukumu “Auto Complete Polygon”, kas ļauj zīmēt tikai poligonu ārējo robežu, savukārt robežas, kas ir kopīgas ar jau esošiem poligoniem, tiek zīmētas automātiski. Lai lietotu šo rīku, zīmēšana ir jāsāk un jābeidz kāda no eksistējošo poligonu iekšpusē. QuantumGIS savukārt šāda pati funkctionalitāte nav izdalīta atsevišķi, bet ir pieejama, ja aktivizē laukumu nepārklāšanās opciju. To var izdarīt dodoties uz “Iestatījumi” -> “Pielipšanas iespējas” un atķeksējot atbilstošā slāņa nosaukumu, kā tas parādīts attēlā. Kad laukumu nepārklāšanās ir aktivizēta, atliek tik zīmēt jaunus laukumus ar pierastajiem rīkiem (attēlā pa kreisi) un QuantumGIS programma automātiski tos pārveidos tā, lai tie aizņemtu tikai brīvo telpu (attēlā pa labi). Gluži tā pat kā ArcView gadījumā, arī QGIS būs automātiski izzīmējis kopīgās laukumu robežas tā, lai tās perfekti sakristu. Ņemot vērā, ka nepārklājošu laukumu zīmēšana ir, iespējams, lielākā motivācija trasēšanas rīka lietošanai, iespējams, ka bez atsevišķa objektu trasēšanas rīka QGIS vidē vismaz daļēji ir iespējams iztikt.

Pirmais solis datu konvertēšanā bija datu ievade teksta formāta failā, ko var paveikt ar jebkuru teksta redaktoru, piem. vi (MS-Windows lietotāji – Notepad). Pirmais mēģinājums – ievadam datus formātā “X,Y” un mēģinam rezulātu nolasīt ar QuantumGIS.
Pirmais pārsteigums – kamdēļ dati nesakrīt ar ĢISnet karšu servisā esošajām kartēm? Ak, atkal jau jādzied ārija no Sešu miljonu operas par to, ka MK noteikumos dati netiek doti Latvijas oficiālajā koordinātu sistēmā LKS-92 TM. Tiklīdz ko punktiem tika pateikts, ka tie ir ETRS-89/Baltic 93 TM koordinātu sistēmā, tā tie iekrita pareizā vietā.

Punkti ir jauki – bet kā tikt pie laukumiem? Izrādās, ka mūsdienās tas ir pavisam vienkārši – atliek tik instalēt jaunu QGIS Python spraudni “Poinsts2One”, kas pārvērš punktu sarakstu par laukuma robežu. Svarīgi – ir jānorāda jaunveidojamā Shapefile atribūtu kodējums pat tad, ja atrībūtu dati netiek veidoti (jau izlabota QGIS kļūda). Derīgs kodējums ir, piem., UTF-8. Tas arī viss.

Protams, būtu jau jauki, ja tas viss būtu tik vienkārši. Aplūkojot iegūto rezultātu, ir redzams, ka iegūtie laukumi ir bojāti. Aplūkojot tuvāk MK noteikumu pielikuma tabulu, var pamanīt, ka ir atsevišķi laukumi bez to numuriem un jebkādiem citiem paskaidrojumiem. Acīmredzot ar to ir domāts kodēt laukumos esošos caurumus. Atliek vien pielabot teksta ievades failu, lai tas kaut kādā veidā kodētu caurumus, kurus tad vēlāk varētu izgriezt no lielajiem laukumiem.
Protams, caurumus vēl varētu izskaust, taču aplūkojot tuvāk daļu no “vienkāršajiem” laukumiem, nākas secināt, ka virsotņu kārtas numuri nav īsti pēc kārtas, piemēram, 122 virsotne atrodas starp 113 un 114 virsotni. Rezultātā automātiski ģenerētie laukumi sanāk nepareizi. Diemžēl šo problēmu nav iespējams risināt automātiski, jo sarežģītākas ģeometrijas gadījumā, pat cilvēkam nav uzreiz saprotams kā laukumam būtu jāizskatās pareizi.

Tā, protams, nav vienīgā šo datu problēma – izejas dati nav topoloģiski korekti – dažādu teritoriju laukumi savā starpā pārklājas, kā arī atstāj pa vidu dažus metrus platas joslas, kuras NAV iekļautas aizsargājamajās teritorijās. Šādi dati parasti tiek rādīti ĢIS studentiem pamata studiju līmenī, kad tiek skaidrots par topoloģijas nozīmi “skaidu” novēršanā ĢIS datos. Ja metru platas joslas vēl ir iespējams izskaidrot ar netopoloģisku virsotņu koordinātu noapaļošanu līdz veseliem metriem, tad sešu metru un lielākas atšķirības tādā veidā nav izskaidrojamas, kas norāda uz nekvalitatīviem izejas datiem.

Nobeiguma vietā.
Varbūt kādam var rasties jautājums – “Nu par ko Jūs tur cepaties? Visiem tādi sīkumi taču ir vienalga…” Te nu nākas atzīt, ka lielākajai daļai tas tiešām ir “pie kājas”, taču šī ir viena no lielākajām Latvijas problēmām ne tikai ĢIS/kartogrāfijas lauciņā. Protams, pāri paliek ĢIS/kartogrāfijas eksperti, kā arī tie, kurus šādi neprecīzi noteikumi ietekmē visvairāk – zemju īpašnieki, kuru darbības ierobežo šajos (un līdzīgos) MK noteikumos nospraustās neprecīzās robežas. Ja kļūda ir maziņa, piem. zonas pārklājas par “nieka” 10 m, tad uz kopējo malas garumu, kas šajos datos atrodamajā piemērā bija 2,5 km, tas jau veido 2,5 ha. Kā tad īsti aprēķināt nodokļus, kompensācijas šiem 2,5 ha? Precīzās robežas taču tiek noteiktas pēc MK noteikumiem, ne? Un tas ir tikai viena mala vienam no laukumu pāriem. Kā šādos gadījumos piemēro LATVIJAS REPUBLIKAS LIKUMU Par īpaši aizsargājamām dabas teritorijām 29.pantu?

Lai arī šādu zonu robežu publicēšana uzrādot koordināšu pārus ir uzskatāma par apsveicamu un pareizu pašreizējā izpildījumā pietrūkst informācijas un metodikas par šo datu viennozīmīgu un pareizu interpretāciju, kas var radīt iepriekš uzdotos jautājumus.
Aplūkojot citus apstiprinātos šāda tipa dokumentus nākas secināt, ka ir pilnīgi brīva interpretācija jau pašā dabas liegumu noteikšanā un to robežas apstiprināšanā. Tas pilnīgi noteikti neliecina par vienotu sitēmu jau pašā saknē, jo nav nekāda standartizācija vai vienotas sistēmas apstiprinatajos dokumentos.

Daži piemēri, kurus nemēģinājām pārvērst ĢIS datos, bet uzmetām šķelmīgo skatienu.
Ministru kabineta noteikumi Nr.478 “Dabas lieguma “Sedas purvs” individuālie aizsardzības un izmantošanas noteikumi” – ar līdzīgiem datiem, kas tika analizēti Lubānas mitrāja gadījumā, koordinātes, protams, ETRS-89/Baltic 93 TM. Šis gan varētu būt labāks gadījums, jo ir īpaši uzsvērts, ka dotas “ārējo robežu koordinātas”.

Ministru kabineta noteikumi Nr.394 “Dabas lieguma “Pāvilostas pelēkā kāpa” individuālie aizsardzības un izmantošanas noteikumi” – uzskates shēma nav ieturēta labākajās padomju tradīcijās – ir pieejams koordinātu tīkls. Ņemot vērā, ka tiek norādīts, ka tā ir shēma koordinātes varētu nebūt.

Ministru kabineta noteikumi Nr.114 “Dabas lieguma “Liepājas ezers” individuālie aizsardzības un izmantošanas noteikumi” – acīmredzot 2000. gadā vēl mērniecības metodes nebija attīstījušās pietiekami, lai varētu noskaidrot robežas virsotņu koordinātas un tādēļ tās ir dotas formā “uz ziemeļiem no resnās priedes”.

Ministru kabineta noteikumi Nr.326 “Dabas lieguma “Lielupes palienes pļavas” individuālie aizsardzības un izmantošanas noteikumi” – kuros, kā izskatās, Sezonas lieguma robežas koordinātu pāriem, salīdzinājumā ar pārējo zonu pāriem, tiek jauktas X un Y vērtības vietām.

Tiem, kuriem ir vēlme paspēlēties ar iegūtajiem Lubānas mitrāja failiem, te tie būs visā savā greizumā:
Lubānas mitrāja robežas Shapefile formātā

Labprāt gaidīsim nozares ekspertu un skarto personu viedokli komentāros.

Gala secinājumi tiem, kam slinkums lasīt tālāk:

• LMT izsnedz USB modemu Huawei E1752 ar vecu programmatūru (firmware) un tādēļ nav iespējams uzreiz sākt tos lietot uz GNU/Linux vai MacOS X datoriem. Saņemot modemu, paprasiet, lai atjaunina modema programmatūru (firmware).
• LMT palīdzības dienests ir kaut ko dzirdējis par GNU/Linux, taču viņi zin tikai Ubuntu un arī tikai esošā priekšraksta līmenī. Iespēja saņemt no distributīva neatkarīgu informāciju (konfigurācijas parametrus utml.) nav. Pirms došanās laukā, savienojums ir jāizveido vietā, kur ir pieejams internets un Gūgles tantes palīdzība.
• Savienojuma ātrums ārpus pilsētām, kur tas ir visvairāk nepieciešams, ir ~127 kilobiti sekundē, kas nodrošina datu lejupielādi ar ātrumu līdz 16 kB/s (0,14 Mb/s pēc Speedtest.net). Augšupielāde, protams, ir daudz lēnāka – ~86 kilobiti sekundē, kas dod līdz 10 kB/s (0,09 Mb/s pēc Speedtest.net).
• Lai arī iezvanīšanās programma pppd ne reizi darba laikā neatvienojās, savienojums brīžiem neeksistēja, ko varēja labi novērot pie failu lejupielādes vai mājaslapu neatvēršanās ar pirmo reizi.
• WMS servisus ir iespējams lietot, taču jārēķinās, ka kartes skata pārzīmēšana aizņem aptuveni divas minūtes. Ja savienojums pazūd, gaidīt var nākties vēl ilgāk, kā arī jārēķinās ar nepieciešamību vaicājumu atkārtot. Arī SCP darbojas, SSH lietošanu gan apgrūtina salīdzinoši lielā aizture.
• LMT izsniegtā aparatūra nav diezko stabila, jo pēc 49,4 minūšu lietošanas, modems nomira ar “SIM failure” kļūdas paziņojumu un vairs nebija atdzīvināms.

Testu veikšanai tika izmantots LMT dotais USB modems Huawei E1752 (12d1:1446 un 12d1:1001). Testam tika izmantots AMD64 dators ar 2.4 GHz procesoru, 4Gb operatīvās atmiņas, ko darbināja pats jaunākais Gentoo Linux (~AMD64 izmantojot 2.6.36 kerneli). Testu veikšanas vieta – 20 km attālu no Limbažiem esošs ciems, kur vadu tālruņu līniju vairs nav kā sugas.

Pati iekārta ir paliela USB datu nesēja izmēros ar uzdrukātu LMT logo. Komplektā nāk “Īsā pamācība” latviešu valodā, kā arī SIM karte, kuru ir nepieciešams ievietot modemā. Mēģinot iespraust modemu brīvā datora USB ligzdā, uzreiz atklājas pirmais trūkums – iekārta ir pietiekami resna, lai aizsegtu blakus esošās ligzdas, kur ir paredzēts spraust citas USB iekārtas (piem. peli). Lai problēmu risinātu, ir nepieciešams USB pagarinātājs, kas komplektā nav iekļauts. Pie iekārtas plusiem var pieskaitīt ārējās antēnas iztrūkumu, kas gan vienlaikus ir arī iekārtas trūkums – nav iespējams pieslēgt ārējo antenu, lai uzlabotu uztveršanu atrodoties telpās. Šī iemesla dēļ iekārtu nevar rekomendēt patstāvīga inerneta savienojuma ierīkošanai lauku mājā.

Pēc iekārtas ieslēgšanas, tā uzreiz datorā tiek atpazīta… kā USB datu nesējs. Datu nesēja izmērs – 14 Mb, tips – SCSI CD-ROM iekārta ar ISO 9660 failu sistēmu. Datu nesējā atrodas kaut kādi faili, kurus ir iespējams darbināt MS-Windows vidē. Nekādas instrukcijas, README faili nav atrodami. Zvans LMT palīdzības dienestam. Patīkami – lai gan otrā galā esošajai operatorei nav nekādas sajēgas, kas ir redzams pēc biežajām pauzēm “uzgaidiet”, tomēr pēc Linux pieminēšanas saruna vismaz nebeidzas ar “neatbalstam” paziņojumu. Pēc krietnas gaidīšanas tiek arī atrasta vajadzīgā instrukcija, tiesa gan priekš Ubuntu Linux, un laipnā operatore braši cenšas lasīt tajā teikto. Tikai veina ķibele – jau otrajā solī izrādās, ka modemā iebūvētajam datu nesējam vajadzētu saturēt mapīti ar programmām priekš Linux un priekš MacOS X, taču ne viena, ne otra mapīte tur nav. Tā nu kopīgi ar LMT palīdzības dienestu konstatējam, ka testēšanai tiek izsniegti modemi ar veco programmatūru (firmware) un bez cita interneta pieslēguma tikt pie interneta nav iespējams. Tiek gan laipni piedāvāts griezties klientu apkalpošanas centrā, kur darbinieki varētu tad šo programmatūras atjaunināšanas operāciju izveikt. Kāda izgāšanās, ņemot vērā, ka izsniedzot modemu, tika pateikts, ka tas atbalsta Linux un MacOS X. Kopējais zvana laiks – 20 minūtes.

Protams, ĢISnet drosmīgos testētājus nieka 20 minūšu gara saruna un nepieciešamība meklēt palīdzību internetā, nespēj nobiedēt. Vispirms tiek izmēģināts iekārtu piedarbināt izmantojot Wine. LMT Internet instalācija noris sekmīgi, taču Wine nav emulators (tiem, kas nesaprata joku, skatīt Wine mājaslapu). Programma darbojas labi, taču iekārtai piekļūt nav iespējams. Spriežot pēc komandrindā redzamajiem paziņojumiem, wine-1.3.3 neuztur “RasEnumConnectionsW”, lai ko tas arī nenozīmētu. Arī šis ir strupceļš.

Pēc rezerves interneta atrašanas un dažiem jautājumiem Gūgles tantei, izrādās, ka ir nepieciešama speciāla programmiņa “usb_modeswitch”, kas, pēc iekārtas pievienošanas, tai aizsūta speciālu komandu, lai modems pārslēgtos no datu nesēja uz modema režīmu. Pēc šī brīnumrīka instalēšanas, iespraužot modemu, parādās jaunas iekārtas – ttyUSB0, 1 un 2 (GSM modem (1-port) converter). Nu jau izskatās labāk. Tagad tikai paliek vēl “maziņa” problēma – kā īsti piedarbināt šo modemu?!? Izmantojot wvdialconf programmiņu, ir iespējams uzzināt, ka modems atbalsta 9600 biti/sekundē ātrumu (nezinātājiem – tas bija aktuāli pirms 1990. gada) un to ir iespējams iedzīvināt ar “ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0″ komandu. Protams, arī šis ir strupceļš, jo nekur tālāk nav iespējams tikt.

Pēc rakāšanās pa MS-Windows videi domātajiem draiveriem, izdodas noskaidrot, ka modems kā inicializācijas rindu pretī ņem mazliet savādāku komandu – “AT&FE0V1X1&D2&C1S0=0″. Tur atrodas arī nepieciešamā konfigurācijas informācija – interneta piekļuves numurs “*99#” un APN “open.lmt.lv”. Savadot šos visus parametrus wvdial programmas konfigurācijā, nu jau tiek iedots cits kļūdas paziņojums – “+CME ERROR: SIM PIN required”. Tātad vispirms ir jāievada PIN kods, taču kā to izdarīt?!? Gūgles tante saka, ka ir nepieciešams papildus parametrs “AT+CPIN=0000″, kurš tiek veiksmīgi arī akceptēts. Ups! wvdial automātiski mēģina izveidot savienojumu trīs reizes, kā rezultātā tagad jau kļūda ir “+CME ERROR: SIM PUK required”, jo SIM karte ir nobloķēta. Pēc vajadzīgo kodu noskaidrošanas izrādās, ka “AT+CPUK=XXXX” komanda neeksistē. Problēma tiek atrisināta ievietojot modema SIM karti tālrunī un ievadot nepieciešamos kodus tur. Pie reizes tiek atslēgta PIN vaicāšana pie palaišanas, lai vairs nav jāmokās. Tikai kāds bija PIN kods mana tālruņa SIM kartei?!?
Lai nu kā, bet ir ievērojams progress – modems zvana uz pareizo numuru, taču tālāk nekā – saruna tiek pārtraukta. Kas vēl trūkst? Ak, jā – jānorāda APN “AT+CGDCONT=1,’IP’,'open.lmt.lv’”. Beidzot panākums – ir nodibināts savienojums un datoram tiek piešķirta iekšējā tīkla IP adrese (10.XX.XX.XX). Varam sākt testēt. Savienojuma izveidošana prasīja nieka divas dienas ar intensīvu Gūgles tantes palīdzību. Viennozīmīgi draudzīgi.
Te būs strādājoša wvdial konfigurācija. Iekopējam saturu failā /etc/wvdial.conf un startējam kā root ar komandu “wvdial LMT_Internet”. Par visu parametru korektumu pārliecības nav, bet strādā.
[Dialer LMT_Internet]
Init1 = AT
Init2 = AT&FE0V1X1&D2&C1S0=0
Init3 = AT+CPIN=XXXX # Šis ir PIN kods, ja SIM kartei tādu vajag.
Init4 = AT+CGDCONT=1,"IP","open.lmt.lv"
Phone = *99#
ISDN = 0
Username = { }
Password = { }
Ask Password = 0
Modem = /dev/ttyUSB0
Baud = 503316480
PPPD Options = noauth crtcts multilink usepeerdns lock defaultroute nobsdcomp nodeflate refuse-pap refuse-eap refuse-chap refuse-mschap
Idle Seconds = 3000
Modem Type = USB Modem
Compuserve = 0
Auto DNS = 1
Dial Command = ATD
Stupid Mode = 1
FlowControl = NOFLOW

Testēšana tiek veikta lauku teritorijā svētdienas pusdenslaikā – nevajadzētu būt pārāk daudz citiem lietotājiem. Pirmais tests – savienojuma latentums. Testēšanai tiek izmantots ĢISnet serveris, kas ir pieslēgts pie SIGMANET.
64 bytes from 85.254.211.233: icmp_seq=100 ttl=53 time=234 ms
--- www.gisnet.lv ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99001ms
rtt min/avg/max/mdev = 214.900/268.940/454.854/39.820 ms

1032 bytes from 85.254.211.233: icmp_seq=100 ttl=53 time=624 ms
--- www.gisnet.lv ping statistics ---
101 packets transmitted, 100 received, 0% packet loss, time 100595ms
rtt min/avg/max/mdev = 539.728/638.567/879.358/56.257 ms
Kā jau redzams no šiem cipariņiem, LMT internetam piemīt nopietna aizture, kas, visticamāk, izriet no izmantotās tehnoloģijas (lasi – būtiski uzlabojumi nav gaidāmi). Lai spriestu par šo skaitļu lielumu, katrs pats var testu atkārtot savam šī brīža interneta savienojumam. Man šobrīd vidējais ICMP paketes ceļošanas laika rādītājs ir 3.6ms, t.i. 74 reizes ātrāks nekā izmantojot LMT internetu.

Protams, tiek apmeklēta arī Speedtest.net lapa, lai notestētu HTTP datu pārsūtīšanas ātrumu. Ar Chromium 7.0 lapa ielādējas ātri, taču uz Flash saturu nākas pagaidīt. Testējot ātrumu savienojumam ar Rīgā esošu serveri (Balticom), lejupielādes ātrums ir 0,14 Mb/s, augšupielāde – 0,09 Mb/s, ping – 471 ms.
Tests tiek atkārtots, taču šoreiz testam tiek uz labu laimi izvēlēts ASV esošs serveris. Izvēle krīt pa labu Losandželosai Kalifornijas štatā, kur serveri piedāvā “Dreamhost”. Iegūtie rādītāji daudz neatšķiras no tiem, kas tika iegūti testējot ar Latvijā esošu serveri – lejupielāde 0,12 Mb/s, augšupielāde – 0,08 Mb/s, ping – 629 ms.
Lai vieglāk būtu izprast šos ciparus, Speedtest lapa piedāvā uzreiz arī informāciju, cik ilgi būtu jāgaida faila lejupielāde ar šādu savienojumu – MP3 fails (5Mb) = 6 minūtes, video fails (35 Mb) = 39 minūtes, filma (800 Mb) = 901 minūte. Protams, reālais gaidīšanas laiks var būt krietni ilgāks, kā arī pastāv risks, ka savienojums var pārtrūkt pavisam. Secinājums – lēnākā daļa viennozīmīgi ir pieslēgums pie LMT nevis LMT ārzemju interneta savienojums.

Informācijas meklēšana izmantojot Google, darbojas pietiekami raiti, lai būtu ērti to lietot. Savukārt mēģinot atvērt ĢISnet.lv lapu, nākas saskarties ar gaidīšanu. Dažu minūšu laikā tā arī lapa neielādējās. Mēģinot vēlreiz – viss notiek salīdzinoši raiti. Secinājums – interneta ātrums ir ļoti nestabils un visticamāk mainās atkarībā no signāla stipruma.

Nākamais tests – topogrāfiskās kartes 1:10k kopēšana uz ĢISnet serveri, izmantojot SCP. Faila izmērs – 1,3 Mb. Te nu sākas interesantumi – faila kopēšanas laiku SCP uzrāda kā 0 sekundes ar ātrumu 1,3 Mb/s, taču nākas vēl ilgi gaidīt kamēr tiek saņemts paziņojums par sekmīgu darbības pabeigšanu. Acīmredzot pie vainas ir kaut kāda lokālā kešatmiņa. Nākas testu vēlreiz atkārtot, tikai šoreiz mērot laiku no komandas sākuma līdz beigām, tas ir, ieskaitot paroles ievadīšanas laiku.
$ time scp topo10k.jpg marisn@gisnet.lv:/home/marisn
marisn@gisnet.lv's password:
topo10k.jpg 100% 1291KB 1.3MB/s 00:00

real 2m5.999s
user 0m0.092s
sys 0m0.020s


Nākamais tiek apmeklēts ĢISnet piedāvātais topogrāfisko karšu pārlūks. Kad pēc trīs minūšu gaidīšanas Chromium 7.0 joprojām neko nav ielādējis, tests tiek atkārtots ar Firefox 3.6. Ielāde sākas uzreiz, taču pilna sākuma skata ielādēšanās aizņem aptuveni trīs minūtes. Mainot kartes tuvinājuma pakāpi – atkal jau ir jāgaida vairākas minūtes – mainot kartes tuvinājumu vai skatu, ir jārēķinās ar vismaz 2 minūšu gaidīšanu. Tiesa, pēc datu sņemšanas, skatīšanās ir raita, jo visi dati ir jau uz datora.

Visbeidzot tiek veikts tests, kurš interesē visvairāk – cik ātri strādā WMS?!? Slāņu saraksta saņemšana notiek raiti – gandrīz tik pat ātri, kā izmantojot stacionāro pieslēgumu, taču te arī labais iespaids beidzas. Latvijas kopskata saņemšana aizņem 2 min 15 sek. Tā kā slāņi tiek attēloti to dzimtajā koordinātu sistēmā (ETRS89/TM Baltic93), datu sagatavošanai nepieciešamais servera laiks noteikti neveido lielāko gaidīšanas laika daļu. Lai nodrošinātu objektīvākus rezultātus, QGIS vietā tiek izmēģināts lietot wget. QGIS vidē izvēlas tuvinājumu, kurā var redzēt topogrāfisko karti mērogā 1:10 000, iegūto WMS pieprasījuma adresi iedod wget, tikai pirms tam nomainot telpisko apgabalu – lai būtu svaiga vieta. Lejupielādējot WMS datus ar wget, ātrums vidēji turās ap 16 kb/s, brīžiem pat sasniedzot 19 kb/s, taču lejupielāde brīžiem pārtrūkst pavisam, lai arī modems atvienošanos neuzrāda. Pēc brītiņa gan savienojums pazūd pavisam un atkārtota savienojuma izveidošana beidzas ar paziņojumu “+CME ERROR: SIM failure”. Iekārtas izraušana/iespraušana, SIM kartes izņemšana/ielikšana nekādus rezultātus tā arī nedeva, līdz ar to, nācās testus beigt pirms laika.

Tā nu savienojuma prieki ilga nepilnu stundu, kuras laikā tika paspēts notērēt 23,23 megabaitus no testēšanai piedāvātā viena gigabaita. Modems tika atgriezts atpakaļ LMT, jo ātrums nebūt nebija tuvs reklamētajam, kā arī iekārta nespēj funkcionēt stabili.
Gala secinājums – ja vajadzība pēc interneta nav pārāk bieža, labāk izlīdzēties ar jebkuru GPRS/UMTS atbalstošu mobilo tālruni, jo savienojuma ātrums būs tāds pat (apgalvojums balstās uz pieredzi ar tajā pašā vietā lietoto LMT internetu izmantojot Nokia 6120 Classic tālruni). Ja internets laukā ir nepieciešams bieži, tad ir vērts pamēģināt vēl kādu citu piedāvājumu, jo šis LMT piedāvājums noteikti nav ne ar ko pārāks par kaimiņos esošo Triatel interneta pieslēgumu.

Ja aplūko QGIS GRASS spraudni pirmkoda līmenī, tad izrādās, ka datu attēlošanu uz ekrāna veic pati QGIS programma izmantojot GRASS gluži tā pat kā jebkuru citu datu avotu. Tam ir zināmas priekšrocības, jo automātiski ir pieejamas visas QGIS slāņu noformēšanas iespējas, kā arī vektordatu slāņu pārprojecēšana pie attēlošanas. Kas attiecas uz datu apstrādes rīkiem, tad tiem QGIS nodrošina tikai grafisko priekšpusi – savāc lietotāja norādītos parametrus un palaiž analīzes programmu ar dotajiem parametriem. Līdz ar to galvenais secinājums – “tīra” GRASS vai GRASS no QGIS darbināšana neietekmē analīzes rezultātus, jo tiek izmantotas vienas un tās pašas programmas.

No iepriekš noskaidrotā izriet vēl kāda svarīga lieta – pat ja mēs lietojam GRASS no QGIS vides, joprojām ir spēkā GRASS “spēles noteikumi”. Šie “noteikumi” ir salīdzinoši vienkārši.

• Lai gan ir iespējams pievienot vektoru/rastra karti no jebkura GRASS novietojuma, analīzes rīkiem būs pieejamas tikai aktīvā novietojuma/karšu kopas kartes.
• Rastra datu nolasīšana notiek tādā izšķirtspējā, kāda ir iestatīta reģiona iestatījumos. Tāda pati izšķirtspēja tiks izmantota no jauna veidotajiem rastriem. Pemērs redzams attēlā.
• Darbības ar rastru notiek tikai reģiona ietvaros. Ja nepieciešams izmantot ne-taisnstūra teritorijas ierobežojumu, ir pieejams rastra masku atbalsts. GRASS rastra reģionu var aplūkot QGIS vidē uzklikšķinot uz ikoniņas “Rādīt pašreizējo GRASS reģionu”, kas parādīs tā robežas kā sarkanu taisnstūri pa virsu pārējai kartei. Piemērs redzams attēlā.
• Ir iespējams rediģēt tikai aktīvajā karšu kopā esošos vektordatus, piedevām lietotājam ir jābūt karšu kopas mapes īpašniekam.

Vairāk par dažādām GRASS specifiskām lietām var palasīt GRASS GIS dokumentācijā. Ievads GRASS palīdzēs saprast, kas ir novietojums, karšu kopa. Savukārt ievads 2D rastra apstrādē un ievads vektordatu apstrādē palīdzēs izprast GRASS rastru un vektoru specifiku, kā arī kuros rīkos meklēt biežāk lietotās datu analīzes metodes.

Tiktāl viss ir bijis ļoti skaisti, taču GRASS lietošanā no QGIS vides ir arī savi trūkumi. Pirmkārt – QGIS uztur tikai vienkāršos vektordatus (OGC SFS) un nepieļauj dažādu ģeometriju paralēlu eksistenci vienā datu slānī. Šī iemesla dēļ attēlojot GRASS vektordatu slāni QGIS vidē ir jāizvēlas kāda tipa objekti tiks rādīti. Tāpat pagaidām QGIS GRASS spraudnis neuztur vektoru topoloģijas attēlošanu.
Nākamais ierobežojums ir saistīts ar QGIS veikto moduļu grafiskās saskarnes vienkāršošanu – grafiskajā vidē ir pieejami tikai tie moduļu parametri, kuri ir norādīti QGIS moduļa konfigurācijas failā. Lielākajai daļai moduļu ir pieejami visi parametri, lai gan atsevišķiem moduļiem parametri ir sadalīti pa atsevišķiem rīkiem. Tā, piemēram, modulis r.lake QGIS vidē parādās divās versijās – atkarībā no izvēlēta datu ievades tipa kā r.lake.xy, gan kā r.lake.seed.
Visbeidzot problēmas sagādā GRASS uzbūves arhitektūra – GRASS ir veidots kā rīku kopums nevis monolītas sistēmas daļa, līdz ar to, avārijas gadījumā, GRASS rīki un bibliotēka parasti pārtrauc programmas izpildi. GRASS darba sesijā tas nekādas problēmas nerada, taču monolītā programmā kā QGIS, tas var nozīmēt tūlītēju QGIS aizvēršanos vai avāriju.
Tāpat der piezīmēt, ka GRASS vektoru rediģēšana QGIS vidē šobrīd notiek tiešā režīmā – QGIS avārijas gadījumā vektoru slānis var tikt neatgriezeniski bojāts! Tāpat nav pieejamas “Atcelt” un “Pārdarīt” pogas – kļūdas ir jālabo manuāli. Tiesa gan “tiešās” rediģēšanas izmantošanai ir arī priekšrocības – GRASS vektordatu rediģēšana ir topoloģiska – uzreiz ir redzams, vai līniju gali ir savienoti, laukumi ir noslēgti utml. Ja ir vēlme nodrošināties pret nejaušu datu zudumu rediģējot vektordatus, drošākais ir izveidot tiem kopiju, ko var paveikt atverot GRASS čaulu (shell) un ieklabinot komandu “g.copy vect=old,new”, kur “old” ir vecās kartes nosaukums, “new” – jaunā karte. QGIS vidē šobrīd nav grafiskās saskarnes priekš g.copy moduļa.

Kā redzams – GRASS lietošanai QGIS vidē ir stiprās un vājās puses. Gluži tā pat kā ar jebkuru citu risinājumu – atliek tik pieņemt lēmumu, kurā brīdī kurš rīks labāk der. No analīzes rezultātu viedokļa – atšķirību nav – joprojām svarīgākās ir un paliek prasmes dotos rīkus pielietot pareizi. Jautājiet, un jums taps atbildēts.

Grāmatas

Pietika apskatīt divas grāmatas, lai būtu skaidrs, ka viennozīmīgas atbildes nebūs. 2001. gadā Valsts zemes dienesta izdotajā „Mūsdienu Latvijas topogrāfiskās kartes” (ISBN 9984-9508-2-4) 38. lappusē lasāms: „ Latvijas ģeodēziskās sistēmas vai LKS-92 (Latvijas koordinātu sistēmu – 92) pamatu veido Eiropas zemes atskaites sistēmā (European Terrestrial Reference System) noteiktie četri nultās klases ģeodēziskie punkti .. . .. Latvijas koordinātu sistēmas plaknes taisnleņķa projekcijas pamatā ir transversālās projicēšanas Merkatora likums (TM) ar vienu Rīgas centrālo ass meridiānu 24° A.g. un mēroga koeficientu 0,9996 uz tā, kur abscisa vērsta ziemeļu virzienā, samazinot to par 6000 km, bet ordināta palielināta par 500 km rietumu virzienā.”

Otra grāmata, kuru pāršķirstīju, bija 2007. gadā Valsts aģentūras „Latvijas Ģeotelpiskās informācijas aģentūra” (LĢIA) izdotā „Ģeodēzija” (ISBN 9984-28-428-X). 18. lappusē iespējams izlasīt, ka „tagad punktu koordinātas mūsu valstī tiek noteiktas Latvijas ģeodēzisko koordinātu sistēmā LKS-92, kas pielāgota pasaules ģeodēziskai sistēmai WGS-84. Šīs koordinātu sistēmas pamatā ir Merkatora projekcija (TM). Pēc būtības šī projekcija ir līdzīga iepriekš aplūkotajai UTM projekcijai, bet atšķiras ar to, ka par zona ass meridiānu ir pieņemts meridiāns ar ģeogrāfisko garumu 24° (Rīgas meridiāns). Ar to tiek panākts, ka visa Latvijas teritorija atrodas vienā zonā. Lai izvairītos no negatīvām Y vērtībām, tāpat kā Gausa koordinātu sistēmā, zonas ass meridiāna ordinātai pieskaita 500 km. Tādā veidā koordinātu sākumpunkts (ass meridiāna un ekvatora krustpunkts) nosacīti tiek pārnests uz rietumiem par 500 km. Ekvatora abscisas X tiek ieņemta ar vērtību 0. Latvijas teritorijā X vērtība ir, sākot no 6175 km .. .”

Abi apraksti ir vienisprātis par to, ka LKS-92 apzīmē taisnleņķu koordinātu sistēmu ar noteiktiem parametriem. Nesaprašanās ir tikai par vienu parametru – ko darīt ar Dienvidu – Ziemeļu virziena koordinātām – atņemt vai neatņemt 6000 km. Abas grāmatas rada maldīgu priekšstatu, ka koordinātas tiek izteiktas kilometros.

Uzskats, ka jaunāka grāmata būtu pareizāka, šoreiz nav spēkā. Normatīvo aktu apskats liecina, ka LĢIA oficiālais viedoklis nesakrīt ar pašas izdotajā grāmatā pausto.

Normatīvie akti

2009. gada nogalē pieņemtajā «Ģeotelpiskās informācijas likumā» tik vien teikts, ka „Ģeotelpiskās informācijas pamatdatu iegūšanā, sagatavošanā un uzturēšanā izmanto Latvijas 1992. gada ģeodēzisko koordinātu sistēmu, 1993. gada topogrāfisko karšu sistēmu un Baltijas 1977. gada normālo augstumu sistēmu. Minēto sistēmu parametrus un to piemērošanas kārtību nosaka Ministru kabinets.” Tātad, jāskatās, ko apstiprinājiss MK. Ir Ministru kabineta 2007. gada 20. novembra rīkojums Nr. 718, kurš saucas, «Par Latvijas ģeotelpiskās informācijas attīstības koncepciju». Rīkojums ir spēkā esošs un ar to tika apstiprināta Latvijas ģeotelpiskās informācijas attīstības koncepciju un atzīta par spēku zaudējušu Kartogrāfijas attīstības koncepciju, kura bija akceptēta ar Ministru kabineta 1995. gada 23. maija sēdes protokollēmumu (prot. Nr.27 17.§).

Iepazīstoties ar «Latvijas ģeotelpiskās informācijas attīstības koncepciju», beidzot atrodam meklēto – koncepcijas 2. pielikums saucas „1992. gada Latvijas ģeodēziskā koordinātu sistēma (LKS-92)”. Šajā pielikumā rakstīts, ka „LKS –92 ir veidota uz pasaules 1984. gada ģeodēziskās sistēmas WGS 84 (World Geodetic System 1984) pamata un tās piesaisti Zemei nosaka šādi ģeodēziskie dati:

1. starptautiskās ģeodēziskās atskaites sistēmas 1980. gada Zemes modelis GRS 80 (Geodetic Reference System 1980);
2. ģeodēzisko punktu „Rīga”, „Kangari”, „Indra” un „Arājs” elipsoidālās koordinātas, kuras noteiktas Eiropas elipsoidālo koordinātu atskaites sistēmā ETRS 89 (European Terrestrial Reference System 1989);
3. transversālās projicēšanas Merkatora likuma rezultātā aprēķinātā koordinātu plakne ar vienu ass meridiānu 24° A.g.(austrumu garuma) ar sagrozījuma mēroga koeficientu 0,9996 uz tā, kur abscisa(X) vērsta ziemeļu virzienā un tā samazināta par - 6000 km, bet ordināta (Y), kas vērsta austrumu virzienā palielināta par + 500 km;
4. ģeodēzisko punktu augstumi Baltijas 1977. gada normālo augstumu sistēmā ar sākumu Kronštatē.”

Lai arī atkal tiek piesaukti km, iepazīstoties ar tālāk tekstā dotajām formulām, var redzēt, ka koordinātas LKS-92 tiek izteiktas metros.

Lai arī šī koncepcija būtu uzskatāma par „stingāko” papīru, kurš izskaidro LKS-92 saturu, ne visi normatīvie akti mūsu valstī ir ar to saskaņā. Tālāk trīs atšķirīgi piemēri no arvien spēkā esošiem dokumentiem:

1. Likums „Par Latvijas Republikas valdības, Baltkrievijas Republikas valdības un Lietuvas Republikas valdības vienošanos par valstu robežu krustpunkta noteikšanas kārtību”, spēkā kopš 1998.05.29. Šajā likumā atrodam tekstu: „.. ar sekojošām, grafiski noteiktām, ģeogrāfiskajām koordinātām:
   1992. gada Latvijas koordinātu sistēmā (LKS-92)
   55°40’50,17” z.p.
   26°37’49,79” a.g.
   ..”.
2. „Ķemeru nacionālā parka likums”, spēkā kopš 2001.07.03. Aprakstot robežu arī šeit tiek piesaukts LKS-92: „.. tad pāri Vecslocenes upei līdz punktam Latvijas koordinātu sistēmā (LKS-92) x 471574,00, y 6315549,00, tālāk gar Vecslocenes upes kreiso krastu pa iedomātu taisni ..”.
3. MK noteikumos Nr. 69 „Noteikumi par aizsargājamo ainavu apvidiem” (spēkā kopš 1999.03.03.) rakstīts: „Šo noteikumu 7., 8., 9. un 10. pielikuma robežpunktu koordinātas ir programmatūras Esri ArcView 8.3 aprēķinātās apveidfailu (*.shp) visu lūzuma punktu koordinātas Latvijas koordinātu sistēmā LKS 92 (Transversā Merkatora projekcija, mēroga faktors – 0,9996, ass meridiāns – 24 E), kas noapaļotas līdz veseliem metriem.”. Tālāk dotajās tabulās redzams, piemēram, šādas punkta koordinātas: „ X koordināta: 649128, Y koordināta: 225740”.

Tie, protams, nav vienīgie normatīvie akti, kuros uzdotas koordinātas it kā „LKS-92” sistēmā, lai gan tiek izmantotas trīs dažādas koordinātu sistēmas. Pirmajā piemērā punkta koordinātas uzdotas ģeogrāfiskajās koordinātās, otrajā uzdotas metriskajās ar 0 km nobīdi Ziemeļu virzienā, bet trešajā – metriskajās ar -600 km nobīdi Ziemeļu virzienā.

Datorprogrammu apskats

Darbam ar telpiskiem datiem parasti izmanto datoru ar kādu tam domātu programmu. Apskatot svaigi instalētu «ArcGIS 9.2» piedāvāto koordinātu sistēmu klāstu, redzam, ka šeit arvien, kā pirms trim gadiem, pie projicētajām koordinātu sistēmām atrodam divas, kuru nosaukumos ir „LKS-92” – gan ar, gan bez nobīdes Ziemeļu virzienā par -600 km. Viena, ar nosaukumu „LKS 1992”, atrodama arī pie ģeogrāfisko koordinātu sistēmām.

«Quantum GIS» lietotāji ir labākā situācijā. Šajā programmā koordinātu sistēmas tiek sauktas to īstajos vārdos. Koordinātu sistēma, kas atbilst „Latvijas ģeotelpiskās informācijas attīstības koncepcijai”, tiek saukta par „LKS92 / Latvia TM”. Tā, bez nobīdes Ziemeļu virzienā, par „ETRS89 / TM Baltic93”. Tiesa, arī pie ģeogrāfiskajām koordinātu sistēmām atrodam „LKS92”. Lai labāk to izprastu, jāpievēršas tīmeklī publicētai informācijai.

Informācija tīmeklī

Neapskatīšu to, ko kurš ir nopublicējis kā privātpersona. Apskatīšu tikai divas datubāzu sistēmas, kuras uzskatāmas par standartu uzturētājām koordinātu sistēmu jomā. Pirmā ir „Information and Service System for European Coordinate Reference Systems (CRS)”. Mājas lapas adrese ir http://www.crs-geo.eu/. Ir atrodama tikai viena ar „LKS-92” saistīta koordinātu sistēma – „LV_LKS-92 / LV_TM”. Pie šīs sistēmas apraksta ir atsauce uz Latvijas Ģeotelpiskās informācijas aģentūras Ģeodēzijas departamentu. Koordinātu sistēma atbilst „Latvijas ģeotelpiskās informācijas attīstības koncepcijā” minētai koordinātu sistēmai. No apraksta var arī uzzināt vēl vienu saīsinājuma „LKS-92” skaidrojumu – tas ir referencelipsoīds.

Otra datubāzu sistēma, kurā ir vērts ielūkoties, ir „EPSG Geodetic Parameter Dataset” (http://www.epsg-registry.org/). Šo datubāzi izmanto arī daudzas ar kartogrāfiju saistītas datorprogrammas, lai definētu izmantojamās koordinātu sistēmas. Ir atrodami sekojoši, ar šo rakstu saistīti, ieraksti:

No tabulas redzams, ka saīsinājums „LKS-92” tiek ietverts gan ģeogrāfisko koordinātu sistēmu, gan vienas projicētās koordinātu sistēmas nosaukumā. Iepazīšanos ar katras koordinātu sistēmas sīkāku izklāstu atstāju lasītāju paša ziņā. „Latvijas ģeotelpiskās informācijas attīstības koncepcijai” atbilst projekcija „ LKS92 / Latvia TM” ( EPSG::3059).

Kopsavilkums

Ar „LKS-92” tiek apzīmētas atšķirīgas lietas – referencelipsoīds, ģeogrāfisko koordinātu sistēmas un divas projicētās koordinātu sistēmas.

Nobeigumā trīs ieteikumi:

1. Pārstāt saukt koordinātu sistēmu „ETRS89 / TM Baltic-93” par „LKS-92”. Galu galā, pastāv taču Ministru kabineta 2007. gada 20. novembra rīkojums Nr. 718, kas to nosaka.
2. Ja kāds prasa uzdot objekta koordinātas LKS-92 sistēmā, nenokautrējaties un, neņemot vērā 1. ieteikumu, paprasāt, kas ar to tiek domāts.
3. Lai nejuktu referencelipsoīds, ģeogrāfiskās koordinātu sistēmas un projicētā koordinātu sistēma, tad „Latvijas ģeotelpiskās informācijas attīstības koncepcijā” aprakstīto projekciju saukt par „LKS-92 TM”.

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.

Pieļauju, ka gisnet.lv auditorijā ir cilvēki, kam šī lieta varētu ieinteresēt. Pats par ģeokešingu pirmo reizi uzzināju laikam pirms gadiem 3 rakstot kādu referātu – toreiz likās samērā “tālu” no Latvijas ikdienas aktualitātēm. Tagad izskatās, ka šī varētu būt tīri populāra aktivitāte vietējam mērogam, spriežot pēc tā, ka šobrīd, pēc geoforums.lv datiem, Latvijā ir 505 slēpņi. Un ideja par to, ka šī ir forša iespēja paceļot un apskatīt kādas zīmīgas vietas vismaz man liekas samērā neslikta – GPSošana tam noteikti piedod zināmu hi-tech feelingu, kas kādai daļai cilvēku to varbūt padara vēl aizraujošāku:)

Varbūt slēpņotāji lasa arī gisnet.lv?

Kas attiecas uz pašu savdabīgo izdevumu, nevarētu teikt, ka esmu liels tā fans, jo kopā ar savu galveno konkurentu šie sastāda 80% makulatūras mūsu mājsaimniecībā. Pirms kāda laika bija arī neliels tracis ap šo izdevumu, kuru šķiet primāri izraisīja tā maksas konkurenta neapmierinātība ar pilsētas pašvaldības kailajām propogandas tieksmēm un centieniem kropļot vietējo mediju tirgu (ja to tā var nosaukt). Lai nu kā, bet beidzās tas ar to, ka tagad mēs nelūgtā kārtā saņemam abus divus! Nevar jau nosodīt pašvaldības mēģinājumus uzturēt kontaktus ar saviem iedzīvotājiem un radīt kādu kopības apziņu un informētību par to, kas notiek ap viņiem viņu pilsētā, bet resursu neizšķērdēšanas labad fiziskās kopijas tomēr varēja sūtīt tikai tiem, kas to izvēlētos, nevis visai pilsētai masveidā. Bet tas nu tā.

Tomēr šķiet tas, ka šim izdevumam ir garantēta auditorija un līdz ar to arī laikam budžets, droši vien pieļauj plašāka spektra eksperimentus ar tematiku, kas dod iespējas pa laikam producēt ko šādu.

Aizsāka Jeff Thurston ar  Geospatial Thought of the Day:
Let’s be clear: If government pays for geodata, then makes it available for free. Then it is not free. You ARE paying for it.
The question should be - “what do you want to buy?”

Sean Gillies formulējumā:
If you're paying for it, you own it, and should have the right to unfettered access to unclassified portions of it.

Jāsaka, ka ne tikai ĢISNet radošais kolektīvs jauno gadu ir iesācis bez skaļiem notikumiem. Arī daži ievērojamākie brīvās ĢIS programmatūras projekti joprojām nav laiduši tautās savus jaunākos un ilgi gaidītos gara darbus. Ilgi gaidīto QuantumGIS laidienu 1.0.0 pašlaik aizkavē vairs tikai problēmas ar Windows versijas kompilēšanu/sapakošanu. Priekš citām operētājsistēmām QGIS pakas esot jau gatavas, savukārt eksperimentēt kārākie Ubuntu lietotāji forumā jau ziņoja par jaunās versijas pieejamību un lietojamību. Tiklīdz ko QGIS jaunā versija būs oficiāli pieejama, noteikti to darīsim zināmu, kā arī centīsimies paskatīties, kas tad ir jauns šajā laidienā salīdzinot ar iepriekšējiem.

GRASS ĢIS laidiens 6.4.0 arī joprojām mazliet kavējas. Daļa izstrādātāju jau strādā pie 7 versijas un 6 zaru atstājuši mazliet novārtā, citiem savukārt nepārtraukti gribas “vēl tikai šo papildinājumu / labojumu”.

GRASS 6.4 WxPython GUI

GRASS 6.4.0 lielākais jaunums būs jauna grafiskā vide, kura veidota iekš WxPython. Pirmos iespaidus par to jau bija iespējams iegūt no 6.3.x laidieniem, taču šobrīd šī grafiskā vide jau tiek uzskatīta par pietiekami stabilu, lai to varētu izmantot ikdienā. Kā redzams no ekrānattēla, izskats ir mazliet mainījies, bet grafiskās vides darbības pamatprincipi ir palikuši vecie. Gala laidiena lietotājus sagaida vēl viens pārsteigums – jauna ikonu tēma, kura tika pievienota tikai dienu pirms RC2 taga izveides. Vecā Tcl/Tk bāzētā grafiskā vide joprojām būs pieejama visos 6 zara laidienos, savukārt GRASS 7 vairs nesaturēs nekādus Tcl/Tk bāzētos grafiskās saskarnes elementus. Tie, kuri nespēj sagaidīt gala laidienu, var pamēģināt otro laidiena kandidāta versiju (RC2), kas ir pieejama kopš 12. janvāra. Savukārt pārējiem vēl mazliet jāpaciešas, jo GRASS ir gatavs tad, kad ir gatavs.