ubuntu-party a Schio | pubblicati i video

Gli organizzatori dell’Ubuntu-party che si è svolto a Schio (Vicenza) lo scorso 30 aprile e 1 maggio hanno pubblicato su Vimeo i video dei talk.

Tra i tanti c’è anche il mio soporifero intervento su “Openstreetmap – La mappa del mondo creata dal basso”; se avete difficoltà a dormire e cercate un’alternativa alla conta delle pecore andate qui :-), sarò lieto di conciliarvi…

Buona notte.

imagemagick | un coltellino svizzero per le immagini!

Imagemagick, una suite open source per la manipolazione di immagini (creazione, modifica, composizione, conversione,…) torna sempre utile!

Raggruppo qui alcuni semplici comandi indispensabili in operazioni che non svolgo abitualmente ma quando servono….:

Per ridimensionare tutte le immagini contenute in una directory utilizziamo il comando “mogrify” (che fa parte del pacchetto imagemagick).

– Ecco un esempio che mostra come ridurre del 50% le dimensioni di tutte le immagini contenute nella directory “image”.

$ mogrify -resize 50% *.JPG

Otterremo così tutte le immagini ridotte della metà (in termini di dimensioni width x height).

– Per ridimensionare una serie di immagini (in formato JPG per esempio) impostando solo la larghezza a 300 pixel (l’altezza viene adattata proporzionalmente):

$ mogrify -resize 300 *.JPG

– Se volessimo invece convertire una serie di immagine dal formato png al formato jpg:

$ mogrify -format jpg *.png

– Per ritagliare un’immagine si usa il tool “-crop“. Nell’esempio riportato sotto viene tagliata un’immagine con dimensione di ritaglio di 420×580 e con offset dai bordi sinistro e superiore rispettivamanete di 360 e 5 pixel.

$ convert nome_immagine.PNG -crop 420×580+360+5 nome_immagine_crop.PNG

Ecco uno schema dell’esempio:

immagine con misure (in pixel) del ritaglio. L’immagine originale era di 1158×583 pixel ed è stata ritagliata una porzione di 420×580 pixel

openlite | migrazione tra database in pochi click

Il papà di SpatiaLite, Alessandro Furieri, ha lanciato un altro ottimo tool: OpenLite. Si tratta di uno strumento leggerissimo e semplice per migrare database (interi o in parte) tra SpatiaLite, PostGIS e MySQL.

E’ disponibile in forma sorgente oppure binaria per Windows ed è accompagnato da una semplice ma esaustiva guida che si trova alla stessa pagina del progetto.

Ho provato ad installarlo dai sorgenti su Ubuntu 10.10. Ecco una sisntesi dei passaggi e delle prove fatte:

– scaricare i sorgenti da qui;

– scompattare tutto in una directory di lavoro; nel mio caso in “/home/sit/src/openlite-0.0.1

– ci sono dipendenze da soddisfare: libspatialite e wxWidgets. Le installiamo via sudo apt-get install nome_pacchetti o via synaptic

– da riga di comando si accede alla directory interessata:

cd /home/sit/src/openlite-0.0.1

– lanciare in sequenza i tre canonici comandi:

  ./configure

  make

  sudo make install-strip

– a questo punto il programma è installato. Lo lanciamo da riga di comando con:

sit@dell1530:~$ openlite

– si presenta così:

OpenLite - come si presenta

la semplicità dello strumento si nota subito


– è necessario stabilire prima di tutto una connessione ad un db SQLite. Se ne esiste già uno colleghiamoci cliccando sul pulsante in alto a sx “Connecting an existing SQLite DB” e cerchiamo il DB interessato. In alternativa possiamo creare un DB nuovo cliccando sul secondo pulsante da sx “Creating a New (empty) SQLite DB”.

– in seconda battuta connettiamoci ad un atro DB. Nel mio caso ho provato con un DB PostGIS (PostgreSQL). Cliccare sull’icona con freccia azzurra e contenitore magenta “Connecting to PostgreSQL/PostGIS DBMS”. La prima volta che si tenta di connettersi ad un DB PostgreSQL viene chiedo di individuare la libreria necessaria. Nel nostro caso si tratta di “/usr/lib/libpq.so.5.2“. Questa impostazione viene salvata permanentemente ed ogni connessione successiva a DB PostgreSQ/PostGIS cercherà questa libreria. Nel caso si indicasse la libreria sbagliata viene restituito il messaggio “No PostgreSQL Client Library available … sorry
Connection impossible”. Per “sbloccare” la situazione ed impostare il percorso corretto alla libreria ci sono due alternative:

– alternativa 1 – brutale ma efficade:

– andare nella home directory
– lanciare il comando: ls -la
– dovremmo trovare un file nascosto chiamatto “.OpenLite” (è il file in cui vengono salvate le impostazioni permanenti)
– cancellare il file e ripartire.

– alternativa 2 – piu’ soft (ma non testata):

– andare nella home directory e aprire il file nascosto .OpenLite con: $ nano .OpenLite

– modificare la riga “PostgisLibraryName=libpq.so.5.2” indicando la libreria corretta.

– rilanciare openlite e ripartire.

Una volta individuata la libreria compare un popup per l’inserimento del percorso al DB e delle credenziali di accesso.

connessione a PostgreSQL

Connessione a DB PostgreSQL/PostGIS

Nella parte dx del pannello vengono elencate tutte le tabelle presenti del DB PostgreSQL. Selezionare con click sx la tabella che si vuole trasferire al DB SQLite e poi click dx. Compare un menù contenstuale: scegliere la voce “Select for data transfer”. Poi click dx sullo schema che contiene la tabella in questione (nel nostro caso “public“) altrimenti non è possibile avviare il tarsferimento. Fatto questo verrà abilitato un nuovo pulsante “Start data transfer” che si trova a sx del pulsante “About…”.

– Click sul pulsante indicato.

– Fatto: in questo modo avviene il trasferimento della tabella in questione al DB SQLite che comparirà dopo qualche secondo (a seconda delle dimensioni) nella parte sx del pannello.

La tabella "areacirc" è stata trasferita con successo

Ushahidi

La definizione che capeggia nella home page del progetto è:

We are a non-profit tech company that develops free and open source software for information collection, visualization and interactive mapping

Ho sentito parlare per la prima volta di Ushahidi nel 2010 (inizio) quando Napo mi ha girato un link a riguardo.

Mi sono subito cimentato per installarlo ma per mancanza di tempo non ho avuto modo di arrivare alla fine e di testarlo.

Per ora inserisco questo video (tratto dal sito stesso del progetto)

ma appena riesco a cimentarmi meglio vorrei riportare un resoconto.

Nel frattempo ho provato la versione crowdmap che consente di realizzare da subito un sito proprio confezionato con una applicazione dimostrativa delle funzionalità dei Ushahidi. Tostissimo! Qui il test che ho fatto.

2010 in review

Mi è arrivata questa review sul blog dalla redazione di WordPress….la pubblico as is…. :-).

————————————————————————-

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

Featured image

The average container ship can carry about 4,500 containers. This blog was viewed about 14,000 times in 2010. If each view were a shipping container, your blog would have filled about 3 fully loaded ships.

In 2010, there were 17 new posts, growing the total archive of this blog to 75 posts. There were 13 pictures uploaded, taking up a total of 1mb. That’s about a picture per month.

The busiest day of the year was February 2nd with 144 views. The most popular post that day was Conversione di uno SHP da coordinate WGS84 a Gauss-Boaga Fuso Ovest (GB Fuso Ovest -> WGS84 nel commento).

Where did they come from?

The top referring sites in 2010 were google.it, search.conduit.com, freegis-italia.org, it.wordpress.com, and esridipendente.it.

Some visitors came searching, mostly for coordinate wgs84, grass kml, formato gml, flavio rigolon, and conversione coordinate wgs84.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Conversione di uno SHP da coordinate WGS84 a Gauss-Boaga Fuso Ovest (GB Fuso Ovest -> WGS84 nel commento) March 2009
6 comments

2

Mapnik | un tiles cacher di dati OSM April 2009
2 comments

3

aggiornare data e ora di sistema su Debian February 2009

4

PHP | Gestione di “submit” multipli in un singolo form February 2009

5

Debian | creare un live CD March 2009

django | somma di campi

Supponiamo di avere una tabella contente i valori dei consumi energetici di un particolare dispositivo.

In particolare abbiamo inserito un campo (somma) che sarà popolato con il risultato ottenuto dalla somma di altri 4 campi. In questo modo ad ogni inserimento (Admin) di dati relativi ai primi 4 campi (rientranti nella somma) e dopo avere cliccato il punsante “Salva” o “Salva e continua le modifiche” il campo “somma” apparirà popolato con il valore somma.

Ecco un esempio di strutturazione della class nel file models.py.

class ConsumiIlluminazione(models.Model):
 """Tabella consumi illuminazione"""

 utente = models.ForeignKey(UtenteIlluminazione)
 campo1 = models.IntegerField(null=True, blank=True)
 campo2 = models.IntegerField(null=True, blank=True)
 campo3 = models.IntegerField(null=True, blank=True)
 campo4 = models.IntegerField(null=True, blank=True)
 somma = models.IntegerField(null=True, blank=True)
 def calcoloTotale(self):
  self.somma = self.campo1 + self.campo2 + self.campo3 + self.campo4
 def save(self):
  self.calcoloTotale()
  super(ConsumiIlluminazione, self).save()
 def __unicode__(self):
  return "%s" % (self.utente)
 class Meta:
  ordering = ["utente"]
  verbose_name_plural = "Consumi illuminazione"

geodjango | primo approccio

GeoDjango è un add-on per Django che consente di gestire e manipolare dati geografici all’interno di un progetto django.

Questo post riassume i passi iniziali per implementare una class geografica in una applicazione….spero di espandere il post non appena avro’ fatto qualche test ed esperienza ulteriore. Andiamo per step:

1. Creazione del db geografico (nel mio caso si tratta di un db Postgis).

Se ancora non esiste creiamo un template per i db gis (sarà molto comodo anche in futuro):

– autenticarsi come utente postgres ed entrae in un template (esempio il “template1”):

postgres@debian:/home/sit$ psql template1;

–  creare un nuovo db che chiameremo template_gis sul modello del template0;

postgres=# CREATE DATABASE template_gis template=template0;

– uscire da psql e creare il linguaggio per il db appena creato:

postgres@debian:/home/sit$ createlang plpgsql template_gis

– poi:

postgres@debian:/home/sit$ psql -f /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql -d template_gis

– popoliamo la tabella spatial_ref_sys:

postgres@debian:/home/sit$ psql -d template_gis -f /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql

– entrare nuovamente in un template e indicare che template_gis è un template:

postgres=# UPDATE pg_database set datistemplate=’t’ WHERE datname=’template_gis’;

– a questo punto possiamo creare il nostro db per django usando il template_gis appena creato:

postgres=# CREATE DATABASE energia_django template=template_gis OWNER sit;

– ci spostiamo all’interno del database appena creato:

postgres=# \connect energia_django

– poi è necessario dare i GRANT di SELECT sulla spatial_erf_sys e ALL sulla geometry_columns:

postgres=# GRANT SELECT on spatial_ref_sys to sit;

postgres=# grant ALL on geometry_columns to sit;

2. Configurazione del progetto django (geodjango)

Andiamo all’interno del nostro progetto django (il progetto sia chiama “energia” e una prima applicazione si chiama “manager”)

– Configurare il file settings.py modificando le impostazioni del database come segue:

DATABASES = {
    'default': {
         'ENGINE': 'django.contrib.gis.db.backends.postgis',
         'NAME': 'energia_django',
         'USER': 'sit',
     }
}

Aggiungere:

django.contrib.gis tra le INSTALLED_APPS

3. Preparazione dei dati geografici

Partiamo da dati in formato SHP (nel nostro caso si tratta di uno SHP di punti chiamato “quadri.shp”.

– creare una directory chiamata “data” all’interno della nostra applicazione:

$ mkdir manager/data

e salviamo al suo interno gli SHP relativi:

– con ogrinfo ispezioniamo lo SHP:

$ ogrinfo -so quadro.shp quadro

ottenendo una lista di dati relativi allo SHP (tra cui il numero di feature, SRS, nomi dei campi). Questo è molto importante per creare la class (nel file models.py) che andrà ad “accogliere” i dati. Definiamo quindi la class nel nostro models.py dell’applicazione.

class QuadroIlluminazione(models.Model):
 kp = models.IntegerField()
 numnuovo = models.CharField(max_length=5)
 via = models.CharField(max_length=30)
 codanagr = models.IntegerField()
 norma = models.CharField(max_length=2)
 regolato = models.CharField(max_length=2)
 contenel = models.CharField(max_length=15)
 contpote = models.CharField(max_length=20)
 elettronic = models.CharField(max_length=2)
 ncliente = models.CharField(max_length=10)
 gmrotation = models.FloatField()
 geom = models.MultiPointField(srid=3003)
 objects = models.GeoManager()
 class Meta:
 verbose_name_plural = "Quadri illuminazione pubblica"

 # Returns the string representation of the model.
 def __unicode__(self):
 return self.numnuovo

NB: attenzione all’indentazione; in questo post puo’ non essere corretta; vedere la guida di python per una corretta scrittura del codice)

Abbiamo definito la nuova tabella che conterrà i dati geografici con gli stessi attributi trovati nello SHP. Gli unici due campi che vengono aggiunti sono “geom” e “objects“.

– Controlliamo che tutto sia a posto prima di generare il DB con:

$ python manage.py sqlall manager

l’output è simile a questo (la parte finale):

……………..

CREATE INDEX “manager_contrattoaperturagasnaturale_utente_id” ON “manager_contrattoaperturagasnaturale” (“utente_id”);
CREATE INDEX “manager_contrattofornituragasnaturale_utente_id” ON “manager_contrattofornituragasnaturale” (“utente_id”);
SELECT AddGeometryColumn(‘manager_quadroilluminazione’, ‘geom’, 3003, ‘MULTIPOINT’, 2);
ALTER TABLE “manager_quadroilluminazione” ALTER “geom” SET NOT NULL;
CREATE INDEX “manager_quadroilluminazione_geom_id” ON “manager_quadroilluminazione” USING GIST ( “geom” GIST_GEOMETRY_OPS );COMMIT;

– a questo punto sincronizziamo il DB con:

$ python manage.py syncdb

compariranno una serie di messaggi (con la richiesta di creazione del superutente). alla fine avremo il nostro db pronto.

4. Ridefinizione del models.py

Il models.py deve essere modificato inserendo classe e dizionario. Una funzione ci viene in aiuto per automatizzare il processo:

$ python manage.py ogrinspect manager/data/quadro.shp QuadroIlluminazione –srid=3003 –mapping –multi

Questo comando produce in output la definizione della class e del dizionario necessario per il nostro layer geografico. Tale output puo’ essere copiato/incollato nel nostro models.py

5. Caricamento dei dati del database

Per il caricamento dei dati è necessario creare un modulino python per l’import. Per farlo creare un file chiamato “load.py” e salvarlo all’interno della nostra applicazione. Copiare al suo interno il seguente codice:

import os
from django.contrib.gis.utils import LayerMapping
from models import QuadroIlluminazione

quadroilluminazione_mapping = {
 'kp' : 'KP',
 'numnuovo' : 'NumNuovo',
 'via' : 'Via',
 'codanagr' : 'CodAnagr',
 'norma' : 'Norma',
 'regolato' : 'Regolato',
 'contenel' : 'ContEnel',
 'contpote' : 'ContPote',
 'elettronic' : 'Elettronic',
 'ncliente' : 'Ncliente',
 'gmrotation' : 'GMRotation',
 'geom' : 'MULTIPOINT',

}

quadroilluminazione_shp = os.path.abspath(os.path.join(os.path.dirname(__file__), 'data/quadro.shp'))

def run(verbose=True):
 lm = LayerMapping(QuadroIlluminazione, quadroilluminazione_shp, quadroilluminazione_mapping, transform=True, encoding='iso-8859-1')
 lm.save(strict=True, verbose=verbose)

– Ora invochiamo la shell python per importare i dati mediante il modulo appena creato

$ python manage.py shell

Al prompt di python impartiamo i seguenti comandi (prima richiamiamo il modulo e poi la funzione di “load”):

>>> from manager import load
>>> load.run()

Seguirà una serie di messaggi di import (uno per ogni feature).

6. Caricamento del layer geografico

All’interno del file “admin.py” inserire le seguenti stringhe di codice:

from django.contrib.gis import admin
from manager.models import *
........
admin.site.register(QuadroIlluminazione, admin.GeoModelAdmin)

…to be continued as soon as possible