Lai arī konferences nosaukumā ir ietverts vārds “zinātniskā”, tomēr ziņojumu tēmas būs interesantas ne tikai zinātniekiem. Iespēja klausīties ziņojumus un ņemt dalību diskusijās ir visiem interesentiem, kas ieradīsies uz pasākumu.

Laipni lūgti visi interesenti, jo konferences apmeklēšanai ierobežojumu nav. Lai arī nosaukumā ir vārds “zinātniskā”, diskusijas par un ap ģeomātiku var būt arī nezinātniskas.

Papildināts.
Konferences tēžu krājums ir pieejams LU ĢZZF mājas lapā (11,3 MB PDF). Savukārt ar prezentācijām (pagaidām) var iepazīties LU 69. konferences lapā.

Savukārt runātājiem līdz 8. decembra 16:00 jāiesūta savi tēmas pieteikumi sekcijas vadītājam A. Markotam pa e-pastu Aivars.Markots@lu.lv (pieteikuma forma). Apstiprinātajiem runātājiem tēžu iesniegšanas termiņš – 2010. g. 28. decembris, 17:00.

ĢISnet.lv sekos līdzi turpmākajiem ar LU konferenci saistītajiem notikumiem. Un ko Tu stāstīsi citiem?

• Grigorijs GOLDBERGS – Arhitektūras objektu dokumentēšana ar fotogrammetriskām metodēm izmantojot amatieru kameras
• Andrejs GRIŠANOVS, Juris SOMS – ArcGIS programmproduktu pielietojums DRM ģenerēšanai un erozijas procesu modelēšanai: problēmas, ierobežojumi un risinājumi
• Lauma GUSTIŅA – Ar Latvijas purvu datu bāzes sagatavošanu saistītās kartogrāfiskās problēmas
• Jānis JĀTNIEKS, Māris NARTIŠS – No ArcSDE uz MapServer WMS, ĢZZF pieredze un ieguvumi
• Jānis JURGELĀNS, Agnis REČS – Siguldas pilsētas poligonometrijas tīkla analīze LATPOS sistēmā
• Kārlis KALVIŠKIS, Brigita LAIME, Didzis TJARVE – MODIS reģistrēto attēlu izmantojamība piekrastes biotopu izmaiņu novērtēšanā
• Jānis KAMINSKIS – Ģeoīda modeļa attīstība ģeodēzijas darbos
• Aivars MARKOTS, Agnis REČS – Ģeodēziskā atbalsta punktu tīkls Lodesmuižā, stāvoklis un perspektīvas
• Indra MURZIŅA, Arvīds OZOLS – Valsts ģeotelpiskie pamatdati. Šodiena un rītdiena.
• Agnis REČS, Aivars MARKOTS, Māris NARTIŠS – Topogrāfiskās kartes m 1:10 000 reljefa piemērotība Baltijas jūras stadiju pētniecībā
• Agnese VĒZE – Topogrāfisko karšu pieejamība mūsdienu sabiedrībai

Visi ģeomātikas atbalstītāji laipni gaidīti klausītāju rindās, kā arī prezentācijām sekojošajās diskusijās.

Nozīmīgi termiņi:
2009. gada 1. decembris.
Reģistrācija, referāta vai stenda referāta tēmas iesniegšana (1. pielikums), sūtīt uz e-pasta adresi maris.nartiss@gmail.com
2009. gada 21. decembris.
Referāta kopsavilkuma (tēžu) iesniegšana (paraugs 2. pielikumā), sūtīt uz e-pasta adresi maris.nartiss@gmail.com

Pārējo informāciju lūdzam skatīt pievienotajā apkārtrakstā. Idejas referātu tēmām var smelties iepriekšējo konferenču aprakstos, kur ir pieejama arī informācija par nolasītajiem referātiem. Informācija par šī gada konferences tēmām tiks publicēta tiklīdz ko būs saņemti visi pieteikumi dalībai.

Ar cieņu,
Māris Nartišs

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!

Vakar tika izlaista PostgreSQL 8.4 beta2 versija, stabilā versija sagaidāma aptuveni jūlijā. Robert Treat referāts “No More Waiting: A Guide To PostgreSQL 8.4″ sniedza ieskatu PostgreSQL 8.4 jaunumos, kas izklausījās visai ‘garšīgi’. Šeit daži no tiem:

Performance

• Visibility maps – VACUUMs notiks tikai uz tām datubāzes lapām, kur kopš pēdējā VACUUM notikušas izmaiņas;
• Default stats target – parametrs default_statistics_target=[0...100] palīdzēs noteikt, cik ļoti Postgrei jāanalizē konkrētā tabula. Skaitlis reprezentē analizējamo paraugu skaitu, kad tiek ievākta statistika, u.c.

Administration

• jaunas 'free-space-maps' - Postgres monitorēs brīvo diska vietu, vajadzēšot retāk pārstartēt serveri;
• pg_terminate_backend(pid) - drošāks veids kā nogalināt nevēlamus procesus nekaitējot pašāi datubāzei;
• stats temp file - pgstat.stat ir visaizņemtākais fails datubāzē, dažreiz tik aizņēmts, ka bremzē visu citu. Tagad tam būs pašam sava direktorija Postgres datu direktorijā;
• kolonnu līmeņa privilēģijas;
• atsevišķa vaicājumu statistika;
• Auto Explain - uzrādīs vaicājuma plānojumu reizē ar tā izpildījumu;
• Explain Verbose uzrādīs iesaisītās kolonnas, u.c.

PSQL

• funkciju rediģēšana ar \ef manafunkcija (tiks atvērts editors kā vi);
• \dX atlasīs tikai lietotājaveidotos objektus, \dXS atlasīs sistēmas objetus;
• \dT+ uzrādīs tabulas izmērus, u.c.

Development

• Jauna rank() funkcija;
• LIMIT varēs būt balstīts uz apakšvaicājumu;
• Teksta meklēšāna pēc daļvārdien, piem., 'maj*';
• Jauna TABLE komanda, kas vienlīdzīga ar SELECT * FROM;
• generate_series() funkcija laika  sēriju ģenerēšanai, u.c.

Procedures

• Būs pieejams CASE vārdiņš (no sērijas IF... THEN ... ELSE...);
• Funkcijas ar mainīgu argumentu daudzumu (srgumenta veids "variadic");
• Funkciju argumentiem varēs būt noklusētās vērtības, u.c.

Upgrades

• Joprojām problemātiski, bet top pg_migrator.

Lūk šeit jau kāds fanātiķis ir apkopojis PostgreSQL 8.4 fīčas: http://www.depesz.com/.

Tālāk noklausījos Luis Bueno "Saving the Amazon with PostGIS", bet īpaši apmierinājuma nebija.  Stāsts bija ļoti vienkāršs, tomēr izdevās noskaidrot, ka Brazīlijā visām valdības iestādēm jālieto FOSS risinājumi (nu ne gluži likumiski, bet tā ir ļoti stipra rekomendācija). Brazīlijai ir grūti izveidot valsts ĢIS datubāzi, jo džungļos nav datortīkla caur kuru sajūgt kopā visus kompjus. Protams, atkal tika pacelta labi zināmā problēma, ka cilvēki neuzticās FOSS risinājumiem...

Greg Smith bija sagatavojis visai interesantu lasījumu par "Database hardware benchmarking". Stāsts par to, kā jātestē dzelži vēl pirms uz tiem tiek sainstalēti brīnumi un palaistas jelkādas aplikācijas. Tāpat jāpatur prātā, ka pārdevēji parasti melo un nekad nevar zināt, kas var tikt 'iesmērēts'.  Pērkot CPU un RAM smalki jārēķina, vai tiem sakritīs takts un frekvences, jo ja nesakrīt, tad kompis pazemina tās frekvences līdz līmenim, kurā sistēma var darboties sinhroni. Cik es nopratu, tad Postgres ir diezgan CPU rijīga. Cilvēki parasti sev nezinot apgriež savam kompim CPU jaudu paturot uz tā standartā ieinstalētās 'power management' sistēmas. Jā, tās taupa enerģiju, īpaši jau laptopiem, bet arī apgriež Postgres rociņas. Divi CPU ar vienādiem parametriem nebūt neveiks vienādu darbu. Kā likums, svaigāk izlaistie CPU ir jaudīgāki par vecajiem pat pie vienādiem specenes cipariem. Cietņi arī ir viltīgi. Dažādas sekcijas uz diska strādā dažādā ātrumā, jo tas cipars lielāks, jo lēnāks tas disks paliek. Fiksais gals ir diska sākumā, dibengals var būt pat 2x reizes lēnāks. Sākumgalā parasti tiek ieinstalēta operētājsistēma, kamēr disks ir tukšs, tikmēr kompis strādā raiti, jo visi faili ir fiksajā galā, bet kad faili sāk parādīties arī diska lēnajā galā, tad kompis paliek lēnāks (tāpēc tas kompis paliek tik lēns, kad ir pilns ar failiem - samazinās darbības videjais ātrums). Nu, lūk, ja gribās no sistemas dabūt ārā maksimālo, tad visgudrāk ir nogriezt diskam sākumgalu un glabāt datubāzi tur, bet lēno galu vienkārši norakstīt...

Tālāk Steve Singer nedaudz pastāstīja par "OpenStreetMap with PostgreSQL". OSM sniedz brīvību publicēt, izplatīt, pārdot, stilizēt un rediģēt kartes pēc sirds patikas. OSM pamatā ir ideja par to, ka ja vien katrs no mums  uzzīmētu savu mikrorajonu, tad kopā mēs varētu nokartēt visu pasauli. OSM drīzumā tiks papildināta ar TIGER (USA), GeoBASE (Canada) un NAND (the Netherlands) datiem. Līdz šim OSM izmantoja MySQL, bet nu jau kā mēnesi OSM dzīvo iekš Postgres. Pārvākšanās zināmā mērā notika tamdēļ, lai lietotāji varētu izmantot PostGIS. Diemžēl, lai izmantotu PostGIS, jāizveido pašam sava datubāze uz sava datora, kas aizņem ap 100 GB un turpina augt. OSM ik nedēļu eksportē datubāzei svaigi pievienototos datus, kas piejami šeit. Izmantojot OSMOSIS (piem, rīku osm2pgsql) OSM datus var ielādēt savā datubāzē. OSM datus iespējams izmantot arī maršrutēšanā, tikai OSM ne vienmēr ir 'pilnīga'.

Leo Hsu un Regina Obe šobrīd raksta grāmatu "PostGIS in Action", kas oficiāli tiks izdota 2010.gada janvārī. Pašlaik  internetā ir iespējams abonēt un lasīt grāmatu nodaļu pa nodaļai līdz ko tās sarakstītas. Pirmo nodaļu var lasīt par velti šeit. Hsu un Obe uzstājās šai konferencē  ar referātu "Spatial Analysis with PostGIS". Hsu un Obe lietišķi uzsver, ka PostGIS datubāze var tikt izmantota dažādām vajadzībām:

1) datu krāšanai, apkopošanai;
2) datu piegādei citām aplikācijām (backend);
3) ģeogrāfiskajai analīzei;
4) datu ekstrahēšanai, reproducēšanai un izplatīšanai;
5) datu labošanai un papildināšanai.

Hsu un Obe demonstrēja visai  sarežģītus PostĢIS vaicājumus. PostĢIS atšķirībā no ArcĢIS ļauj sajūgt ķēdē kaudzi ar dažādām funkcijām, tā kā to, kas ArcĢISā jādara ar 10 rīkiem, pieseivojot starprezultātus, PostĢISā var izdarīt vienā lielā pūtienā. Arī rezultāti tiks atgriezti ātrāk, jo ir iespējams izmantot indeksus uz dažādām kolonnām. Šobrīd PostGIS atbalsta tikai vektordatus, bet pa neoficiāli kanāliem tika ziņots, ka jau ir iespējams izmēģinot jaunos PostGIS rīkus rastra datiem.

Šī konference tiek filmēta un visi materiāli tuvākajā laikā tiks publicēta PgCon mājas lapā vai vismaz tur parādīsies info par to, no kurienes materiāli ir lejuplādējami.

Vispār Skytools piedāvā vēl šādus tādus labumus, ar ko vairāk var iepazīties http://wiki.postgresql.org/wiki/Skytools

PGQ apmācība te: http://wiki.postgresql.org/wiki/PGQ_Tutorial

Pēcpudienas sadaļa  izvērtās nedaudz ‘šizīga’. Joshua Tolley prezentācija “Writing a Procedural Language” sniedza ieskatu jaunā procedurālajā valodā PL/LOLCODE. Šī valoda izsktās kā ļoti nepareiza angļu valoda, izrauta no kaut kāda baismīga čata. Pie labākās gribas nevaru saņemties, lai sniegtu pozitīvas atsauksmes par šo ‘marasmu’.

LOLCODE:

“This is a love letter to very clever people who
are slightly bored. I had no idea there were so
many of us out there.”

- FAQ, lolcode.com

Ha! Skatoties uz LOLCODE varētu piekrist, ka daži cilvēki ir pamatīgi nogarlaikojušies, bet es neteiktu, ka te izpaužas diža gudrība. LOLCODE ir bērnu šļupstu kompilēšana. Cilvēki ar šo valodu nodarbojas tikai tīras garlaicības pēc…

Viens PL/LOLCODE piemērs:

BOTH SAEM ANIMAL AN “CAT”, O RLY?
YA RLY, VISIBLE “J00 HAV A CAT”
MEBBE BOTH SAEM ANIMAL AN “MAUS”
VISIBLE “JOO HAV A MAUS? WTF?”
NO WAI, VISIBLE “J00 SUX”
OIC

Šis piemērs drusku sakarīgā valodā izklausās apmērām tā:

animal = cat, TEST
IF TRUE THEN PRINT  “J00 HAV A CAT”
IF ANIMAL = “MAUS”
PRINT “JOO HAV A MAUS? WTF?”
IF FALSE THEN PRINT “J00 SUX”
???

Jebkādā gadījumā, par LOLCODE lietderīgumu spriediet paši…