Archivio del mese di giugno, 2011

26 giugno, 2011 | di

In un dopocena di un po’ di tempo fa, speso in letture web su python e gdal, ho “guardato” un po’ dentro l’archivio di Google code, ed in particolare tra i progetti etichettati con “gdal”. Sono soltanto 17 e tra questi l’occhio mi è “caduto” su MetaGETA: Metadata Gathering, Extraction and Transformation Application.
Si tratta di un’applicazione scritta in python, per estrarre e raccogliere metadati da dataset raster spaziali, in uno di questi formati:

  • Generic  format (che legge tutti i formati “classici” di GDAL, incluso GDAL Virtual Raster)
  • EO1 ALI (L1G & L1R) e Hyperion (L1R)
  • ACRES ALOS AVNIR-2/PRISM/PALSAR
  • ASTER
  • ACRES Landsat CCRS/SPOT 1-4
  • Digital Globe
  • ECW
  • ECWP
  • ENVI
  • ESRI Bil
  • ESRI GRIDs
  • ACRES Landsat FastL7A
  • JPEG2000
  • Landsat geotiff
  • NetCDF
  • NITF
  • SPOT 1-4
  • SPOT DIMAP

La scelta è molto ampia, con formati “generici” ed altri “specializzati” tipici del mondo del remote sensing. L’architettura a plugin dell’applicazione consente comunque di aggiungere facilmente nuovi driver di lettura di metadati.

E’ uno strumento di grande utilità, perché l’estrazione di metadati strutturati consente di conoscere meglio le proprie basi dati e di dargli quindi più valore.

Si tratta di un software opensource multipiattaforma, installabile da codice sorgente e nel caso di Windows anche tramite un installer. Io ho testato soltanto quest’ultima versione.
Il lancio si esegue (anche) da riga di comando con questa sintassi tipo:

>runcrawler.bat/sh arguments

Se non vengono forniti argomenti sufficienti, si aprirà la finestra di dialogo sottostante, in cui è possibile scegliere il percorso da analizzare, quello del file di output del processo, ed altre opzioni (tra cui quella di cercare anche nelle sottocartelle).

Gli output sono:

  • un file .xls con i metadati raccolti
  • la generazione (opzionale) di un’immagine di anteprima e di un thumbnail per ogni immagine dell’archivio
  • un quadro d’unione in formato ESRI Shapefile in coordinate geografiche (ma EPSG:4283, perché gli sviluppatori sono australiani, e gli piacciono i codici EPSG del paese loro), con in il bounding box di ogni immagine associato ai relativi metadati

Se volete un’idea dei contenuti del file .xls di output, potete fare click qui: le coordinate del bounding box, la risoluzione, il sistema di coordinate, il datatype, il tipo di compressione, le dimensioni, il numero di bande, ecc.. Ma ci sono anche campi tipici (come detto sopra) del remote sensing.

Ho invece pubblicato su GeoCommons uno shapefile di output di esempio. E’ il classico layer poligonale costituito dai bounding box degli strati informativi processati – analogo a quello di output di gdaltindex – arricchito dai metadati “intercettati” da MetaGETA.

Aggiunti nuovi file nel proprio archivio (e dopo un”eventuale rimozione di vecchi), possono essere eseguite nuove operazioni di indicizzazione che aggiorneranno i record del file .xls . Questo può essere facilmente convertito in XML secondo lo schema ANZLIC Profile (ISO 19139) e caricato ad esempio su GeoNetwork. E’ ancora una volta possibile personalizzare il processo, modificare lo schema di esportazione ed aggiungere anche nuovi campi.

MetaGETA però non fa miracoli e potrà estrarre soltanto i metadati associati ai vostri dati; in presenza di una “povera” coppia tif/tfw, non sarà in grado di determinarne il sistema di coordinate. Io l’ho trovato molto utile anche per questo: mi ha fatto scoprire diverse “falle” di alcune mie basi dati, ed evidenziato ancora una volta il grande valore del corredo informativo dei dati spaziali. Buon crawling!

19 giugno, 2011 | di

Tim Sutton ha da poco annunciato che è stato rilasciato ufficialmente QGIS 1.7.0 – Wroclaw e le novità sono veramente tante.

Alcune sono legate all’infrastruttura del progetto:

Queste invece alcune delle novità software:

  • Simbologia
    • il nuovo gestore della simbologia – già presente nella versione precedente – è diventato quello di default
    • import ed export degli stili
    • elementi lineari
      • è possibile inserire un simbolo nel punto centrale di una linea
      • è possibile inserire un simbolo sul primo e sull’ultimo nodo di una linea
      • è possibile inserire un simbolo in ogni vertice di unalinea
    • elementi poligonali
      • rotazione dei riempimenti svg
      • aggiunta la possibilità di inserire un simbolo in corrispondenza del centroide di un poligono
    • etichette
    • è possibile impostare la distanza in unità di mappa
    • inserito uno strumento per muovere/ruotare/cambiare interattivamente le etichette
  • Nuovi strumenti
    • aggiunta un’interfaccia per gdaldem
    • aggiunte nuove funzioni nel field calculator, $x $y e$perimeter
    • aggiunto lo strumento “Lines to polygons” nel menu Vector
    • aggiunto lo strumento “Voronoi polygon” nel menu Vector
  • Interfaccia
    • zoom ad un gruppo di layer
    • “Suggerimento del giorno” all’avvio (si può disabilitare)
    • migliore organizzazione dei menu, e nuovo menu database
    • possibilità di mostrare in legenda il numero di feature per ogni classe (si attiva con il tasto destro del mouse)
    • migliorata usabilità e “pulizia”
  • Gestione CRS
    • visualizzazione del CRS attivo nella barra di stato
    • possibilità di assegnare il CRS  dal menu contestuale in legenda
    • possibilità di impostare il CRS di default per i nuovi progetti
  • Raster
    • aggiunti gli operatore AND e OR nel raster calculator
    • riproiezione al volo
    • inserita un barra degli strumenti, con pulsanti per calcolo dell’istogramma e funzioni di stretch
  • Gestione e provider dati
    • supporto per Join tra tabelle
    • nuovo provider vettoriale SQLAnywhere
    • supporto per la ricerca di valori NULL nella tabella degli attributi
    • miglioramenti nella modifica e nella gestione degli attributi
    • possibilità (opzionale) di inserire gli attributi della feature precedente all’inserimento di una nuova
    • stringa di rappresentazione dei Null value configurabile
    • possibilità di unire/assegnare valori di campi ad un insieme di feature
    • possibilità di salvare (tramite OGR) oggetti geometrici senza attributi associati (i.e. DGN/DXF)
  • QGIS Server
    • possibilità di specificare le Capabilities WMS nella finestra Proprietà Progetto
    • supporto per stampa WMS tramite GetPrint-Request
  • Plugin
    • supporto per l’utilizzo di icone nella finestra di dialogo di gestione dei plugin
    • rimosso plugin “quickprint” (usare in sostituzione il plugin easyprint scaricabile dal catalogo)
    • rimosso plugin “ogr convertor” (usare in sostituzione “save as” dal menu contestuale)
  • Stampa
    • supporto per Undo/Redo nel gestore di stampa

Io l’ho appena installato ed il primo impatto è molto buono. Feature come il supporto per il Join, la riproiezione al volo dei file raster e le migliorie legate alla simbologia mettono da subito di buon umore. Nel ringraziare tutti quelli che hanno contributo al progetto, ricordo (anche a me stesso) che QGIS è basato sul volontariato; una donazione, anche minima, si può fare da qui.

Supporto Join

Simbologia elementi lineari

Conteggio feature

Gestione CRS

___

16 giugno, 2011 | di

Oggi ho potuto seguire a Bari il seminario organizzato da DigitPA dal titolo “Il nuovo CAD: opportunità per i cittadini, adempimenti per le amministrazioni”.

Fa parte di un ciclo di incontri nell’ambito del Programma Operativo di Assistenza Tecnica Società dell’Informazione (POAT-SI) con il quale si vogliono presentare le opportunità e gli obblighi insiti nel nuovo CAD.

E’ stato un interessante momento di confronto, durante il quale i circa 60 presenti, tra funzionari delle PA, operatori del settore dell’informazione e qualche curioso come me, hanno tempestato di domande e posto molti dubbi ai relatori.

Per quanto mi riguarda, dopo aver ascoltato la prima presentazione “Gli elementi fondamentali della riforma del CAD” di Elena Tabet (qui il PDF delle slide), ho fatto un intervento sottolineando che il Codice (artt. 52 e 68) di fatto parla di “formati aperti” come modalità di interscambio tra le amministrazioni pubbliche, trascurando la necessità – se non proprio obbligo – da parte della PA di rendere disponibili i propri dati, sempre in formati aperti, al pubblico.

Ho comunque spezzato una lancia a favore del MiPA, sottolineando come la definizione della IODL sia un ottimo passo avanti. Ma ho anche fatto notare come tra i gruppi di lavoro (vedi slide 28-34) che si occuperanno di elaborare le regole tecniche sulle numerose questioni annoverate dal CAD in seno a DigitPA, nessuno di fatto si occuperà di open data.

Mi è stato risposto che in effetti al momento non sono previste azioni che vadano a definire regole tecniche o tempi che le PA dovranno rispettare per aprire i dati al pubblico.

Ma proprio questa mancanza di fatto lascia la realizzazione dell’open government alla totale discrezione delle singole PA che lo hanno tra i propri obiettivi prioritari. Molto poche al momento, come abbiamo già accennato sempre qui su TANTO (Piemonte pionieri e Puglia in stand-by), e talvolta in maniera alquanto farraginosa, come racconta Gerlando Gibilaro in un suo approfonditissimo articolo, parlando della Regione Siciliana.

It’s a long way to the top if you wanna open data…

 

Immagine anteprima YouTube


TANTO non rappresenta una testata giornalistica ai sensi della legge n. 62 del 7.03.2001, in quanto non viene aggiornato con una precisa e determinata periodicita'. Pertanto, in alcun modo puo' considerarsi un prodotto editoriale.