Archive for category mapping
Postgresql | Postgis | modificare i valori dei campi di una vista
Pubblicato da flaviorigolon in db-ing & geodb-ing, mapping il 31 ottobre 2011
Lavorando con Postgresql|Postgis mi capita spesso di avere delle tavole come viste “View” ottenute dal join di una tabella geomerica e di una tabella non-geometrica. Esempio: la tabella geometrica contiene poligoni (edifici) con un campo chiave (es= scheda); la tabella alfanumerica contiene tutti i dati relativi a quegli edifici + un campo chiave “scheda” come la prima.
Questo perché, in un lavoro svolto, un utente si occupava di gestire la parte geometrica (mediante QGIS) mentre un altro utente caricava i dati alfanumerici relativi ad un rilievo di edifici mediante interfaccia web (via PHP).
In un secondo momento quindi è stata creata una join fra le due tabelle in modo da generare tavole tematiche sulle condizioni e sull’uso di quegli edifici.
Ecco la View creata (siano “schede” e “schede_nogeom” rispettivamente la tabella geometrica e non-geometrica)
=> CREATE VIEW schede_cartogr AS SELECT scheda_nogeom.grado, scheda_nogeom.altezza, scheda_nogeom.volume, scheda_nogeom.piani, scheda_nogeom.note, scheda_nogeom.stcontetto, scheda_nogeom.punttetto, scheda_nogeom.stconprosp, scheda_nogeom.puntprosp, scheda_nogeom.stconserr, scheda_nogeom.puntserr, scheda_nogeom.stconsolai, scheda_nogeom.puntsolai, scheda_nogeom.stconmurat, scheda_nogeom.stcompl, scheda_nogeom.puntcompl, scheda_nogeom.d_uso_pint, scheda_nogeom.d_uso_pt, scheda_nogeom.d_uso_p1, scheda_nogeom.d_uso_p2, scheda_nogeom.d_uso_p3, scheda_nogeom.d_uso_p4, scheda_nogeom.d_uso_p5, scheda_nogeom.d_uso_compl, scheda_nogeom.d_uso_progetto, scheda_nogeom.d_uso_comp_grafica, scheda_nogeom.essenze_arboree, scheda_nogeom.emerg_arch, scheda_nogeom.h_pint, scheda_nogeom.h_pt, scheda_nogeom.h_p1, scheda_nogeom.h_p2, scheda_nogeom.h_p3, scheda_nogeom.h_p4, scheda_nogeom.h_p5, scheda_nogeom.vol_pint, scheda_nogeom.vol_pt, scheda_nogeom.vol_p1, scheda_nogeom.vol_p2, scheda_nogeom.vol_p3, scheda_nogeom.vol_p4, scheda_nogeom.vol_p5, scheda.area_gis, scheda_nogeom.foto1, scheda_nogeom.estratto_cartografico, scheda_nogeom.vol_residenza, scheda_nogeom.vol_comm_dir, scheda_nogeom.vol_artigianale, scheda_nogeom.vol_pubblico, scheda_nogeom.vol_misto, scheda_nogeom.puntmurat, scheda_nogeom.d_uso_vigente, scheda.gid, scheda.the_geom, scheda.scheda FROM scheda JOIN scheda_nogeom ON scheda.scheda::text = scheda_nogeom.scheda::text;
- Caricando questa vista in QGIS riusciamo quindi a consultare geometrie e tutti i valori colelgati. Ma se ad un certo punto voglio modificare un valore o alcuni valori della tabella? Abilitando l’editing sul layer “schede_cartogr” vediamo che possiamo modificare i valori ma al momento del salvataggio veniamo avvisati che non è possibile. Ci viene allora in aiuto la creazione di un RULE con istruzione “DO INSTEAD” in Postgresql . In sostanza si tratta di una regola che consente di modificare la (o le) tabelle origine agendo sulla vista.
In generale la sintassi è la seguente:
>= CREATE RULE nome_rule_da_creare AS ON UPDATE TO nome_della_view DO INSTEAD UPDATE nome_tabella_origine SET nome_campo=NEW.nome_campo WHERE campo_chiave=NEW.campo_chiave;
Ecco la definizione del RULE che ho usato:
=>CREATE RULE update_grado_schede_cartogr AS ON UPDATE TO schede_cartogr DO INSTEAD UPDATE scheda_nogeom SET grado=NEW.grado WHERE scheda=NEW.scheda;
D’ora in avanti possiamo modificare da QGIS il valore del campo “grado“; verrà aggiornato di conseguenza il valore della tabella originale.
importare dati da tabella QGIS a LibreOffice
Pubblicato da flaviorigolon in linuxing, mapping il 27 ottobre 2011
Se durante una sessione di lavoro con QGIS vogliamo eseguire un “copia/incolla” di dati da una tabella ad un foglio di calcolo LibreOffice puo’ succedere che i dati “incollati” presentino alcuni problemi. In particolare i dati numerici decimali (aree di oggetti poligonali per esempio) vengono mantenuti come “testo” e non numero con tutte le conseguenze negative del caso: se vogliamo fare una somma di valori ottenimao un errore.
Come fare per ovviare a tutto cio’?
Andiamo per punti:
- dalla sessione QGIS apriamo la tabella attributi del layer interessato, selezioniamo tutte o parte delle righe che ci interessano e clicchiamo sul pulsante “copia le righe selezionate nel blocco appunti” che si trova in basso a sinistra della tabella.
- apriamo una sessione di LibreOffice Calc e andiamo su “modifica > incolla” oppure “CTRL+V“;
- ci si presenta la finestra di impostazione dei dati di import che si chiama “Importazione testo” (lo vediamo scritto in alto sulla barra della finestra di popup stessa);
- su “Tipo di carattere” lasciamo “Unicode” come da default e poi scegliamo il simbolo di delimitazione (dovrebbe andare bene la “tabulazione” come proposto); a questo punto ci troviamo i nostri dati nel foglio di calcolo;
- Se schiacciamo contemporaneqmente “CTRL+F8” vedremo alcuni valori diventare blu. Sono i valori numerici. Il resto rimane nero (il testo). In verde eventuali valori calcolati da altri campi (ma essendo dati appena importati non avremo alcun campo di colore verde).
- Nel mio caso ho una colonna che riporta l’area di elementi poligonali e, ahimè, i suoi valori non diventano blu ma rimangono neri. Significa che sono dati importati come testo. Se infatti selezioniamo le celle interessate, tasdo dx e “Formatta celle…” vedremo che il tipo di dato è impostato su “testo”.
- Modifichiamo questa impostazione impostando su “categoria=numero” e “formato=standard”; in questo modo, tornando sul foglio di calcolo e selezionando una delle celle interessate vedremo che il valore indicato nella “riga di digitazione” presenta un’apostrofo “‘“all’inizio. Questo significa che la cella dovrebbe contenere numeri ma il valore inserito è un testo. Nel mio caso trovo: ’1011.15.
- Il problema sta nel fatto che il nostro separatore dei decimali è la virgola “,” mentre i dati incollati hanno importato come separatore il punto “.”.
- Basta fare un “trova e sostituisci” (CTRL+ALT+F) sulle celle interessate e sostituire il punto con una virgola.
- A questo punto vedremo automagicamente comparire i nostri valori in blu (ergo sono diventati numeri a tutti gli effetti).
GFOSS-DAY 2011
Pubblicato da flaviorigolon in blogging, mapping il 26 settembre 2011
Si terrà a Foggia il quarto GFOSS-DAY. Dopo le edizioni di Pontedera, Bolzano e Foligno quest’anno si sposta in Puglia. L’evento interesserà le giornate del 24 e 25 novembre e sarà caratterizzato da un nutrito calendario di eventi.
Per maggiori dettagli e specifiche teniamo d’occhio il sito dell’associazione http://gfoss.it in particolare la pagina http://gfoss.it/drupal/gfossday2011
array_to_string in Postgresql ovvero il problema della “battaglia navale”
Pubblicato da flaviorigolon in db-ing & geodb-ing, mapping il 27 agosto 2011
Premetto come per ogni post su questo blog che quanto scrivo è frutto di tentativi e ricerche per risolvere un problema pratico che di volta in volta mi si presenta. Non è detto quindi che sia il modo migliore ed il più elegante; ogni feedback e/o consiglio è pertanto graditissimo.
Parto dall’inizio: dispongo di un grafo stradale (stradario comunale) archiviato in db Postgresql con estensione spaziale Postgis. La tabella contenente gli archi stradali si chiama “grafo_new”; in essa ogni arco di strada è spezzato all’intersezione con altri tratti. Questo comporta che una strada denomimata “Via Roma” sia composta da tanti archi. Inoltre il db contiene una griglia regolare di passo quadrato che identifica i quadranti del territorio comunale. Il problema da risolvere è: “Come faccio ad ottenere un elenco delle strade (in ordine alfabetico) che indichi anche il quadrante o i quadrantiall’interno dei quali la strada ricade”. Mi ricorda moltissimo il funzionamento della battaglia navale quando per colpire una nave avversaria di indicavano le coordinate: A7: acqua; B5: colpito; B6: colpito e affondato.
Un po’ come fa l’ottimo servizio maposmatic (http://www.maposmatic.org)
Ecco i passaggi che ho seguito:
1. creazione di una view in postgres che aggrega tutti i tratti di via con lo stesso nome:
#= CREATE VIEW view_grafo_union AS SELECT nome, ele_desc, ele_tipo, gid, ST_Multi(ST_Union(f.the_geom)) AS the_geom FROM grafo_new AS f GROUP BY nome ORDER BY nome;
2.creazione di una seconda view di intersezione spaziale tra il grafo e la griglia di quadranti:
#= CREATE VIEW view_grafo_union_quadrante AS SELECT ST_Intersection(r.the-geom, m.the_geom) AS intersection_geom, m.codice, r.nome FROM view_grafo_union AS r, quadrante_stradario AS m WHERE ST_Intersects(r.the_geom, m.the_geom);
3. Creazione di una query “array_to_string” che fornisca l’elenco di tutti i quadranti di instersezione per ogni tratto di strada:
#= SELECT DISTINCT a.nome, array_to_string(array(SELECT codice FROM view_grafo_union_quadrante AS b WHERE b.nome = a.nome),’,') FROM view_grafo_union_quadrante AS a ORDER BY nome;
Per salvare il risultato dell’ultima query su un file basta impartire prima della query il seguente comando:
#= \o /percorso/al/file/di/output.csv
Il CSV potrà poi essere aperto e gestito con Calc o altro editor di testo.
To be continued con snapshot e altri dettagli….
ubuntu-party a Schio | pubblicati i video
Pubblicato da flaviorigolon in linuxing, mapping il 19 maggio 2011
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.
openlite | migrazione tra database in pochi click
Pubblicato da flaviorigolon in db-ing & geodb-ing, mapping il 21 aprile 2011
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ì:
- è 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.
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.
Ushahidi
Pubblicato da flaviorigolon in mapping il 7 febbraio 2011
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.
geodjango | primo approccio
Pubblicato da flaviorigolon in db-ing & geodb-ing, mapping il 24 dicembre 2010
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 iniziale per implemntare 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 chiamto “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 deifinito la nuova tabella che conterrà i dati geografici con gli stessi attributi trovati nello SHO. 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 sincornizziamo 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 definzione 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
18-19 (20) novembre 2010, GFOSS DAY a Foligno
Pubblicato da flaviorigolon in blogging, mapping il 16 settembre 2010
L’associazione Italiana per l’Informazione Geografica Libera GFOSS.IT (Geospatial Free and Open Source Software) organizza, per i giorni 18 e 19 novembre 2010, a Foligno, la 3a conferenza italiana sul software geografico libero, per fare il punto sullo stato dell’arte del software geografico libero ed Open Source in Italia, ponendo particolare attenzione alle applicazioni nel campo delle pubbliche amministrazioni e delle aziende.
L’associazione GFOSS.IT (http://www.gfoss.it), costituita nel febbraio 2007 da docenti universitari, ricercatori e professionisti provenienti da diverse regioni italiane, ha, tra gli altri, gli obiettivi di:
- favorire lo sviluppo, la diffusione e la tutela del software esclusivamente libero ed open source per l’informazione geografica;
- promuovere gli standard aperti per l’informazione geografica e il libero accesso ai dati geografici.
Il Gfoss Day, tenutosi in precedenza nelle città di Pontedera e Bolzano (http://www.gfoss.it/drupal/convegno e http://www.gfoss.it/drupal/gfossday ), rappresenta uno dei momenti in cui l’associazione GFOSS.IT riunisce soci, aziende, professionisti e pubbliche amministrazioni attive nell’applicazione, sviluppo, promozione e diffusione di software libero geografico.
L’evento sarà aperto e gratuito per tutti i partecipanti. La prima giornata sarà dedicata a momenti formativi durante i quali esperti di fama nazionale ed internazionale terranno corsi mirati su Software GIS (Geographic Information System) e/o WebGIS.
La seconda giornata della conferenza sarà orientata a discutere aspetti tecnologici e legali relativi alla circolazione dei dati geografici. Sono previsti interventi orientati a fare il punto sul processo di adeguamento delle PA italiane alla direttiva Europea INSPIRE (http://inspire.jrc.ec.europa.eu/ – anche alla luce del decreto legislativo 27 gennaio 2010 , n. 32) e sulla promozione di servizi di distribuzione di dati in rete secondo standard condivisi ed internazionali – OGC e ISO (Web Services).
Per questo saranno ospitati interventi di pubbliche amministrazioni che illustreranno i loro progetti ed il loro stato di avanzamento.
Il terzo giorno sara’ dedicato ad una attivita’ di mappatura della citta’ di Foligno (mapping party) coinvolgendo i ragazzi di alcune scuole. I dati raccolti mediante ricevitori GPS saranno poi riversati nel database libero mondiale di OpenStreetMap.
Maggiori informazioni: http://www.gfoss.it/drupal/gfossday2010
il primo “Hello world” in C
Pubblicato da flaviorigolon in linuxing, mapping, scripting il 4 giugno 2010
Non sono un programmatore; non conosco nessun linguaggio di programmazione. Per questo, approfittando di una piccola necessita’ lavorativa, mi sono avvicinato al C.
Bazzicando in rete ho trovato alcuni “punti di partenza” molto ben fatti:
- introduzione alla programmazione in C;
- piccolo corso di programmazione in C;
E da qui ne e’ uscito un piccolo programmino per convertire le coordinate geografiche (lat/long) da DMS (Gradi Primi Secondi) a DD (Gradi decimali).
L’ho scritto usato l’editor “nano” (semplice quanto efficace editor che offre colorazione del testo ben fatta).
Una volta scritto il testo sottostante salvarlo con il nome di “primo_test.c” (i codici sorgente in C vengono contraddistinti dal suffisso .c).
#include <stdio.h>
float a,b,c,d;
main()
{
printf(“inserisci i gradi: \n”);
scanf(“%f”, &a);
printf(“inserisci i primi: \n”);
scanf(“%f”, &b);
printf(“inserisci i secondi: \n”);
scanf(“%f”, &c);
d=a+(((c/60)+b)/60);
printf(“l’angolo in formato decimale e’ %f \n”, d);
}
Una volta salvato il codice deve essere compilato. Per fare questo ho usato il compilatore “gcc” mediante la seguente sintassi:
$ gcc primo_test.c -o primo_test.out
Viene creato un file eseguibile chiamato primo_test.out (nel caso non avessimo indicato il nome del file di outptu, gcc avrebbe nominato il file “a.out”).
Il programma si lancia con il comando
$ ./primo_test.out
Vediamo il codice. All’inizio del testo viene indicata la libreria da caricare per eseguire le operazioni (#include <stdio.h>).
Poi si passa al processo. Stampa a console la richiesta di inserire i valore dei gradi dell’angolo da convertire; fatto questo cattura il valore inserito e lo memorizza nella prima variabile dichiarata (di tipo float). Poi chiede di inserire il valore del primi e memorizza il valore nella seconda variabile. Infine richiede i secondi e li memorizza nella terza variabile.
Fatto questo esegue l’operazione di conversione e propone in output il valore dell’angolo calcolato.











