Non c'è due senza tre: i raster del PCN scaricabili con i servizi WCS.

Revisioni e note:


- 13 aprile 2012: ATTENZIONE!
Nel mese scorso il PCN ha modificato le specifiche WCS, passando dalla versione 1.0.0 alla 1.1.2. Inoltre, con l'occasione, ha impostato diversamente nomi e caratteristiche dei servizi. In poche parole, questo articolo deve essere aggiornato... ma non ho tempo!!!
In attesa di farlo, ho inserito nell'articolo anche la stringa corretta, evidenziata in GIALLO.
Trovate ulteriori dettagli su questa soluzione speditiva - ma funzionante! - nel commento che ho inserito oggi in coda all'articolo (...in fondo, in fondo... 61° posizione!). Vi anticipo però che a me funziona SOLO utilizzando FIREFOX. 

 - 9 febbraio 2011:  leggendo i numerosi commenti collegati a questo post e nella speranza di evitare gli errori più comuni, ho ritenuto opportuno rivedere alcuni passaggi dell'articolo originale.  Come sempre vi invito a leggere i commenti di coda, vi assicuro che sono ricchi di informazioni e consigli tecnici!



Cari utenti ArcGIS,
dopo aver parlato di servizi WMS (Web Map Service) e WFS (Web Feature Service), tocca ora ai servizi WCS (Web Coverage Service), la modalità scelta dal PCN (Portale Cartografico Nazionale) per distribuire dati in formato raster.

Un esempio?
Il DTM (o DEM) - acronimo di Digital Terrain Model - grazie al quale ho ottenuto l'immagine qui sotto: un'affascinante veduta in 3D dell'isola d'Elba ottenuta tramite ArcScene (voglia di mare???).

Se ben ricordate avevo già parlato di WCS, più precisamente in un passaggio inserito nell'articolo del 21 gennaio scorso :
"....un rapidissimo accenno ai servizi WCS (Web Coverage Service) che, in pratica, sono complementari ai WFS. Sono infatti utilizzati per distribuire dati di tipo raster: celle (GRID) più i relativi attributi.
Si pensi ad esempio ad un DTM (Modello Digitale del Terreno) e all'associazione tra ogni cella e il corrispondente valore di quota.

Se volete approfondire anche questo argomento, vi consiglio la lettura, sempre su Wikipedia, della seguente pagina: http://it.wikipedia.org/wiki/Web_Coverage_Service "

Diciamo subito che mentre i servizi WMS sono ormai molto diffusi e i WFS vanno lentamente affermandosi, i servizi WCS sono ancora rarissimi.
In Italia, ad esempio, mi risulta che li esponga solo il Portale Cartografico Nazionale.

Chiariamo anche, onde evitare false speranze, che tra i servizi WCS del PCN non sono comprese le ortofoto che, almeno fino ad oggi, sono esposte solo come servizi WMS.
Vi segnalo però che su questo argomento, qualche tempo fa, avevamo aperto una discussione che trovate nello "spazio libero" a fondo pagina, ecco i passaggi chiave:

"...solo un servizio WCS (Web Coverage Service) ti consentirebbe di scaricare il dato raster originale, esattamente come avviene per i dati vettoriali quando si utilizza un servizio WFS.
Ma il PCN, almeno per ora, non espone le ortofoto come WCS...
In effetti, visto che le ortofoto sono - per definizione - dati "statici", non sarebbe male poterle scaricare, se non altro per minimizzare i tempi di attesa dovuti al collegamento internet...
Se ti serve una zona limitata puoi tentare però un "accrocchio": massimizza l'area del tuo schermo e opera uno zoom adeguato al tuo utilizzo, accedi poi al menu "file" e clicca su "export map", scegli il formato jpg, imposta una risoluzione adatta al tuo caso e metti il flag nella casella "write world file".
Otterrai così un'immagine georeferenziata corrispondente all'area visibile a monitor... dopo qualche prova, finalizzata a trovare la risoluzione più adatta ai tuoi scopi, sono certo che otterrai il risultato voluto.
Se ti servisse un'area più estesa, dovrai ripetere l'operazione spostando il centramento della mappa. Produrrai così una serie di immagini, identiche per caratteristiche, che potrai visualizzare assieme oppure - meglio ancora - mosaicare in un raster catalog o in raster dataset.
Ovviamente ci vuole più tempo e fatica, ma se l'area è poco estesa..."

In realtà l'idea di scrivere un post sui servizi WCS è nata mentre stavo preparando il primo articolo dedicato ai servizi WFS.
Infatti, sulla scia dell'entusiasmo, avevo provato a scaricare dal PCN anche i raster esposti come servizi WCS ma, ahimè, con risultati poco soddisfacenti.
Dopo alcuni tentativi infruttuosi decisi di confrontarmi con Marco, un sostenitore del blog che sapevo impegnato nella stessa operazione. Ecco il nostro fraseggio:

"Ciao Marco,
volevo chiederti se nella tua euforia dei giorni scorsi hai scaricato anche qualche dato esposto con i servizi WCS.
Ieri ho provato con alcuni servizi, in particolare DTM 20, 40 e 75m, ma il risultato mi ha molto sorpreso: infatti sono sempre raster di 512x512 celle (quindi troppo "piccoli" per essere corretti) e privi di qualsiasi significato.
Inutile dire che mi aspettavo di scaricare lo stesso dato che alimenta i corrispondenti servizi WMS...
Tu hai avuto lo stesso risultato?"

"Ciao Paolo,
... ho fatto dei tentativi con il servizio WCS del PCN, in particolare ho provato a scaricare il DTM 20 mt. Riesco a scaricarlo ma quando vado a fare il preview, il dato mi appare come un rettangolo nero sia per il DTM fuso 32 che per quello fuso 33.
Se poi vado a vedere le properties in effetti il raster risulta costituito da 512 righe e 512 colonne, così come è sucesso a te. Anche tu vedi un rettangolo nero come me?"

In realtà, applicando un'opportuna simbologia, il rettangolo nero si trasfoma nell'immagine qui sotto che, a questa scala, potrebbe sembrare corretta:

L'immagine che segue, mostra però i limiti del dato raster appena scaricato: non ci crederete ma quella qui sotto è proprio l'isola d'Elba, peccato che ogni pixel misuri oltre 2Km di lato...

Dopo ulteriori tentativi mi sono quindi convinto che i servizi WCS del PCN sono poco "graditi", almeno per ora, al nostro beneamato ArcView (quindi anche ad ArcEditor ed ArcInfo).

La mail che ho ricevuto ad inizio febbraio da Roberto - altro sostenitore del blog - ha confermato i miei sospetti:

"Da quanto ho capito io hanno pubblicato i servizi WCS rispettando la lettera del protocollo WCS, cosa che però li rende al momento inutilizzabili con ArcGIS (funzionano invece con il nostro software) : Warning: "A selcted item could not be added to the map. Failed to open raster dataset."

Ho segnalato la cosa allo staff del PCN che mi ha risposto il 15 febbraio scorso: "Stiamo, comunque, provvedendo a verficare, tramite test, cosa debba essere modificato nei nostri servizi Wcs affinchè siano fruibile con ArcGis (9.3.1). Sarà nostra premura contattarla quando ne avremo verificato la compatibilità."

Precisando che Roberto faceva riferimento ad AdbToolbox - software liberamente scaricabile proprio dal PCN - ho tentato di installare questo prodotto per verificare se i servizi WCS fossero realmente fruibili.
Purtroppo sul mio notebook - sistema operativo Windows Vista - la procedura di installazione va subito in errore, impedendomi così di effettuare il test...

Questa ennesima delusione mi ha condotto però sulla strada più corretta: definire una "chiamata" WCS rigorosamente in linea con le specifiche di questo standard.

Un approccio diverso che, nel vero spirito degli standards OGC e del concetto di interoperabilità, fosse totalmente indipendente da qualsiasi tecnologia software.

Ho quindi scaricato le specifiche WCS versione 1.0.0 (la stessa attualmente implementata dal PCN) e letto attentamente il documento, giungendo così da "una" soluzione del problema.

Passiamo quindi alla fase operativa scegliendo come dato di riferimento il DTM con maglia 20 metri  (sicuramente uno dei tematismi più interessanti pubblicati dal PCN) nella "versione" restituita in coordinate UTM WGS84 e, nello specifico, relativa al fuso 32 Nord.

Il primo passo è conoscere, con maggior dettaglio, le modalità con le quali viene pubblicato questo strato informativo.
A questo scopo le specifiche WCS prevedono l'istruzione describecoverage il cui compito, come facilmente intuibile, è quello di restituire informazioni descrittive del dato.

Nel caso specifico mi sono collegato alla pagina del PCN che elenca tutte le risorse WCS disponibili, cliccando poi sul link capabilities relativo allo strato di mio interesse. Modificando l'ultima parte della URL, ovvero sostituendo getcapabilities con describecoverage, si ottiene la stringa qui sotto:
http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/wcs/DTM_20M_wcs_32.map&service=wcs&version=1.0.0&request=describecoverage

Cliccandovi sopra potrete visualizzare una pagina XML che, come anticipato, vi elenca una serie di caratteristiche descrittive della "coverage" DTM20: nome, sistema di riferimento, formato di restituzione, metodo di interpolazione, ecc...
In particolare vi faccio notare come il raster che andremo a scaricare verrà generato in formato GeoTiff.

Premesso che le informazioni appena ottenute forniscono tutti gli elementi necessari per impostare correttamente l'istruzione getcoverage, riporto qui sotto la stringa completa che mi ha permesso il download della parte di DTM20m relativa all'isola d'Elba:

http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/wcs/DTM_20M_wcs_32.map&service=wcs&version=1.0.0&request=getcoverage&coverage=DTM_20M_f32&crs=EPSG:32632&bbox=586000,4726000,620000,4750000&width=1700&height=1200&format=geotiff

ATTENZIONE:
a seguito delle modifiche apportate dal PCN nel mese di marzo 2012, la stringa precedente NON è più utilizzabile.
La stringa corretta (anche se a  me funziona solo con FIREFOX) è:
http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/wcs/dtm_20m.map&service=WCS&version=1.1.2&request=GetCoverage&Identifier=EL.DTM.20M&BoundingBox=42.69,10.08,42.89,10.48,urn:ogc:def:crs:EPSG::4326&format=image/tiff
In attesa di aggiornare tutto l'articolo (forse...), vi rimando al commento che ho lasciato oggi (13 aprile 2012) in coda a questo post.

Ulteriore nota del 12/10/2015 - Nonostante la richiesta qui sopra sia formalmente corretta, in questi giorni restituisce un misero riquadro nero, privo di qualsiasi dato di elevazione...
Ipotizzando qualche problema nel servizio (quindi lato PCN), vi rimando alla risposte che ho dato a Geomarty in coda al commento inserito in data 8/10/2015 (in sintesi: il servizio sembra funzionare solo in alcune zone).
Si attendono, ovviamente, indicazioni utili a risolvere il problema.

Cliccando direttamente sul mio link - operazione che equivale a lanciare la richiesta WCS direttamente dal vostro browser - otterrete il download dell'immagine GeoTiff che, applicando un'opportuna simbologia, produce il risultato qui sotto.

Attenzione: nel mio caso - ovvero utilizzando Internet Explorer 8 - il file scaricato viene denominato "mapserv[1].tif" e salvato in un cartella temporanea.
Nei commenti all'articolo (leggeteli sempre!), Stefano segnala che Firefox produce invece un file "mapserver.exe", strano ma vero! Comunque basta modificare l'estensione in .tif per rendere subito consultabile il raster...

Ribadisco il concetto: in questo momento NON sto utilizzando ArcCatalog o ArcMap, mi limito a "lanciare" la richiesta direttamente dal browser (nel mio caso Internet Explorer 8).

Attenzione poi alla simbologia da applicare ai dati: il file scaricato presenta infatti una "striscia" di pixels, fortunatamente in mare aperto, con un valore di quota di oltre 32.000 metri!
Anomalia che però va rimossa dalla simbologia per evitare che il territorio appaia troppo "pianeggiante" (intendo visivamente).

Inizialmente ho pensato ad un errore del server PCN.
Poi, rispondendo ad alcuni commenti dei lettori, ho approfondito meglio la problematica individuando così una possibile soluzione che oggi - 9/2/2011 - aggiungo all'articolo.
E' infatti sufficiente ottenere le statistiche del raster per risolvere il problema, che ritengo dovrebbe interessare tutte le zone "perimetrali" del tematismo.
Il metodo più semplice per generare le statistiche è tramite ArcCatalog: è sufficiente cliccare con il tasto destro sul DTM e lanciare il comando "Calculate Statistics...".
A seguito di questa operazione ArcGIS interpreta meglio i dati: ora l'altimetria di questa zona risulta compresa tra 0 e 1012 m.s.l.m.
Le celle con valore 32.767 sono invece interpretate come "NoData" (vedi proprietà del layer - scheda "Source"), di conseguenza non vengono considerate... (nota: il valore 32.767 deriva dal fatto che il raster prodotto è a 16bit, in grado quindi di gestire 65.536 valori: da -32.768 a +32.767).

Resta inteso che, una volta scaricata, l'immagine sarà disponibile in ArcMap/ArcCatalog per tutte le analisi e le elaborazioni del caso.
Avrete notato che la risoluzione del DTM è ora nettamente migliore (ogni pixel misura infatti 20x20 metri) e l'immagine qui sotto - uno zoom in scala 1:25.000 - rende ancor meglio il concetto.

Proviamo ora ad illustrare il significato delle diverse "componenti" che, nell'insieme, definiscono la richiesta WCS utilizzata nel mio esempio.

In questo modo ogni lettore potrà "personalizzare" la stringa, adattandola quindi alle proprie esigenze.
Notate innanzi tutto che ogni singola componente è preceduta da una & la cui funzione è appunto quella di "concatenare" i vari elementi della URL.

A - http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/wcs/DTM_20M_wcs_32.map
Rappresenta la URL del servizio, esattamente come appare cliccando sul tasto "URL" corrispondente al servizio WCS di vostro interesse.

B - &service=wcs
Indica il tipo di servizio.

C - &version=1.0.0
Indica la versione del protocollo utilizzato dal PCN per esporre il servizio WCS.

D - &request=getcoverage
E' la "richiesta" che consente il download dei dati raster.

E - &coverage=DTM_20M_f32
Indica il nome della "coverage", ovvero del tematismo raster che si intende scaricare.

F - &crs=EPSG:32632
Indica il CRS - Coordinate Reference System - al quale fa riferimento la richiesta. Nel mio caso ho indicato il CRS associato alla coverage, informazione ottenuta dopo aver letto la scheda XML restituita dalla richiesta describecoverage (sezione: supportedCRSs).
Si noti che il codice EPSG 32632 corrisponde al sistema di riferimento cartografico UTM WGS84 fuso 32Nord.
ATTENZIONE: dopo aver risposto a parecchi lettori (vedi commenti), vorrei evidenziare come il sistema ci coordinate dipenda SIA dal tematismo CHE dalla zona di vostro interesse, quindi non è sempre 32632!!!

G - &bbox=586000,4726000,620000,4750000
Con riferimento al CRS di cui al punto precedente, definisce un quadrante (34x24Km) centrato sull'isola d'Elba.
Il riquadro è identificato dalle coordinate del vertice basso-sinistro e da quelle del vertice alto-destro.
Per maggiori informazioni sull'istruzione BBOX potete fare riferimento al mio articolo del 21 gennaio 2010 . Nello stesso articolo troverete illustrata un buon metodo per determinare facilmente le coordinate BBOX che fanno al caso vostro.

H - &width=1700
Definisce la larghezza dell'immagine raster, espressa in numero di pixel. Nel mio caso ho voluto mantenere le dimensioni dei pixel coincidenti con il livello di dettaglio "nominale" del DTM, quindi 20x20 metri.

I - &height=1200
Definisce l'altezza dell'immagine raster, espressa in numero di pixel. Per le dimensioni dei pixel vale quanto detto al punto precedente.

L - &format=geotiff
Indica il formato immagine scelto per il download dei dati, formato che, ovviamente, deve essere compreso fra quelli "supportati" dalla servizio WCS (informazione che si ottiene dalla già citata richiesta describecoverage).

Tutte le componenti sopra descritte sono OBBLIGATORIE, l'assenza di una sola di esse rende la richiesta invalida, producendo così un messaggio di errore.
E' anche evidente come alcune componenti siano "invarianti" (B-C-D-L), mentre altre siano STRETTAMENTE CORRELATE sia al tematismo che si intende scaricare, sia all'area di interesse.
ATTENZIONE: dopo aver risposto a parecchi lettori (vedi commenti), mi sembra opportuno ribadire l'importanza del'ultimo concetto espresso, leggetelo bene!

Per ulteriori dettagli in merito allo standard WCS vi rimando alle specifiche OGC, in particolare alla tabella qui sotto, che troverete pubblicata a pagina 32 :

Ma perchè ArcView non carica direttamente i servizi WCS esposti dal PCN?
La mia impressione è che il problema sia riconducibile all'impostazione RectifiedGrid,  un parametro opzionale che, probabilmente, mette in crisi ArcView.
Se provate a consultare il file restituito dall'istruzione DescribeCoverage, noterete che per questa coverage è prevista una griglia di 512x512 pixels, ognuno con dimensioni rettangolari pari a 2.008 metri (larghezza) x 2.568 metri (altezza).

Per completezza vi segnalo che in azienda abbiamo effettuato alcune prove "parallele", in particolare ho chiesto a NicoGIS di pubblicare un servizio WCS di test utilizzando a tale scopo la nostra licenza ArcGIS Server.
In questo caso il collegamento alla risorsa WCS funziona senza problemi, qualcosa però non torna: in effetti, mantenendo monitorate le "chiamate" di ArcMap o ArcCatalog al servizio, non vi è traccia dell'istruzione GetCoverage...

In definitiva devo ammettere che ho ancora le idee confuse ma, come recita un noto proverbio, "a caval donato non si guarda in bocca".

Un caro saluto.
PaoloGIS

PS: come al solito attendo commenti ed osservazioni per migliorare, correggere ed integrare il contenuto di questo articolo.

Servizi WFS parte seconda: quando il gioco si fa duro...

NOTE E REVISIONI
- 26/11/2012: ho effettuato una prova di connessione con la versione 10.1 di ArcGIS (nel caso specifico con il servizio "Infrastrutture stradali"), verificando, con soddisfazione, che funziona tutto a meraviglia!
E' stato risolto anche l'inconveniente legato alla sostituzione delle virgole nella stringa di richiesta: ora, infatti, il BBOX può essere dichiarato nei parametri che definiscono il "Search Envelope" (come è giusto che sia), evitando quindi di specificare le coordinate nella richiesta stessa.
- 01/04/2011: inserito un passaggio in cui ho simulato il download dei dati utilizzando la versione 10 di ArcView.

Cari utenti ArcGIS,
BUON 2010!!!

Apro "ufficialmente" il nuovo anno con questo post che, a tutti gli effetti, potete considerare come la seconda parte dell'articolo pubblicato il 30 novembre scorso.
In quell'occasione vi ho parlato dei servizi WFS erogati dal Portale Cartografico Nazionale (PCN), avvisandovi però che i tematismi di maggior dettaglio avrebbero richiesto parecchio tempo per completare il download.

In questa sede cercherò di illustrarvi una possibile soluzione, rispondendo così a quei lettori che hanno incontrato difficoltà nel caricamento degli strati informativi più "pesanti".
La logica è abbastanza semplice: occorrerà impostare la connessione WFS limitandone l'estensione territoriale.

Che poi - pensandoci bene - si tratta proprio dell'esigenza più comune: molto spesso non serve scaricare "tutto" un tematismo anche perchè, nel caso del PCN, i servizi WFS comprendono l'intero territorio nazionale o, nella migliore delle ipotesi, uno dei due fusi.
Nella maggior parte dei casi è invece più che sufficiente una "porzione" limitata, ad esempio un comune, una provincia o una regione.

Un "filtro spaziale" di questo tipo si basa sulla richiesta  BBOX (Bounding Box), appositamente definita nelle specifiche WFS, WCS e WMS (per i dettagli fate riferimento alla documentazione pubblicata da Open Geospatial Consortium ).

La possibilità di impostare un filtro su un'area di interesse è evidenziata nelle Capabilities di tutti i servizi erogati dal PCN.
Provate, ad esempio, a verificare le Capabilities del tematismo "rete_stradale": nella parte finale del file XML, all'interno della sezione ogc:Filter_Capabilities, troverete indicata anche la richiesta BBOX.

Già che ci siete verificate il sistema di riferimento (SRS) adottato per questo strato informativo ovvero EPSG:4326.
Chi non avesse confidenza con questi codici, può visitare la pagina web EPSG Geodetic Parameter Registry: scegliendo la scheda retrieve by code e inserendo "4326", scoprirete che a questo codice è associato il sistema di coordinate geografiche nel datum WGS84.

Sempre consultando le Capabilities, nella sezione FeatureTypeList, noterete che questo servizio WFS - impostato su specifiche in versione 1.0.0 - è composto in realtà da 4 diversi livelli:

• strade_locali
• strade_provinciali
• strade_statali
• autostrade

Passiamo ora alla fase "operativa" ribadendo però, giusto per evitare incomprensioni, che per connettersi ai servizi WFS NON è richiesto l'acquisto dell'estensione Data Interoperability, è però necessario che tale estensione sia installata (considerazione valida per ArcView, ArcEditor e ArcInfo).

Ammettiamo quindi di effettuare il download limitando l'operazione alla rete stradale che interessa il comune di Monza (che caso!).
Come prima operazione dobbiamo definire l'area di interesse e per farlo esistono diversi metodi.
Visto che siamo in tema di PCN, suggerirei di rispolverare il mio articolo del 6 febbraio 2009 : caricare in ArcMap i dati del portale cartografico nazionale.

Fra tutte le mappe disponibili, ritengo che la più adatta ai nostri scopi sia quella denominata "Default". Caricandola in ambiente ArcMap otterete il risultato qui sotto:

Si tratta di un servizio di mappa comprendente l'intero territorio nazionale: quindi la base ottimale per definire tutti i BBOX di nostro interesse.
Inoltre, come potete notare dalle proprietà del dataframe (scheda Coordinate System), questo servizio è pubblicato in coordinate geografiche nel datum WGS84, in linea quindi con le nostre esigenze.

Per ottenere i parametri richiesti dall'istruzione BBOX, ho effettuato uno zoom sul comune di Monza e, utilizzando lo strumento New Rectangle, contenuto nella toolbar Draw, ho disegnato un rettangolo tale da comprendere l'intero confine comunale.
Per conoscere le caratteristiche geometriche di questo grafico, è sufficiente accedere alle Properties dell'oggetto e visualizzare la scheda Size and Position. A tale scopo basterà attivare il pulsante Select Elements (freccia nera) ed effettuare un doppio click all'interno del rettangolo.

I parametri da inserire nella richiesta BBOX sono: Xmin, Ymin, Xmax, Ymax.
Quindi, con riferimento alla figura qui sopra, otterremo il seguente risultato: 9.22, 45.55, 9.33, 45.64
Vi faccio notare che, trattandosi di coordinate geografiche, l'unità di misura è il decimal degree (dd), ovvero, tradotto in italiano, il grado sessadecimale.

NOTA inserita il 26/11/2012: con ArcGIS 10.1 NON è più necessario esplicitare le coordinate nella stringa di richiesta MA, come è giusto che sia, si agisce direttamente sui parametri che definiscono il Search Envelope (Minimum X, Minimum Y, Maximum X, Maximum Y), avendo poi cura di attivare il flag Clip to Search Envelope.

A questo punto siamo in grado di impostare la connessione WFS limitando il download all'area scelta come esempio.
I passaggi da effettuare sono tutti sintetizzati nella seguente figura:

Rispetto a quanto avevo indicato nel post del 30 novembre scorso, l'unica differenza consiste nell'impostare diversamente la stringa inserita nella casella Dataset.
In questo caso specifico la stringa corretta è la seguente:
http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/wfs/rete_stradale_wfs.map&service=wfs&version=1.0.0&request=getfeature&bbox=9.22,45.55,9.33,45.64

In pratica occorre sostituire la parte request=getCapabilities con version=1.0.0&request=getfeature&bbox=9.22,45.55,9.33,45.64
(nota inserita il 26/11/2012: come già anticipato, con ArcGIS 10.1 NON è più necessario esplicitare le coordinate nella stringa di richiesta).

Si noti che omettendo la stringa &bbox=9.22,45.55,9.33,45.64 , si indica al sistema di effettuare il download dell'intero tematismo (nota: questa sintassi, a parità di risultato, è formalmente più corretta rispetto a quella utilizzata nell'articolo del 30 novembre).
Se volete verificare di persona, provate a selezionare, nella Tables List, solo il layer delle autostrade.
Il risultato che otterrete è illustrato nella figura qui sotto:

Tornando invece al comune di Monza, il download dell'intera rete stradale interessa circa 9.400 archi e richiede, nel mio caso, circa 2 minuti per essere completato (il tempo, ovviamente, dipende dalla banda disponibile sulla propria linea internet).
Visualizzando l'anteprima del tematismo strade_locali, si ottiene il risultato qui sotto:

ATTENZIONE: nel caso doveste accedere nuovamente alle Connection Properties, dovete considerare che ArcCatalog interpreta come "separatori di richieste" le virgole che, invece, separano le 4 coordinate del BBOX.
Così facendo le sostituisce con una serie di apici (in corrispondenza di ogni virgola, ma anche all'inizio e alla fine di tutta la stringa) che rendono poi inutilizzabile la connessione.
Purtroppo l'unico rimedio che ho trovato è quello di correggere manualmente la stringa
(nota inserita il 26/11/2012: problema risolto con ArcGIS 10.1 !!!).

NOTA A POSTERIORI: come si evince dall'immagine qui sotto, ho provato ad effettuare la stessa operazione anche con la versione 10 di ArcView (vi ricordo che quando pubblicai l'articolo utilizzavo la versione 9.3.1) e confermo che la procedura funziona correttamente.
L'unica differenza - comunque ininfluente ai nostri fini  - riguarda la maschera "Settings", che ora si chiama "Parameters" e che prevede un maggior numero di impostazioni.
Inoltre, come appare evidente in figura, NON è stato ancora risolto il problema degli apici.
Per aggirare l'ostacolo ho anche provato ad impostare il BBOX inserendo le coordinate nel riquadro "Use Search Envelope" ma, dopo alcuni tentativi infruttuosi, mi sono quasi convinto che questa modalità non funzioni. Difficile dire se sia colpa di ESRI o del PCN...
(nota inserita il 26/11/2012: problema risolto con ArcGIS 10.1 !!!).

Per una visione complessiva di tutta la rete stradale, dobbiamo invece ricorrere ad ArcMap.
Qui sotto vedete la rappresentazione dei quattro livelli di strade (nota: il progetto è lo stesso utilizzato per ricavare i parametri necessari alla richiesta BBOX).

Risulta evidente che il donwload ha interessato tutte le strade che intersecano l'area specificata: se ne deduce che l'istruzione BBOX non esegue tagli (clip). Quindi, in altri termini, è sufficiente che una parte dell'elemento sia interna all'area di interesse per essere compreso nel download.

Nulla vieta, applicando la stessa procedura al servizio Comuni fuso 32, di scaricare anche il confine comunale di Monza (nota: in questo caso dovrete inserire gli estremi del BBOX esprimendoli in coordinate cartografiche UTM).
Potrete poi utilizzare il comando Clip di ArcToolBox (lo trovate in Analysis Tools - Extract)  per effettuare il "taglio" delle strade esattamente in corrispondenza del confine comunale...
Ma questo è un altro argomento!

Diamo invece un'occhiata agli attributi associati alle strade, esattamente come rappresentato nella figura qui sotto.

Ai fini pratici ritengo che gli attributi più interessanti siano il Nome e la Tipologia.

Diversi archi risultano privi di nome ma, da una rapida analisi del grafo, mi sembra di poter affermare che si tratta quasi sempre di elementi secondari, spesso di estensione molto ridotta.

Invece, per quanto concerne la suddivisione per tipologia, ritengo particolarmente utile quella impostata sul layer delle strade locali.
La distinzione avviene in 4 categorie:

• Extraurbana
• Urbana Scorrimento
• Urbana Quartiere
• Locale

La figura qui sotto mostra una semplice tematizzazione basata proprio su questo attributo:

Analizzando meglio la mappa ottenuta - una zona che, ovviamente, conosco molto bene - mi sono subito accorto di alcuni errori: ad esempio via Manara, la strada in cui ha sede la nostra azienda, non è affatto una strada statale!!!

Ancora più evidente Piazzale Virgilio (al centro dell'immagine) che, a seguito dei lavori effettuati nell'estate 2008, si presenta oggi come una grande e unica rotonda. Esattamente come indicato nello stradario World Street Map (vedi immagine qui sotto), uno dei tanti layers disponibili gratuitamente sul portale ArcGis Online.
Se non vi ricordate come accedere a questi servizi di mappa, molti dei quali recentemente arricchiti e aggiornati (tra questi proprio World Street Map), fate riferimento all'articolo con il quale ho aperto il blog.

Quest'ultima considerazione mette in evidenza una critica già sollevata in merito ai dati pubblicati dal PCN, ma non solo! Riguarda infatti un pò tutti i soggetti che producono dati, sottoscritto compreso...
Non mi riferisco agli errori in sè stessi, ci mancherebbe!
Vorrei solo evidenziare come il corretto utilizzo di un dato non possa prescindere da una "buona" documentazione dello stesso ovvero, in termini più tecnici, da un buon METADATO.

Quest'ultimo, nel caso specifico, dovrebbe rispondere a domande del tipo:
- a quale data è aggiornata la rete stradale?
- come è stato ottenuto il tematismo?
- come devo interpretare ogni singolo attributo?
- quali criteri sono stati adottati per la suddivisione in tipologie?
- come è pianificata la manutenzione del dato?
- ecc...

Provate ora a visualizzare il "Metadato Completo" che il PCN pubblica in merito a questo tematismo, il link è il seguente: http://www.pcn.minambiente.it/mdSearch/mdView.jsp?ID=727
Secondo voi risponde "veramente" alle domande qui sopra?
Alcune risposte sono facili da immaginare, altre richiederebbero un'analisi di maggior dettaglio, altre ancora sono impossibili da ottenere.
Ma la questione è ben altra: NON dobbiamo "immaginare", dobbiamo poter "leggere" le risposte.

Ad esempio, preso atto che nel metadato non viene indicata la pianificazione in merito al rilascio di nuove releases, come possiamo essere certi che i dati sui quali stiamo lavorando in ArcMap siano effettivamente allineati all'ultima versione disponibile?
Purtroppo, in mancanza di informazioni precise, siamo costretti ad inventarci una procedura alternativa.
Ad esempio, nel caso specifico, suggerirei di agire "ogni tanto" sul tasto Clear Cache che trovate nella scheda Data Interoperability delle Options: in questo modo ArcGIS sarà costretto ad effettuare un nuovo download.

Se invece ritenete di trasferire in un geodatabase i dati - magari per lavorarci in maniera più strutturata - vi segnalo un'alternativa alla soluzione che avevo illustrato il 30 novembre scorso.
Per salvare le features direttamente in un geodatabase, quindi senza l'obbligo di utilizzare ArcMap, potete utilizzare lo strumento Quick Import di ArcToolBox (lo trovate nel ToolBox Data Interoperability Tools e, a dispetto del nome, anche in questo caso NON serve l'acquisto della licenza Data Interoperability) .

Vi faccio notare che anche questa procedura prevede la possibilità di impostare una richiesta BBOX, avete anzi due alternative: utilizzare la logica illustrata in questo post oppure agire sulle impostazioni della connessione, modalità questa più semplice ed intuitiva.
Agendo sul tasto Settings della connessione WFS, apparirà la solita scheda Input Settings for WFS ma, questa volta, in una versione più "ricca":  infatti, come si nota nell'immagine qui sotto, compare anche il riquadro Use Search Envelope, all'interno del quale è possibile specificare le coordinate che definiscono il BBOX (in realtà ho provato a farlo e mi sembra - salvo miei errori - che questa modalità non funzioni...).
Nota inserita il 26/11/2012: problema risolto con ArcGIS 10.1 !!!

Concludo ricordandovi che le informazioni contenute in questo articolo sono parziali: anche in questo caso l'argomento è "immenso" e meriterebbe una trattazione molto più approfondita!
Lascio però spazio ai vostri commenti/richieste per ampliare e descrivere meglio quanto sopra.

Un caro saluto.
PaoloGIS

I servizi WFS del PCN: dati vettoriali scaricabili online!

Cari utenti ArcGIS,
in questo post vi parlo di un sogno diventato realtà.

Mi sto riferendo alla crescente disponibilità di dati geografici sul web, guarda caso l'argomento con il quale ho aperto questo blog. Nel febbraio scorso avevo però trattato questa tematica limitando le mie considerazioni ai servizi di mappa in quanto, fra tutti i web services utilizzati nel settore GIS, sono certamente i più diffusi.

Questo post ha invece come oggetto i servizi di download impostati sullo standard WFS (Web Feature Service),  strumenti che consentono di scaricare strati informativi di tipo vettoriale utilizzando un protocollo, definito a livello internazionale, che garantisce l'interoperabilità fra differenti sistemi.

La disponibilità di questi servizi non è certo una novità e anche in Italia alcuni enti - ancora pochi in realtà - espongono risorse di questo tipo.
Da parte mia ho notato, proprio nell'ultimo periodo, un'attenzione crescente intorno a questa tematica.
In effetti collegarsi ad un sito web, scegliere lo strato informativo di proprio interesse e poterlo scaricare liberamente in locale, è sicuramente un'opportunità da non sottovalutare anzi, per molto tempo, è stato "il sogno" di qualsiasi utente GIS.

In questa sede illustrerò come impostare ArcCatalog per connettersi ai servizi WFS e, ovviamente, come utilizzarli in ambiente ArcMap.
Giusto per chiarire il concetto, vi mostro qui sotto l'anteprima del servizio WFS esposto dal Portale Cartografico Italiano (PCN) e relativo alle province del nord Italia.

Come ho anticipato nell'ultimo post, ho preso spunto dalla richiesta che Marco, il 10 novembre, ha inserito nel nuovo "spazio commenti".
In realtà ero pronto a pubblicare l'articolo già venerdì 20 novembre. Facendo un'ultima verifica, mi sono invece accorto che l'esempio scelto - i servizi WFS del PCN - non erano più in linea. 
Inizialmente ho pensato ad una interruzione temporanea (in effetti anche i servizi WMS e WCS presentavano lo stesso problema), magari per una manutenzione programmata del sistema. Poi, dopo alcuni giorni di inutile attesa, ho deciso di inviare una mail al supporto del PCN e, magicamente, venerdì 27 ho verificato che i servizi erano di nuovo online.
Ad un certo punto ho addirittura pensato fosse colpa di Marco, avevo il sospetto che quell'ingordo, a furia di scaricare dati, avesse stressato il server del ministero al punto da provocarne il crash.

Scherzi a parte, chi si occupa di GIS sa bene che uno dei temi più interessanti del momento riguarda proprio l'interoperabilità, il cui obiettivo è quello di facilitare l'interazione fra sistemi differenti, in particolare per quanto concerne l'accesso ai dati.

In questo contesto assumono grande importanza gli standard definiti da OGC (Open Geospatial Consortium). Per conoscere meglio questa organizzazione mi approprio di un passaggio della pagina di Wikipedia, l'enciclopedia libera ( http://it.wikipedia.org/wiki/Open_Geospatial_Consortium ):
"Open Geospatial Consortium (OGC, in precedenza OpenGIS Consortium) è un'organizzazione internazionale no-profit, basata sul consenso volontario, che si occupa di definire specifiche tecniche per i servizi geospaziali e di localizzazione (location based). OGC è formato da oltre 280 membri (governi, industria privata, università) con l'obiettivo di sviluppare ed implementare standard per il contenuto, i servizi e l'interscambio di dati geografici (GIS - Sistema informativo geografico) che siano "aperti ed estensibili". Le specifiche definite da OGC sono pubbliche (PAS) e disponibili gratuitamente."

Come primo passo è opportuno comprendere cosa si intenda per servizio, in particolare per web service.
Sempre da Wikipedia, vi consiglio la lettura delle prime 10 righe della pagina   http://it.wikipedia.org/wiki/Web_service , dovrebbero chiarire bene il concetto.
In estrema sintesi possiamo affermare che un Web Service nasce per supportare l'interoperabilità tra diversi sistemi informativi.

Caratteristica fondamentale dei servizi basati sugli standard OGC è la totale indipendenza da qualsiasi tecnologia e piattaforma GIS, e ciò, ovviamente, a tutto vantaggio di una migliore interoperabilità fra differenti sistemi.
Grazie agli standard OGC, sistemi diversi possono "dialogare" utilizzando lo stesso "linguaggio".

ESRI, che è uno dei membri principali di OGC, conosce molto bene l'importanza di questo approccio e infatti ArcGIS è da sempre la tecnologia che implementa il maggior numero di standard OGC (per maggior informazioni vi consiglio la lettura della brochure, in italiano, "ArcGIS: standard e interoperabilità", potete scaricarla cliccando sul seguente link http://www.esriitalia.it/index.php?option=com_docman&task=doc_download&gid=10&Itemid=388&lang=it ).

Come già anticipato, lo standard OGC più diffuso è certamente il WMS (Web Map Service), ormai utilizzato da moltissimi enti pubblici italiani per esporre servizi di mappa (per approfondire l'argomento vi consiglio la lettura, sempre su Wikipedia, della seguente pagina:  http://it.wikipedia.org/wiki/Web_Map_Service ).

Si noti però che il WMS non è l'unico servizio di mappa, probabilmente i servizi di mappa più diffusi sono quelli "nativi" di ArcIMS o di MapServer.

Vi segnalo inoltre che anche i servizi esposti tramite ArcGIS Server stanno conquistando sempre più consensi, soprattutto per la loro estrema velocità. Per farvi un'idea date un occhio alle ortofoto 2007 che il GeoPortale della regione Lombardia espone, insieme alla CTR e ad uno stradario, direttamente nella sua Home Page: i tempi di risposta sono veramente impressionanti!

Il WFS - ovvero il protagonista di questo post - è invece uno standard OGC di tipo "Download service" (per maggiori informazioni consultate, ancora da Wikipedia, la seguente pagina http://it.wikipedia.org/wiki/Web_Feature_Service ).
Servizi utilizzati per distribuire "fisicamente" tematismi in formato vettoriale: quindi oggetti geografici più i relativi attributi.
Una volta caricati in ArcMap, l'utilizzo di questi dati è identico a quanto avviene con uno shapefile o una feature class.

Per completare il quadro vorrei dedicare anche un rapidissimo accenno ai servizi WCS (Web Coverage Service) che, in pratica, sono complementari ai WFS. Sono infatti utilizzati per distribuire dati di tipo raster: celle (GRID) più i relativi attributi. Si pensi ad esempio ad un DTM (Modello Digitale del Terreno) e all'associazione tra ogni cella e il corrispondente valore di quota.
Se volete approfondire anche questo argomento, vi consiglio la lettura, sempre su Wikipedia, della seguente pagina: http://it.wikipedia.org/wiki/Web_Coverage_Service

Dopo questa lunga ma doverosa premessa, veniamo ora agli aspetti più operativi!
Per connettervi ai servizi WFS, nel caso specifico quelli del PCN, dovete innanzi tutto accedere alla pagina http://www.pcn.minambiente.it/PCNDYN/catalogowfs.jsp?lan=it  .

1 - scegliete il tematismo di vostro interesse - nel mio esempio le regioni - e cliccate sulla voce capabilities (attenzione a non confondersi con i servizi regioni fuso 32 e regioni fuso 33, ovvero lo stesso tematismo ma già proiettato e suddiviso nei 2 fusi UTM);

2 - apparirà una pagina in formato XML che illustra le caratteristiche del servizio. Ovviamente potete leggere tutto il documento ma, ai nostri fini, è sufficiente copiare in memoria l'indirizzo URL di questa pagina ovvero http://wms.pcn.minambiente.it/cgi-bin/mapserv.exe?map=/ms_ogc/wfs/regioni_wfs.map&service=wfs&request=getCapabilities

3 - aprite ArcCatalog, fate doppio click sulla voce Interoperability Connections e poi su Add Interoperability Connection (nel caso la voce non fosse disponibile, occorre accedere al menu Tools e cliccare sulla voce Options, selezionate poi la scheda General e, nell'elenco superiore, inserite un flag in corrispondenza della voce Interoperability Connections);

4 - nella maschera che appare, selezionate come Format la voce WFS (Web Feature Service) e, nella casella Dataset, incollate l'indirizzo copiato al punto 2. Se avete seguito le mie indicazioni dovreste trovarvi nella situazione rappresentata qui sotto.



5 - cliccate sul pulsante Settings e poi, nella maschera che appare, agite sul pulsante che trovate alla destra della casella Table List;

6 - apparirà la maschera qui sotto, inserite un flag accanto alla voce Select all per selezionare entrambi i tematismi: regioni_f32 (Regioni) e regioni_f33 (Regioni);

7 - cliccate sui vari pulsanti OK per chiudere tutte le maschere e attivare così il collegamento che, salvo rimozione, d'ora innanzi sarà sempre disponibile in ArcCatalog.

A questo punto potete visualizzare la Preview dei 2 servizi per verificare se avete ottenuto il risultato atteso che, salvo inconvenienti, dovrebbe coincidere con le 2 immagini qui sotto (nota: la prima visualizzazione richiede qualche secondo di attesa). 

Si noti che per caricare un servizio WFS in ArcView non è richiesto l'acquisto dell'estensione Data Interoperability, è però necessario che tale estensione sia installata (la stessa considerazione vale per ArcEditor e ArcInfo).
Sembrerebbe un controsenso ma non è così: vi ricordo infatti che i DVD di ArcGIS Desktop consentono l'installazione di tutte le estensioni, l'effettivo utilizzo è invece subordinato al possesso, ovvero all'acquisto, della corrispondente licenza d'uso.

Per verificare se Data Interoperability è installata sul vostro PC, potete lanciare l'utility ArcGIS Desktop Administrator e verificare se nella colonna Installed della scheda Availability appare la voce Yes. In caso contrario dovete solo recuperare il DVD e procedere ad un'installazione Custom che aggiunga questa estensione.

Per caricare i servizi WFS è quindi sufficiente la sola licenza ArcView.
Una riprova, semmai ve ne fosse bisogno, della completezza funzionale del "piccolo" di casa ArcGIS.

Per connettersi ad altri strati informativi in formato WFS, basta ripetere la procedura che vi ho descritto, avendo cura di inserire, al punto 4, la stringa di vostro interesse.
Attenti però ai servizi con molti oggetti associati! Aste fluviali, edificato e diversi altri strati, richiedono molto tempo per essere caricati ... o forse sarebbe meglio dire "scaricati"  (nota: trovate una possibile soluzione a questo problema nell'articolo pubblicato il 21 gennaio 2010).

In effetti ArcCatalog crea autonomamente una copia "volatile" dei dati nella memoria del vostro PC.
La scheda Data Interoperability presente nelle opzioni di ArcCatalog o ArcMap (vedi immagine qui sotto), consente proprio l'impostazione di alcuni parametri associati alla Cache generata dal sistema.

Se invece volete salvare i dati in modo permanente, ammesso che ciò abbia senso, caricate il servizio WFS in ArcMap, cliccate con il tasto destro sul nome del layer, scegliete la voce Data e poi Export Data.
Se vi servono ulteriori dettagli su questo passaggio, chiedete pure a Marco: a giudicare dal commento che ha lasciato in coda alla mia risposta, deve aver fatto una vera e propria indigestione di dati!

In merito all'utilizzo di questi strati informativi, tenete presente che sono sottoposti a specifiche condizioni d'uso. Per chiarirmi le idee ho letto la pagina relativa ai termini di utilizzo ma, in tutta sincerità, ammetto di avere ancora molti dubbi: mi è sembrato di capire che lo stesso ente che mette a disposizione i servizi WFS (nati appositamente per il download dei dati) vieta espressamente la possibilità di effettuare una copia dei dati.
Di fronte a questa incongruenza - reale o presunta - nei giorni scorsi ho deciso di inoltrare una mail al supporto del PCN chiedendo chiarimenti. Purtroppo, ad oggi, non ho ancora ricevuto risposta...

Vi segnalo poi che, oltre al PCN, vi sono altri enti - ancora pochi in realtà - che espongono servizi WFS, ecco tre validi esempi:

Portale Geocartografico Trentino - l'elenco delle capabilities di tutti i servizi è disponibile al seguente link http://www.territorio.provincia.tn.it/portal/server.pt?open=514&objID=23011&mode=2 (la figura seguente mostra l'anteprima delle sezioni di censimento).

In questo caso consentitemi un plauso particolare ai tecnici ed agli amministratori di questo portale perchè mi sembra che senza troppi "fronzoli" forniscano un servizio eccellente!
Premesso che NON ho il piacere di conoscerli personalmente e che la mia valutazione si riferisce - per ora - solo ai servizi WFS, ho trovato il loro approccio di una semplicità e di una chiarezza disarmanti.
Vi esorto poi a leggere i termini di utilizzo oppure la guida operativa del servizio, sono certo che vi ritroverete nel mio giudizio...

Provincia di Lodi - utilizzate il seguente indirizzo URL http://sit.provincia.lodi.it/cartografia_generale.asp per accedere a tutti gli strati informativi esposti come WFS (la figura qui sotto mostra l'anteprima dei confini comunali).

Regione Sardegna - utilizzate il seguente indirizzo URL http://webgis.regione.sardegna.it/geoserver/wfs?request=getcapabilities per accedere a tutti gli strati informativi esposti come WFS .

Vi faccio però notare che nella documentazione di questo servizio (è pubblicata nella seguente pagina http://www.sardegnaterritorio.it/j/v/241?s=29692&v=2&c=2871&t=1 ) si precisa che, per evitare il sovraccarico del server, la regione limita il download a "soli" 1000 oggetti per ogni tematismo.

Vorrei farvi notare come questa scelta - un pò "fuori dal coro" - limiti pesantemente l'utilizzo del servizio: in pratica ho la certezza di aver scaricato tutte le features che compongono uno strato informativo solo se il numero totale di oggetti risulta inferiore a 1.000 (come nel caso del layer rappresentativo dei confini provinciali mostrato nella figura qui sotto).

Come al solito non posso concludere l'articolo senza ricordarvi che:

• la guida online di ArcGIS Desktop dedica un intero capitolo ai servizi OGC. Una lettura certamente utile per chiarire i molti aspetti che NON ho trattato in questo post, il link diretto è: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Using_OGC_services_as_map_layers ;
• attenti ai sistemi di riferimento! I servizi del PCN sono esposti sia in coordinate geografiche che cartografiche, entrambe però fanno riferimento al sistema geodetico WGS84. Per sovrapporre questi dati con strati informativi riferiti ai sistemi Roma40 o ED50, è fondamentale impostare le corrette trasformazioni di datum...

Un caro saluto.
PaoloGIS

PS: prima o poi cercherò di pubblicare un video in cui illustro le modalità finora descritte nel blog per accedere a risorse web: WMS, WFS, servizi ArcIMS e servizi ArcGIS Server...
Forse - ma solo se riesco a non ridere - proverò ad inserire anche qualche commento vocale.

Caricare in ArcMap le ortofoto delle aree terremotate (Abruzzo 2009)

Cari utenti ArcGIS,
pubblico questo articolo per evidenziare l'utilità e l'efficacia della tecnologia GIS in situazioni tragiche e di emergenza come il recente terremoto in Abruzzo, anche se, naturalmente, avrei preferito che una simile occasione non si presentasse...

Inizialmente avevo concepito questo post solo per segnalare una lodevole iniziativa del Portale Cartografico Nazionale. Il PCN infatti ha pubblicato, in tempi ristrettissimi, le ortofoto acquisite in Abruzzo nei 3 giorni successivi al sisma (6 aprile).
Proprio questa rapidità nel divulgare "il dato" mi è sembrata una novità degna di rilievo, perlomeno nel contesto italiano. Da questo elemento, a mio avviso veramente significativo, sono nate una serie di considerazioni.

Ma andiamo per gradi!
Potete accedere alle ortofoto direttamente dal sito del PCN oppure, per un'analisi di maggior dettaglio, potete seguire il mio esempio e caricarle in ArcMap assieme ad altri dati.
Nelle due seguenti figure (click per ingrandirle) potete osservare la situazione dell'abitato di ONNA prima e dopo il sisma. Il confronto parla da solo...





Chi ha già messo in pratica le indicazioni contenute nel mio post del 6 febbraio sarà subito operativo: il collegamento al PCN risulterà infatti già impostato e basterà ri-connettersi.

I layer ai quali mi sto riferendo sono quelli con suffisso "ortofoto_sisma".
Si tratta di immagini a colori di ottima qualità che rendono bene l'entità, purtroppo tragica, di quanto accaduto.
Osservando i danni agli edifici, ho notato qualche coincidenza non ottimale tra fotogrammi adiacenti; immagino però che sia dovuta alla fretta con la quale sono state elaborate perchè fossero subito disponibili.

Comparando le due immagini appare inoltre evidente come le ortofoto del 2009 abbiano una risoluzione geometrica migliore (25 cm/pixel) rispetto a quelle del 2007 (50 cm/pixel).
In altri termini, le immagini del 2009 risultano molto più definite, probabilmente sono state acquisite con un volo a bassa quota.

Se qualche lettore volesse utilizzare il mio stesso documento di mappa, può scaricarlo cliccando sul seguente link: Terremoto93.zip
Tramite il comando "Save a Copy" di ArcMap, ho prodotto anche un MXD in versione 9.2. Gli utenti che utilizzano ancora questa versione possono scaricare il file dal seguente link: Terremoto92.zip .

Come potete notare osservando le due figure, mi sono limitato a caricare in ArcMap alcuni layer accessibili dai servizi PCN e ArcGIS online. Tenete quindi presente che i dati sono "in remoto" e la velocità di accesso, ovvero di consultazione, dipenderà molto dalle prestazioni della vostra connessione internet.

Inoltre, per i lettori che non dispongono di ArcView, ArcEditor o ArcInfo, ho predisposto lo stesso progetto affinchè sia utilizzabile anche con ArcReader: per scaricare questo file, cliccate su TerremotoArcReader93.pmf .
Per chi ancora non lo avesse installato, segnalo che ho indicato tutte le istruzioni per trovare, scaricare ed installare ArcReader nel mio articolo del 27 marzo .
Ricordo a tutti che si tratta di un software libero e gratuito.
Pubblico la seguente figura proprio per mostrare come si presenti il progetto se "visto" tramite ArcReader.



Potete anche notare come abbia utilizzato lo strumento "Markup" per perimetrare rapidamente (in 30 secondi circa) alcune aree che appaiono completamente distrutte.
In ambiente ArcMap, la stessa operazione deve essere ovviamente effettuata utilizzando un geodatabase e non dei semplici graficismi: in questo modo i dati trovano una "sede" certamente più adatta per essere elaborati ed analizzati.
Immagino che la protezione civile adotti proprio una logica di questo tipo e che, probabilmente, abbia predisposto negli anni geodatabase o shapefile "standard", cioè strutturati in funzione del particolare ambito di utilizzo: sisma, alluvione, incendio ecc.

Come anticipato all'inizio di questo post, ritengo che la pubblicazione delle prime ortofoto a soli 3 giorni dal sisma, sia una novità importante nel panorama italiano.
Quindi, in qualità di esperto GIS, vorrei innanzi tutto complimentarmi con il PCN e con la Protezione Civile.
Mi sembra questo un ottimo esempio di buon funzionamento del "sistema": la Protezione Civile effettua la ripresa e, nel giro di pochissimo tempo, i dati possono essere distribuiti via web, caricati nei vari software GIS e utilizzati da analisti e decisori per affrontare l'emergenza.
Resta inteso che gli stessi dati saranno una risorsa indispensabile anche per definire e pianificare tutti gli interventi successivi alla vera e propria emergenza, nel medio e lungo periodo.

Il mio entusiasmo deriva dalla convinzione che un buon connubio tra lungimiranza, tecnologia ed organizzazione, possa sempre produrre notevoli risultati.
Premesso che l'iniziativa del PCN è certamente in linea con questa logica, ho l'impressione che ancora molto si debba fare.
In questa seconda parte dell'articolo, vorrei quindi esporvi alcune considerazioni ovviamente legate alla tecnologia GIS: "idee" facilmente attuabili e, a mio avviso, molto efficaci.
Vorrei però precisare che NON sono un esperto di protezione civile, quindi non escludo che su alcune osservazioni potrei essere smentito.

Inizio segnalandovi una delle tante attività che avrebbero reso meno pesante il bilancio delle vittime.
Il tutto è nato assistendo ad un'intervista di un vigile del fuoco il quale, fra le mille difficoltà incontrate, segnalava anche quella di non riuscire a determinare sotto quali macerie potessero trovarsi eventuali vittime, un dato ovviamente fondamentale per stabilire dove concentrare gli sforzi.
In effetti, la zona in cui stava prestando soccorso si presentava quasi completamente distrutta e, di conseguenza, deserta (forse si trattava proprio di Onna): nessun numero civico al quale far riferimento, nessuna persona del luogo per ottenere indicazioni utili.
In questi frangenti è facile immaginare quanto sia importante ottimizzare l'opera dei soccorritori per agire bene e rapidamente.

Mentre l'intervistato descriveva la sua esperienza, mi è venuto spontaneo pensare alla lungimiranza di un'amministrazione comunale che, nel tempo, ha provveduto a georeferenziare la propria anagrafe. Nulla di trascendente: si tratta semplicemente di associare ogni residente a una coppia di coordinate cartografiche, per esempio quelle che identificano la posizione del numero civico esposto fuori dalla propria abitazione (magari perchè in cartografia quel numero è già presente!) oppure, meglio ancora, associando i residenti agli edifici stessi.

Un'operazione che noi del settore sappiamo essere semplice, rapida ed anche molto economica!
Personalmente, applicai questo concetto per la prima volta nel 1999: in qualità di consulente di una ditta di servizi di nettezza urbana, fui incaricato di fornire il supporto GIS necessario per programmare la raccolta dei rifiuti sul comune di Monza, che, per popolazione, è la 3° città della Lombardia e conta da sola circa 120.000 abitanti. Tenete presente che l'intera provincia dell'Aquila ne ha circa 300.000...
Logico immaginare che 10 anni fa non si parlasse ancora di database topografici (DBT); i numeri civici però erano già riportati sulla cartografia comunale, a quel tempo disponibile in formato DWG.
In pochi giorni ottenemmo uno shapefile puntuale in cui ogni elemento risultava associato ad un indirizzo. L'operazione fu condotta secondo la convenzione utilizzata dall'anagrafe comunale, di conseguenza l'unione di questi dati con la tabella fornita dall'ufficio anagrafe fu una semplice formalità: nel giro di 3 giorni riuscimmo a georeferenziare oltre il 90% della popolazione, circa 100.000 persone.

E il restante 10%?
Semplice: si trattava dei residenti corrispondenti a numeri civici non rappresentati in carta in quanto non rilevati durante i controlli a terra, magari perchè i numeri non erano esposti o erano coperti da vegetazione...
Nel caso specifico, "investimmo" ancora 2 giorni per localizzare almeno gli indirizzi corrispondenti al maggior numero di abitanti.
In pratica, in 5 giorni di lavoro localizzammo sul territorio circa il 97% della popolazione, un risultato più che soddisfacente per gli obiettivi di quel lavoro. Valutammo quindi di non proseguire: il rapporto costi-benefici fu considerato infatti troppo elevato.
Per maggior chiarezza, aggiungo che se dovessi quantificare oggi i costi di quell'attività, potrei ipotizzare una cifra di circa 1.500 euro...

Un'operazione, quindi, "semplice ed economica", ma anche estremamente utile!
Infatti l'anagrafe georeferenziata può risultare vantaggiosa anche in molti altri casi...
...ad esempio dopo un terremoto così devastante!
Infatti consente l'avvio di una procedura che, a mio modesto parere, avrebbe potuto ottimizzare l'opera dei soccorritori.
- la protezione civile, che immagino raccolga e aggiorni costantemente gli elenchi delle persone disperse, potrebbe incrociare i propri dati con i geodatabase forniti dai competenti uffici comunali...
- un servizio webgis (magari proprio il PCN) pubblicherebbe in diretta tutti i punti (ovvero gli indirizzi) che corrispondono alle persone ritenute disperse...
- i soccorritori, muniti di palmare dotato di ricevitore GPS e telefonia, potrebbero raggiungere rapidamente i punti evidenziati in mappa e concentrare gli sforzi in aree più limitate.

Tengo a precisare che, anche nel caso dei palmari, non intendo fare necessariamente riferimento a soluzioni sofisticate e professionali: infatti per questi utilizzi sono più che adatti i dispositivi da 200-300€ che trovate nei centri commerciali.
Tanto per intenderci, penso ai PDA Phone di tipo "economico" come quello rappresentato nella foto qui sotto, una tipologia che descrivo meglio nel mio post su ArcPad 8.



Purtroppo la foto non rende bene l'idea... Potete però intuire come l'immagine rappresentata sullo schermo sia proprio l'ortofoto pubblicata dal PCN: questo PDA è infatti dotato di telefonia e può quindi connettersi a internet.

Immagino anche che, con il passare del tempo, i punti diminuiscano o comunque risultino sempre più "affidabili", permettendo così una rapida e continua razionalizzazione dei soccorsi.
Sono consapevole del fatto che non si tratti di un metodo rigoroso, nel senso che non si può essere certi che ad ogni punto corrisponda effettivamente uno o più dispersi; ritengo però che, nel caso specifico, avrebbe prodotto buoni risultati.
Infatti, dato che il sisma è avvenuto in piena notte, è logico attendersi che la maggior parte dei dispersi si trovasse nelle proprie abitazioni.

Da notare poi che questi PDA "economici" non solo consentono di ricevere dati, ma anche, ovviamente, di trasmetterli.
In sostanza, si potrebbe conoscere, in tempo reale, la posizione esatta (intendo con una precisione di circa 5 metri) dei singoli soccorritori, delle squadre, dei mezzi e di tutte le "risorse" in movimento sul territorio...
...il salto di qualità sarebbe enorme: da una localizzazione a livello di singolo comune (es: 1000 soccorritori nel comune di L'Aquila) ad una "puntuale".
Pensate che beneficio per chi coordina tutte le operazioni e, di conseguenza, per chi riceve i soccorsi!

Sappiamo tutti che una logica di questo tipo viene applicata, ormai da molti anni, in campo militare. Anche in ambito civile vi sono diverse applicazioni, ad esempio alcuni veicoli del 118 trasmettono, ad intervalli specifici, la loro posizione sul territorio. Questo dato viene elaborato in tempo reale da una sala di controllo, il cui compito è proprio quello di ottimizzare gli interventi.

I soccorritori potrebbero inoltre utilizzare i palmari per segnalare eventuali necessità o situazioni particolari: e ciò semplicemente inserendo un punto in mappa. Quel "punto" potrebbe finire immediatamente su un geodatabase centralizzato che, in tempo reale, mostrerebbe ai vari analisti, e quindi ai decisori, dove concentrare gli sforzi o dove inviare risorse.

Giusto per non lasciare dubbi ai lettori, ribadisco un concetto fondamentale: dal punto di vista tecnologico, tutto quello che ho finora descritto è semplice da implementare e non richiede grandi investimenti economici.

A questo punto, ritengo anche opportuno pubblicare una delle slides che mostro ai miei studenti nella prima lezione del mio corso.



Tengo a far notare che si tratta di un concetto molto generale e legato ai sistemi informativi in quanto tali, con o senza componenti "geografiche".
Se volessimo ridurre la mia slide ai minimi termini, il "messaggio" potrebbe essere in sintesi: CONOSCERE -> ANALIZZARE -> OPERARE
Ne deriva che conoscere e analizzare "bene e rapidamente" sono condizioni necessarie, anche se non sufficienti, per operare "bene e rapidamente"...

A questo punto, cliccate sulla seguente immagine per ingrandirla e ditemi se non "riconoscete" molti degli strumenti e delle risorse alle quali, indirettamente, ho fatto riferimento in questo articolo....



Nel mio post del 26 marzo, ho cercato di spiegare come l'estrema modularità e la completezza della famiglia ArcGIS debba essere considerata una "ricchezza" e non, come spesso avviene, una complessità "esagerata".
E' evidente come, per una gestione ottimale di certe situazioni, siano necessari sistemi GIS in cui "convivono" contemporaneamente software di fascia server, desktop e mobile.
Laddove il tempo è una variabile estremamente critica, è certamente auspicabile che tali strumenti appartengano tutti alla stessa famiglia: si eviteranno così problemi di interoperabilità e di "dialogo".
Anche la possibilità di disporre di moduli aggiuntivi, in grado cioè di ampliare le funzionalità di ogni strumento di base, assume in questo senso un ruolo importante, permettendo di scalare le soluzioni in funzione delle reali necessità di ogni singola postazione.

E laddove tutto questo non serve?
Basta indirizzarsi verso soluzioni più semplici: non a caso spesso e volentieri risulta più che sufficiente il solo ArcView!

A questo punto direi che ho scritto fin troppo...
Spero di essere riuscito a trasmettere 2 messaggi estremamente importanti:
- la tecnologia GIS, se ben utilizzata, può produrre notevoli benefici anche in situazioni di emergenza;
- si possono ottenere grandi risultati anche a fronte di piccoli investimenti.

A scanso di equivoci, ribadisco ancora una volta il concetto: NON sono un esperto di protezione civile e NON voglio alimentare inutili polemiche. Queste mie osservazioni vogliono solo invitare a riflettere.
Sono certo che, tra i lettori di questo blog, ci siano persone molto competenti su queste tematiche: magari potrebbero confermare le mie considerazioni, oppure smentirle (e ne sarei molto felice!), oppure proporle nelle sedi più appropriate per migliorare la gestione delle emergenze.
Sono altrettanto certo che anche tra i lettori "meno esperti" di protezione civile possano nascere "idee" molto più utili ed intellligenti delle mie.
Anche questo è un modo per aiutare la popolazione dell'Abruzzo e, più in generale, tutti coloro che vivono in aree a rischio.

Concludo con alcune considerazioni piuttosto ovvie:
- è necessario investire ancora molto, almeno in Italia, sulla "cultura GIS", a partire dai nostri amministratori che troppo spesso sostengono i sistemi GIS solo a parole;
- non ha alcun senso disporre di "risorse" così notevoli (hardware, software e dati) se le stesse, per scarse conoscenze o errate valutazioni, non vengono adeguatamente sfruttate;
- i sistemi GIS sono, innanzi tutto, "sistemi": è sufficiente una sola componente sottodimensionata per limitare le prestazioni complessive. Mi riferisco in particolare alle "persone": operatori e utenti finali spesso non sufficientemente preparati.

Nell'era della tecnologia "l'uomo" resta pur sempre l'elemento centrale...

Saluti
PaoloGIS


SUGGERIMENTO IMPORTANTE: chi volesse confrontare (ovviamente in ambiente ArcMap) le ortofoto oggetto di questo articolo con immagini satellitari di altissima qualità, dovrebbe mantenere "monitorato" il servizio di Digital Globe descritto nel mio post del 17 febbraio.
Infatti, se accederete alla home page del sito (http://www.digitalglobe.com/) , troverete in primo piano un interessantissimo documento PDF che confronta un'immagine acquisita il 4 settembre 2006 con una del 8 aprile 2009 (ovvero 2 giorni dopo il sisma).
Il satellite è lo stesso, il QuickBird, e le immagini prodotte da questo "gioiello" hanno una risoluzione geometrica al suolo pari a 61cm.
A mio avviso, questa ripresa sarà pubblicata entro breve e andrà a sostituire l'immagine attualmente disponibile, quella del 4 settembre 2006.
Se così sarà, assisteremo a un altro beneficio della tecnologia!