A-t-t-e-n-t-i-o-n . . . I-c-e-e-v-e-r-y-w-h-e-r-e . . . W-a-y-n-e-h-e-r-e-p-r-a-t t-d-o-e-s-n-t-a-n-s-w-e-r . . . W-a-y-n-e-h-e-r-e-c-o-m-e-i-n-m-o-m-s-s-e-n-c-o-m-e-i-n . . . M-o-m-s-s-e-n-m-o-m-s-s-e-n-m-o-m-s-s-e-n-c-o-m-e-i-n m-o-m-s-s-e-n-m-o-m-s-s-e-n-m-o-m-s-s-e-n . . .

Par izejas materiālu tika ņemts jau labi pasen tapināts drumlina modelis, kura horizontāles drukājam darbiņam un rīcībā esošajam materiālam piemērotā mērogā, un varam sākt darboties.

Sākums.

Pārējam vien vajag nedaudz roku veiklības šķēres, koppapīru, adatatiņas un līmi. Visa darba apjomā būtu labi izmantot viena biezuma kartonu, mūsu gadījumā tas neizdevās.

Te nu nedaudz no procesa un necilais iznākums.

Sākums un starta materiāls -izdrukātas horizontāles, koppapīrs, un darbarīki :)

Necilais rezultāts

Precizitāte nav šī modeļa stiprā puse.

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…

PGCon 2009

Pirmā PostgreSQL konferences diena aizritējai visai mierīgi ar aptuveni 60-70 dalībniekiem.

Pirmais uzstājās Stephen Frost ar prezentāciju PostgreSQL Access Controls.  Frosts pats ir viens no PostgreSQL attīstītājiem, kurš piedalījies šo kontroles metožu programmēšanā. Prezentācijas laikā tika aplūkotas autentifikācijas  metodes, lietotāju lomas un autorizācijas metodes. Pirmējā vairāk skāra serveru konfigurāciju un komunikācijas, ar ko īpaši nav nācies nodarboties, tamdēļ dzirdēto daudz nekomentēšu, lai ‘neiebrauktu auzās’. Varu vien secināt, ka autentifikācijas iespēju ir pietiekoši daudz un dažādu, lai apmierinātu katra vajadzības. Kam interesē sīkāk, tad pilno prezentāciju var atrast šeit. Stāsts par lietotāju ‘lomām’ (roles) bija visai interesants un lietderīgs, jo līdz šim nebiju vēl redzējusi sakarīgu un pilnvērtīgu lomu izmantošanu. Smalka PostgreSQL sistēma var sastāvet no vesela lomu koka, kur hierarhiski pakārtotas lietotāju un lietotāju grupu tiesības darboties iekš datubāzes. Autorizācija praktiski kontrolē, kādas darbības (apskatīt, ievietot vai labot datus) katrs lietotājs var veikt, kā arī kurā vietā (shēmā, tabulā un kolonnā (junums PostgreSQL 8.4 ) ) darbības atļautas.

‘PostgreSQL access controls’ ir salīdzinoši vienkārša lieta. Īsts izaicinājums  ir datubāzu sistēmas uzstādīšana un konfigurēšana tā, lai tā darbotos ar maksimālo darbspēju un maksimali izmantotu pieejamos resursus. Josh Berkus prezentācija Performance Whack-a-Mole II aplūkoja, kā atrast ‘datubāzes lēnuma’ cēloņus jeb ‘kā nosist kurmi’.

Whack-a-Mole!

Berkus izdala 4 likumus, kas jāpatur prātā meklējot veiktspējas problēmas cēloņus:

1) The Layer Cake

Datubāzes sistēma parasti sastāv no 5 slāņiem (hardware, operating system, PostgreSQL, middleware, application)  gluži kā kārtainā kūka nevis no PostgreSQL vienas pašas. Tādēļ visbiežāk datubāzes ‘lēnuma problēma’ nav PostgreSQL problēma, bet vaina drīzāk slēpjas kādā citā no atlikušajām 4 komponentēm.

2) Hockey Stick

Mazāk par 10% ‘kurmjiem’ ir atbildīgi par 90% datubāzes darbspējas zudumiem.

3) The Whack-a-Mole Effect

Vienlaicīgi var ieraudzīt tikai vienu, lielāko, ‘kurmi’. Lai ieraudzītu nākošo problēmu parasti jātiek galā ar iepriekšējo, kas ir lielāka par sekojošo.

4) Dažādiem aplikāciju veidiem (web aplikācijā, Online Transaction Procesing, data warehousing) parasti ir dažādi ‘kurmju’ veidi, attiecīgi, nepieciešama atšķirīga pieeja.

Problēmas cēloņi jāsāk meklēt ievācot sīku informācija par visām sistēmas komponentēm, ne tikai PostgreSQL konfigurāciju. Tālāk ‘kurmji’ var tikt medīti ar dažādiem operētājsistēmas un PostgreSQL darbības analīzes rīkiem.

Šādi tādi lietderīgi operētājsisēmas darbības analīzes rīki (monitoringam un žurnalēšanai):  ps, pg_top, pg_bench, mpstat, vmstat, iostat, sar, dtrace. Test-programmas: dd, bonnie++, iozone, pg_bench, dbt2, pgUnitTest, EAstress, BenchmarkSQL.

PostgreSQL datubāzes darbības ieskatiem pieejamas dažādas funkcijas un statistiku apkopojošas tabulas: pg_stat_databse, pg_database_size,  pg_relation_size, pg_stat_activity, pg_locks, pg_stat_user_tables, pg_stat_user_indexes, pg_stat_bgwriter, pg_stat_statements, pg_stat_user_functions, pg_log, pg_fouine (log parser) ) u.c.

Izrādās, ka reizēm tomēr ir vērts izmantot EXPLAIN ANALYZE, jo tas palīdz ieraudzīt, kur PostgreSQL nepareizi aprēķina tabulu izmērus vai nepareizi uzstāda ‘izmaksas’, respektīvi, ir tiešā veidā redzams, kamdēļ vaicājuma izpildīšana aizņem tik daudz laika.

Cerams, ka drīzumā šī vērtīgā prezentācija parādīsies šeit, kur varēsiet smelties vairāk informācijas par PostgreSQL datubāzes analīzes rīkiem.

Nosit pats savu kurmi te!

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.

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.

Vienkāršām darbībām rīks ir lietojams tīri labi, tomēr pašlaik tas ir gana zaļš, lai nespētu aizvietot kaudzīti ar maziem jaukiem skriptiņiem, kas nodrošina liela apjoma datu apstrādes un pilnu ogr2ogr iespēju izmantošanu.

Par pamatu izvēlējos PSRS Ģenštāba topokartes M 1: 10 000, piesaistītas LKS-92 koordinātu sistēmai. Par garenprofila izejas datiem kalpo četri SHP faili:

1)  no topokartēm vektorizēta upe kā nepārtraukts līnijveida objekts ar sākumu lejtecē un beigām augštecē;

2) no topokartes izohipsām un ūdens līmeņa atzīmēm iegūtie punkti uz upes ar augstuma vērtībām;

3) ģeogrāfiskā piesaiste (tilti, ūdenskrātuves utt) kā punkti ar aptuveni no kartes nolasītām augstuma vērtībām;

4) novērojumu stacijas- punkti, kuriem no topokartes aptuveni nolasītas augstuma vērtības.

Visiem punktiem ir šādi atribūti-| Nosaukums | X | Y | H |, kur X, Y ir koordinātes un H ir augstums vjl pēc topokartes.

Kad tas ir izdarīts, ņemu veco labo AV3.x un izmantojot extensions xsecutil.ave (http://arcscripts.esri.com/details.asp?dbid=11709) iegūstu tabulu, kurā ir attālumi no grīvas pa upi līdz punktam (xsecutil apraksts). Turpat AV3.x samerdžoju tabulas un iegūstu šādu rezultātu:

Upes garenprofils

Piesaiste

Novērojumu stacijas

Tālāk no iegūtajiem datiem, izmantojot AV9.x  veidoju grafiku. Mana versija izskatās tā:

Pavadīju gandrīz dienu, kamēr ieguvu vēlamo grafika noformējumu. Pieminēšu dažas lietas, kas mani pārsteidza nesagatavotu:

1) liekot lābeļus uz asīm, gadījumā ja ir vairāki parametri uz vienas ass, ir svarīgi kā ir sakārtotas grafika sērijas. Man izskatās, ka attēlojas tās sērijas lābeļi, kura ir augstāk. Vai abi. :) Vārdu sakot- šitais mani ilgi mulsināja.

2) jāseko, lai paralēlajām asīm (X-bottom, X-top un Y-left, Y-right) būtu vienādas min un max vērtības. Savādāk grafikā būs nobīdes.

Izskatās apmēram šitā:

Man ilgi nepieleca, kāpēc neattēlojas pareizi, ja datu bāzē viss pa smuko sakrīt :)

Labprāt uzklausīšu ieteikumus kā to visu izdarīt elegantāk.