Uzlabota otrā publiskā versija (1.xx sērija) Karšu lapu masveidīga piesaiste pie nomenklatūras tīkla

Dizainiski apsvērumi Cieta pamatne:) - Programma darbojas kā plugin labi zināmai atvētā koda programmai QGIS, kura visticamāk nav sveša vairumam šī bloga lasītāju. MapSheetAutoGeoRef ir pieejams kā papildinājums no QGIS oficiālā pluginu repozitorija. Kādēļ QGIS? Tādēļ, ka QGIS ļoti ātri spēj strādāt ar lieliem rastriem pateicoties tam ka pamatā šo funkcionalitāti balsta uz GDAL un to ir vienkārši skriptēt. Teorētiski nelimitēta izmēra rastru atbalsts. GDAL var strādāt ar ļoti Lieliem rastriem. Ātri. Būvēt pirmīdas un konvertēt tos visādos veidos. Tas ir noderīgi, darba paātrināšanai.

Daudzprocesoru sistēmu atbalsts - vairāku instanču vienlaicīga startēšana no komandlīnijas, izmantojot GDAL “ārēji” nevis caur QGIS – šādi ir relatīvi vienkārši panākt vienlacīgu darba veikšanu uz nierobežota skaita procesoru, sistēmām kam tas ir iespējams. Nu būsim godīgi – kāda jēga ir no daudzkodolu mašīnām ja vairums programmu nespēj tos izmantot? Šī spēj, bet cieto disku (rindas) ātrumam ir nozīme.

Multiplaformu – izmantojot komponentus tādus kā Qt, GDAL, Python un pašu QGIS. Lai gan lielākā daļa cilvēku šķiet vēl izmanto Windows, nedomāju, ka tā būs arī ilgtermiņā. Vislabāk ir atbrīvotis no nepieciešamības nodarboties ar šādiem apsvērumiem vispār, atbalsta iespēju robežās visas (neesmu testējis uz BeOS utml:)

Atvērtais kods - pašsaprotami

Noturība pret avārijām un spēja turpināt iesāktu darbu – stūru koordinātas tiek saglabātas pēc katras lapas un veselos 2 failos. Sistēmas avārijas gadījumā maz ticams, ka jūs zaudēsiet koordinātas vairāk kā vienai lapai darba. Ja lapu skaits ir par lielu lai to pabeigtu vilkt vienā dienā, jūs varat programmu aizvērt un turpināt nākamajā dienā no tās lapas kur palikāt – tikai sākumā norādiet tās pašas direktorijas ko pirmajā darba sesijā.

Vienkāršota darba gaita: Ņemam čupu karšu lapu rastru, kas novietoti vienā direktorijā kopā ar atbilstošo lapu tīklu shp formātā. Tīkla shp failam jāsatur lauks ar poligonu nosaukumiem, kas ir tādi paši (vai līdzīgi) pēc nosaukumiem kā rastru faili* Visi rastri tiek ielādēti iekš QGIS un tiek automātiski tuvināti to 4 stūri – lietotājam šai brīdī ir jānospiež kursors uz tās vietas kur ir kartes lapā atspoguļotas teritorijas malu atbilstošais stūris. Pēc tam kad visi stūri ir norādīti tiek automātiski veikta karšu lapu reģistrācija – šis process neprasa lietotāja līdzdalību un lielam skaitam lapu to ir domāts atstāt patstāvīgam darbam pa nakti, nedēļas nogali, vai kādu garāku laika periodu.

Komentāri par darba gaitu – ko ļoti vēlams zināt: Pirms stūru norādīšanas programma pirmajā dialoga piedāvā (darba ievērojamai pāatrināšanai) veikt priekškonvertāciju – piemēram, ja jums ir lēns dators un rastri ievērojami pārsniedz, kādus 100 megapikseļus. Ir iespējams tos vispirms pārkonvertēt uz pelēku toņu (grayscale) rastru, kam malu garumi ir par 50% mazāki – summāri tas ir 12x ieguvums uz diska vietu, jo rastra apjoms samzinas 4 nevis 2 reizes šai gadījumā un pāreja no parasta 3 kanālu rastra uz 1 padara to vēl par 66% mazāku. Taču šāda konvertācija diez vai traucēs jums sazīmēt kartes stūri. Ja šādam samazinātam rastram uzbūvē piramīdas (ielikot atbilstošo ķeksi logā), tad darbības ātrums no lēna kļūst par ļoti ātru gandrīz visos gadījumos. Šī ir arī tā situācija, kad varbūt kāds var vēlēties instalēt imagemagick, caur kuru tiek nodrošināta konvertācija uz GIF formātu (256 krāsu skatam) un monohromo.

Taču vairumam gadījumu grayscale 50% ir vispiemērotākais priekškonvertācijas variants un priekš tam imagemagick nav vajadzīgs.

Konvertācijas darbības tiks veiktas palaižot reizē tik daudzas konvertācijas utilītu instances, cik mašīnai būs procesoru. Ja šai brīdī jums ir aizdomas, ka jūsu disku rinda varētu slikti panest visus šos konvertatorus mēģinam strādāt reizē, tad var protams norādīt mazāku instanču skaitu atbilstošajā lodziņā. Tas varētu būt aktuāli, ja jums nav ātra RAID disku rinda vai arī ir aizdomas par nepiemērotu RAID konfigurāciju. Ja nav īsti pārliecības par neko no šī visa, tad var vadīties pēc tā, ka viens moderns SAS/SATA disks varētu spēt turēt līdzi 2 konvertoru instancēm smagi nesākot iebremzēt visu to lietu kopumā. Tātad pa 2 diskiem RAID 0 ja ir 4 procesori būtu ļoti vēlams. Jo vairāk ātru disku jo labāk:P Ja ir šaubas par visu šo, tad nevajg par to īpaši straukties – gan jau kaut kad tā programma darbu beigs:)

Tiek atbalstītas karšu lapas un atbilstošie poligoni tikai ar 4 stūriem. Tīkla poligonu izmēri var būt dažādi, bet ja tiem nebūs 4 stūru rezultāti būs neprognozējami. Lai gan teorētiski varētu mēģināt atbalstīt lapas ar lielāku stūru skaitu, tomēr praksē lielam skaitam karšu lapu parasti ir 4 stūri – nestandarta lapas parasti ir mazā skaitā un var būt ļoti dažādas. Vispār stūru dēļ es vienu no algoritmiem esmu pārrakstijis nu jau vismaz 3 reizes un man tas ir konkrēti apnicis. Ja liekas, ka tas nav (pietiekami) forši, tad tā kā programma ir atvērta jūs esat ielūgti to uzlabot, t.sk stūru detekcijas algoritmu (funkcija CornerLogic?, jeb nu jau newCornerLogic:/). Tomēr praksē 4 stūri ir gana labi 98% gadījumu, kad runa ir par masveidīgiem piesaistes darbiem. Lieliem pārklājumiem (pārāk daudz) nestandarta lapas nav tik raksturīgas.

Atsevišķos gadījumos pastāv arī iespēja programmu mazliet “piečakarēt” lai varētu ievilkt lapas ar lielāku stūru skaitu, tā tikā tām būtu 4 stūri. Pieņemsim, ka jāvelk 50 lapas. Bet tām ir reāli tikai 5 neregulāri rāmji kuri katrs ir kopēji 10 lapām. Šāda situācija reizēm ir ar atsevišķām tematiskajām kartēm, kas pārsedz lielas teritorijas un atspoguļo, piemēram dažādu ģeoloģiska rakstura informāciju par teritoriju. Tas ko šādā gadījumā var darīt ir katram no šeim pieciem rāmjiem ir iedigitizēt shp failā 4 stūrus. Un ļoti labi iegaumēt kurus tieši, katram rāmim. Pēc tam vienkārši veikt piesaistes darbu pluginā klikšķinot uz tieši šiem 4 stūriem. Tāpat var rīkoties arī izmantojot konkrētus koordinātu tīkla kurstpunktus, ja tas ir ērtāk. Taču šis risinājums neatrisinās problēmu ar daudziem desmitiem vai simtiem neregulāru rāmju, kuram katram atbilst viena lapa – tādā gadījumā darbs kas jāiegulda priekš konkrētu 4stūru izvēles un digitizēšanas visdrīzāk neattaisnos sevi attiecībā pret ģeoreferencēšanu ar parastākām metodēm.

Koordinātu sistēma tiek iegūta no shp failam līdzi nākoša prj faila, kas satur koordinātu sistēmas aprakstu ESRI wkt formātā. Ja jūsu shp failam tāda nav –  dabujiet to!

Koordinātas tiek iegūtas no tīkla poligonu stūriem. Kādēļ tieši tā? - Ja jūs piesaistat lielāku skaitu lapu, jums vienalga vajadzēs pārskata tīklu. Daudzi tīkli ir ģenerējami automātiski – vienkāršs veids kā iegut koordinātas;) Varbūt jums jau šāds tīkls ir – no GIS Latvija, piemēram. Ja esat ArcGIS lietotājs, tad jums ir tiesības GIS Latviju izmantot arī, cik saprotu, šādām lietām. Tad vispār šī problēma atkrīt.

Stūru automātiskajai tuvināšanai tiek piedāvāti vairāki varianti – automātiski tuvināt stūri pēc noteiktiem daļveida attālumiem (pikseļos) no rastra malas (piem 1/8 no labās), pēc lietotāja brīvi definētiem skata laukiem un mācoties no visām iepriekšējām lapām – ņemto vidējo stūru novietojumu tajās un piemetot nelielu ofsetu rezervei. Pēdējais variants izmantojams tikai tad kad stūri noklikšķināti jau vismaz 3 lapām. Katram no variantiem ir savas priekšrocības un trūkumi, bet starp tiem var brīvi pārslēgties darba laikā, lai saprastu kurš no tiem ir labāk piemērots konkrētajai karšu kopai.

*Līdzīgi nosaukumi failiem nozīmē, ka tie tiek salīdzināti līdz lietotāja norādītam atdalītājam (seperator). Piemēram, ja shp laukā NUMURS 106. kartes lapas poligonam ir rakstīta vērtība 106 un kartes rastra fails saucas 106-Pilseta.tif, tad jums ir jānorāda '-' kā atdalītājs. Citādi kā atdalītājs darbojas punkts, kas atdala faila nosaukumu no paplašinājuma.

Pēc darba beigšanas, kad notiks rastru reģistrācija, darbs tiks veikts ar vienu programmas instanci, jo reģistracija notiek ar diskam ļoti intensīvu komandu (gdal_translate, bez konvertācijas parametriem, faktiski kopēšanas darbība ar nelielām izmaiņām GeoTIFF headerī), kuru nebūtu jēgas startēt vairākās instancēs reizē.

Instalācijas kārtība: Linux: Uzinstalējam FWTools vai gdal-bin (uz debian bāzētajām tipa ubuntu), skiet arī PyQT vajadzēja. Ja gribas, arī imagemagick. Tagad arī QGIS:)

Windows XP: Instalējam FWTools. Ja gribas arī imagemagick. Tagad arī QGIS:)

Panākam, ka no win komandlīnijas var pa taisno izsaukt gdal_translate no jebkuras direktorijas – to dara šādi: Ejam iekš Control Panel uz System, šķirklis Advanced, poga Environmental Variables, nodalījums System Variables, sameklējam sarakstā Path. Šī saraksta beigās, aiz semikola pievienojam FWTools bin direktoriju, kurā atrodas daudzi jauki utilīti:) Nu, piemēram, šādi: ;C:\Program Files\FWTools2.2.6\bin *Uzmaniet savu FWTools versiju direktorijas nosaukumā – lai tas nebūtu jādara var instalēt FWTools vienmēr uz vienu direktoriju vai arī katru reizi pārinstalējot FWTools nomainīt šajā vieta uz pareizo;)

Mac: Nezinu, gan jau, ka tāpat kā uz *nixiem. Ja zinat, pastāstiet.

Pēc tam uz visām sistēmām vienādi veicam spraudņa instalāciju iekš QGIS šādi: Uzinstalējam pluginu (spraudni) Plugin installer. Tagad no izvēlnes Spraudņi (Plugins) ņemam Fetch Python Plugins un šķirtklī Krātuves (Repositories) pievienojam citu izstrādātāju spraudņu krātuves - citādi pieejami tikai oficiālā. Kaut kur contributed repozitorijā dzīvo MapSheetAutoGeoRef spraudnis. Atrodam to šķirklī Spraudņi un izvēlamies to intalēt. Kad tas izdarīts ejam uz spraudņu pārvaldnieku (plugin manager) un ielikam ķeksīti pie MapSheetAutoGeoRef, ka tas ir aktivizēts. Tagad vajadzētu parādīties menu ierakstam un ikonai uz rīku joslas ar karšu lapu un piesaistes krustiņiem. Ar šo ikonu tad arī var palaist pluginu.

Potenciālās problēmas: Tā kā šī plugina vieksmīga darbība ir atkarīga no QGIS, tā kopmonentu un DMJA toolkita veiksmīgas mijiedarbības, tad ir iespējamas situācijas, kad kaut kas nedarbojas. Ja tā notiek ir vērts pārbaudīt sekojošas lietas:

• vai gdal komandrīkus (piemēram gdalinfo) var izsaukt no komandlīnijas pa taisno?
• vai QGIS instalācijas direktorija nesatur atstarpes? Šī var būt ļoti bieža problēma un ir saistīta ar otru manu programmu DMJA, kura pagaidām nestrādā, ja failu ceļnorādēs ir atstarpes.
• vai nepastāv konflikts starp Python instalācijām, kad pluginu mēģina darbināt Python instalācija, kas ir norādīta systēmas path, bet īstenībā tas būtu jādarbina ar QGIS līdzi nākošo Python instalāciju, kurai ir citi moduļi un citas atkarības (dependencies)? Par to parasti informēs QGIS Python konsole...
• vai Python konsole nemet ārā paziņojumus, ka kaut kādas funkcijas mainīgie vai kas tāds nav definēti. Tas parasti notiek kad nekontrolētas attīstības straujajiem soļiem ejot uz priekšu QGIS API notiek izmaiņas. Šīs problēmas ir programmētājiem viegli labojamas, bet neprogrnozējamas.

Visbeidzot - ja jums ir bieži jāveic darbi ar šo pluginu un lietojat to ikdienā, prātīgi ir strādājošu instalāciju neiaztikt, ja vien nav droši zināms, ka upgreids ir liels, vajadzīgs un darbojas!