Karšu lapu koordinātās ievilcējs MapSheetAutoGeoRef
No daudzveidīgā ģeomātiska rakstura darbu klāsta ir divi, kas man vienmēr ir likušies, nu sacīsim tā, pasaule būtu laimīgāka bez viņu veikšanas nepieciešamības… Tie ir vecu materiālu telpiskā piesaiste un vecu materiālu vektorizēšana (digitizēsana). Digitizēšanas automatizēšanai ir radīti daudzi jo daudzi risinājumi laika gaitā, no kuriem, cik man zināms, neviens īsti nevar aizvietot cilvēku, tomēr vismaz iestrādes šai virzienā ir.
Kas attiecas uz ģeoreferencēšanas automatizēšanu, arī to ir centušies lielākiem darbu apjomiem cilvēki kaut kā automatizēt, bet cik man zināms šie centieni nav beigušies ar plašāk pielietojumu risinājumu, kuru pēc tam līdzīgā izskatā varētu pārņemt citi un lietot saviem datiem pietiekmi universālā veidā. Lai šo darbu atvieglotu tapa plugins QGISam, kas padara šo darbu ievērojami ātrāku.
Rāmī "ievērpta" karte
Tā kā arī man ne vienu vien reizi ir bijis vajadzīgs telpiski piesaistīt, jeb ievilkt koordinātās, šādus tādus legacy materiālus, tad mani nepameta domas, ka būtu labi šo visu automatizēt tik tālu cik nu vien iespējams. To pašu iemeslu dēļ, kuru digitizēšanas automatizēšana joprojām nav perfekta, atkrīt mēģinājumi piespiest datoru pilnīgi patstāvīgi veikt visus ģeoreferencēšanas darbus (pagaidām nespēs labāk par cilvēku atpazīt pareizos kartes stūrus). Taču labi pārdomājot stūru atpazīšana ir viens ļoti īss un, priekš cilvēka, triviāls posms karšu lapu ģeoreferencēšanas darba gaitā. Toties pārējie posmi ir vienkārši datoram. Tādēļ mans mēģinājums šo darbu automatizēt balstās uz abu šo faktoru apvienojumu – cilvēkam darīt tikai to ko dators nespēj izdarīt pietiekami uzticami un labi. Datoram darīt visu pārējo, ko tas spēj automātiski bez lietotāja līdzdalības.
Tie kas bija LĢIA organizētajā ĢIS dienā 2008. gada novembrī, iespējams atceras manu prezentāciju par šo darbu. Tiem, kas nebija toreiz klāt, vai tāpat gribas ieskatīies ir pieejama tās dienas prezentācija.
Pievienoju arī video (OGG Theora) par to kā notiek darbs ar šo programmu.
Torez šķita, ka sataisīt šo jauno uzlaboto versiju prasīs kādas dažas nedēļas. Taču arhitekturālu izmaiņu sanāca pietiekami daudz, lai to realizēšana un debugošana mazliet ievilktos. Kas ir mainījies, kopš pēdējās publiskās versijas, kas pieejama no QGIS pluginu repozitorija?
Diezgan daudz “zem vāka”. Taču dažas detaļas varētu būt interesantas palielam cilvēku skaitam – daudzprocesoru sistēmu atbalsts ir pārrakstīts tā, lai spētu darboties arī zem ne *nix sistēmām. Agrākā realizācija balstījās uz improvizētu shell job control, kas zem Windows, protams (kā vairums noderīgu shell lietu), nepastāv. Līdz ar to, lai realizētu daudzkodolu atbalstu konvertācijas darbībām mazliet universālākā veidā, šī daļa tika pārrakstīta balstoties uz Python subrocess moduļa iespējām – procesi tiek palaisti vienādi uz visām sistēmām. Ir izlabotas arī ne mazums kļūdu, kas padarīja pluginu faktiski darboties nespējīgu uz Windows, dažādu abpusēji tizlu iemeslu dēļ. Nu vismaz uz manas XP darba stacijas tagad tā lieta iet:)
Arī konvertācijas un piramīdu būvēšanas metodes ir nedaudz mainījušās un ir veikti daži nelieli kosmētiski uzlabojumi priekškonvertācijas dialogam (pašam pirmajam) – vairs nerādās mani vecie testēšanas ceļi un (strarp)rezultātu izvades direktorijām nosaukumi tiek piedāvāti automāiski.
Cita lieta, ko var zināmā mērā uzskatīt par regresiju ir progresa rādītāja likvidēšana. Bet tas uz labu;) Iemesls tam ir, tas ka kaut kādu (visticamāk) QT gļuku dēļ progresa logs netika pārzīmēts biežāk nekā tika, lai gan dati widgetam tika nodoti. Tāpat arī konstanta atjaunošana padara dažas citas izstrādes darbības ķēpiskas. Tātad – ja interesē cik tālu ir ticis konvertators un piramīdu ģenerators, skatamies logā (dmja.log darba direktorijā) vai arī skatamies pēc failu skaita rezultātu direktorijā(s). Vienkārši un pietiekami adekvāti ja tiek apstrādāts liels apjoms failu. Ja slinkums skatīties, vienkāršī atsājam šos procesus uz nakti/pusdienlaiku/tējas krūzi un neispringstam. Vēl jo labāk – uzrakstiet kāds labāku progresa indikatoru, jo iespējams, ka gļuks, kas man traucēja to izdarīt QT vairs nepastāv.
Tāpat ir mainījusies arī savietojamība ar QGIS – šī jaunā 1.xx sērija atbalsta jauno QGIS 1.0 versiju. Starp 1.0 un iepriekšējām QGIS versijām ir notikušas izmaiņas pluginu API, kas nozīmē, ka vecā plugina versija darbojas uz dažām vecajām QGIS versijām, savukārt jaunā uz 1.x versijām. To ir vērts atcerēties, ja ielādējot pluginu neatjaunota QGIS instalācijā sāk mesties ārā Python kļūdas. Tas ir pirmais kas jāizdara – jāatjauno QGIS.
Nenoliedzami pie šīs lietas varētu strādāt vēl un vēl. Taču tā pilda savas funkcijas tik cik man tās pašam ir (bijušas) vajadzīgas. Tieši tādēļ šī programma ir atvērta. Lai uzlabojumus ieviestu arī citi jau atvērtā un arī lietotājiem draudzīgākā veidā – caur gisnet.lv piedāvāto Trac vidi.
Lai veiksīgi strādātu ar lieliem karšu apjomiem ir jāzin šis un tas, kas nesatilps šī nelielā raksta ietvaros, tādēļ ir izveidota wiki lapa pluginam, kurā ir garāks apraksts par tā instalāciju, lietošanu un īpatnībām.
Lai ātri velkas!
a) vai ta viss jau nav iesiets? :) b) ja jau pastāv sejas atpazīšanas algoritmi (google picasa albumi) un panorāmu līmēšana no daudz fotogrāfijām (autopano) tad jau teorētiski tas būtu iespējams. praktiski tas būtu muļķīgi izgāzt tik daudz laika fīčai ar minimālu atdevi. c) starp citu ar iepriekšējo versiju sanāca 7 sek uz vienu lapu, tagad izskatās mazāk kā 4 varētu būt. 50% ātrāk – pat ļoti neslikti.
“…teorētiski tas būtu iespējams” – tb atpazīt stūrus
a) nē, diemžēl nav:) psrs topenes nav vienīgais, kas jāsien. bez tam arī tām agrāko laiku skenu kvalitāte ir ļoti zema – vietām nevar horizontāles izšķirt, utml. domāju, ka arī 90tajos cilvēki ticēja, ka ta nu vienreiz visu ieskenēs un tad būs miers, bet diemžēl tas nav noticis vēl joprojām. nenoliedzami, ka liela daļa no šīm aktivitātēm ir saistīta ar arhivēšanu, lielo bibliotēku projektiem utml. tomēr joprojām arī citur pasaulē skenēšanu un vilkšana koordinātās ir izplatīta atrakcija, dažādām vajadzībām, cik var spriest pēc forumiem.
b) teorētiski iespējams, bet ne praktiski. tev pilnīga taisnība par laika izgāšanu ar minimālu atdevi – darbs, kas būtu jāiegulda lai tas darbotos neattaisnotos, īpaši jau, ja kā pats raksti tagad ir 4 sekundes uz stūri. taisnība – autopano-sift tipa tehnoloģija varētu ļoti labi tikt izmantota savietojot jau agrāk skenētu materiālu, kas jau ir ievilkts pareizi, ar jaunu (augstākas kvalitātes) skenējumu. sift viņus savietotu un tad varētu no vecā materiāla stūriem paņemt koordinātas priekš jaunā. tas būtu iespējams. bet agrāk nepiesaistītam materiālam atpazīt stūrus? atpazīt kur bildē ir seja un ka tās statistiskais raksts ir savādāks nekā citām sejām ir viena (relatīvi vienkārša) lieta. atpazīt kartes rāmi, to ka tam var būt vismaz 3 rāmji (ar dažādiem izskaistinājumiem) no kuriem vajadzīgi ir stūri tikai vienam iekšējām un ņemt vērā to, ka rāmjā malām var būt bojājumi materiāla vecuma dēļ, skenera defektu dēļ, nestabils krāsu diapazons utml… tā ir pilnīgi cita lieta. tagad iedomāsimies, ka šāds risinājums ir piespiests strādāt. visiem šādiem machine vision risinājumiem ir pieļaujamās kļūdas procents. iedomāsimies nereāli labi risinājumu ar 98% pareizi detektētiem stūriem. ja tev ir 1000 lapu (~visa latvija 25K mērogā) tad jārēķinas ar 20 lapām, kas būs ievilktas garām. vienīgais veids, kā tās atrast ir veikt vizuālo kontroli jau referencētām lapām…kas basically nozīmē, ka tev jāiet pāri visām anyway! šis te fakts padara šāda risinājuma radīšanu bezjēdzīgu jau sākumā, jo nozīmē obligātu vizuālo kontroli. skatoties no šāda viedokļa – klikšķinot stūrus šī te kontrole notiek reizē ar referncēšanu. protams, pastāv iespēja, ka neapzinoties nospiedīsi kādu stūri garām. bet tā ir daudz mazāka un pēdējo stūri var atcelt ar labo peles pogu. praksē es nedomāju, ka lietojot pašreizējo risinājumu un normāli strādājot var pielaist vairāk kā dažus stūrus uz dažiem tūkstošiem lapu. diez vai.
c) patiess prieks dzirdēt tik nereāli labus skaitļus. ātrāk par 4 nav iespējams, manuprāt, jo tas jau nozīmē, ka sekunde uz stūri – kaut kāds laiks jau ir vajadzīgs gan cilvēka reakcijai gan datoram zoomēšanai:))) bet nu vienalga forši!!! laiks gan parasti ir tieši saistīts ar lapu pikseļu apjomu – 100-300 megapikseļu lapām diez vai 4 sekundes sanāktu;)