Unce upon a time there was a hot summer and dark room. And there was a lazy nerdy Sunday morning. I remember quite well that weekend.

The time was up to try to develop something on Android. In the past I had tried to develop applications on Zaurus, on Dell Axim, on some Nokia smartphone, but the results had been disappointing every time. There had to be something easier, where one could throw his ideas and make simple applications out of it… in one weekend.

The nerdy Sunday, wakeup call at 6, checking emails with coffe’ and cookies, seemed to be inspiring. A couple of days before an email had arrived about a new book, available in “review-reading” mode as pdf version: Unlocking Android, a developer’s guide by Ableson et alter. I decided to give it a possibility.

Well, I found the book so easy to read through, that I gave the first application a try. I really wanted to create a lightweight application that would help out in field surveys and would have those features, that the tablet pc field mapping application didn’t have. Above all the possibility to record the orientation of the pictures taken during the survey, so that they would show the direction of the snapshot when imported on a map. And I really liked the idea of having a mapping device always in my pocket. The motto has always been: “Gather as much information as you can. Always. The GIS will then help you to sort it out.”

That Sunday experiment went way better than I had ever hoped, by the evening I had great satisfaction with my simple, new and most of all GPS logging application. It was already able to take text notes and track lines. I got really excited about the possibilities to create a small version of BeeGIS… well, at that point I knew the time was up for Geopaparazzi.

From that moment on things went quite smooth. We started developing a simple OpenStreetMap based view, we created an import tool for Geopaparazzi in BeeGIS. We were using it in our daily job, and that was simply awesome. As we usually do at HydroloGIS we open sourced the application and published it on the market, in the hope that people would buy it and through that act support our other open source projects: JGrasstools, JGrass, BeeGIS and uDig.

 

The thing we were most proud of, was that it would handle shooting direction:

 

which, once imported into BeeGIS, would result in geonotes containing the picture and showing through a small arrow the direction in which the photo had been taken:

 

As time passes by and as open source software works, one starts to exploit components other teams are specialized in.

So at some point Geopaparazzi decided to remove the compass view to present the much more user friendly dashboard. The android system makes it very easy to call views from other applications. geopaparazzi therefore chose to present a compass button that calls the compass view from the Status GPS project, which is freely available in the market.

 

 

At that point Geopaparazzi 2 was released, which brought a new, more userfriendly dashboard view:

 

From the beginning Geopaparazzi only wanted to deal with data collection, which is why with the time the possibilities to describe the data to collect were enhanced. The new form based tags were introduces, through which it is possible to describe the data structure as forms that appear as tag buttons:

 

Once the button is pushed, the form is generated from a user created description:

 

 

Geopaparazzi 2 also brought the integration with the osmdroid project, a project that supplies a map view that caches OSM map tiles that can be accessed also in offline mode. This gave the possibility to enhance a bit the usability of the map view, also adding the bookmarks facility:

 

That more or less brings us to where we are now. Some interest has grown around Geopaparazzi and that makes us very happy.

The  Osaka Water General Service together with the Osaka University has adapted it to use it for the collection of information about water-supply infrastructure to promote post-disaster recovery for water supply under the guidance of Venkatesh Raghavan.

 

We worked on a customized version of Geopaparazzi to keep waste management information uptodate. Through the trashmapper it is possible to sample and update information out in the field and then syncronize the data with a central database/webgis.

Since in this project the new generation tablets are being used, we got to tweak it for better user experience on tablet screens:

 

Arrived to that point, it was about time to move to the next level. Geopaparazzi has always been a free and open source application. It was sold in the android market but the code has always been accessible. What we want to achieve now that it is a stable product, is to attract some developers to cooperate on the project and enhance its functionalities. That is why from today on Geopaparazzi can be found in the market for free. From today on it is not only free as in speech, but also as in beer.

A few final considerations: the new generation tablets are more or less like pcs and maybe the idea to avoid too much mapping capabilities in Geopaparazzi might be a decision that it is time to review. Maybe instead it is time Geopaparazzi starts to slowly take over the job of old and heavy BeeGIS, with new data and connectivity functionalties and mapping capabilities. The doors are open, even if the main paradigma has to be kept strickt in mind: the tools needs to stay as simple and usable as possible. If you are interested to contribute, feel free to stop by at our mailinglist and have a chat with us. If you want to try it out, simply access the market and search for geopaparazzi.

 

 

TANTO si è già occupato di Stati Generali per l’Innovazione, per esempio qui, e alcuni di noi partecipano alle discussioni iniziate sul forum del sito, su FB, su Twitter e altrove, in preparazione dell’evento previsto a Roma, il 25-26 novembre 2011.

Questo scritto unisce due miei post, pubblicati sul sito di SGI: qui e qui. Incontrandoci al “bar dietro al router” capita talvolta che uno di noi esclami frasi come: “Pensa tu quante idee su usi e applicazioni dei dati geospaziali ci saranno fuori dal ‘circolo dei geomatici’?”.

L’appuntamento di Roma è un’occasione per l’incontro tra addetti ai lavori, portatori d’interessi e utilizzatori. Complice l’atmosfera concentrata sulle possibilità di crescita per il nostro Paese, potrebbero scoccare scintille a cui fornire carburante.

 

Perché partecipare a Stati Generali Innovazione

Le informazioni territoriali hanno assunto un ruolo strategico nelle politiche di sviluppo e innovazione di tutti i paesi industrializzati. Il ruolo dell’informazione territoriale è determinante in molti settori del sistema Paese: industriali (infrastrutture di trasporto, reti tecnologiche, ecc.), finanziari nonché agroalimentari per citarne alcuni. Naturalmente, esse sono indispensabili nel governo del territorio, ad esempio per la prevenzione di tutti quegli eventi – spesso catastrofici – che purtroppo colpiscono il nostro Paese e mitigarne i danni.

La Pubblica Amministrazione rappresenta generalmente il soggetto più rilevante nel processo di qualificazione della domanda e di acquisizione delle informazioni. Essa funge inoltre da volano in molti settori menzionati. Infine, le informazioni territoriali sono anche alla base delle tecnologie digitali che stanno cambiando il nostro modo di interagire con le persone e ciò che ci circonda: Location awareness, Digital interaction, Towards all things computing e Augmented reality… rivestendo quindi un peso rilevante per il futuro dell’economia digitale.

Una prima peculiarità delle informazioni territoriali è quella di essere molto onerosa in termini economici nella fase di acquisizione rispetto a quella di gestione e utilizzo. E’ fondamentale definire regole e standard perché essa, una volta acquisita, possa essere integrata alle altre fonti, anche integrando quelle informazioni provenienti ‘dal basso’, ovvero create dagli stessi utilizzatori (informazione geografica ‘volontaria’). E’ inoltre indispensabile che il sistema pubblico possa lavorare in modo collaborativo, ottimizzando i finanziamenti a disposizione, razionalizzando la produzione e la gestione di tali informazioni, evitando la creazione di duplicati da parte di enti/istituzioni differenti.

Un’altra peculiarità delle informazioni territoriali è quella di essere posseduta e mantenuta tra numerosi soggetti. E’ fondamentale incoraggiare la costituzione di infrastrutture per accrescere l’accesso e la disponibilità di geo-dati, la cui organizzazione sia basata sulla co-operazione: per l’integrazione e l’armonizzazione dei dati, per condividere le policy riguardanti la loro distribuzione. Occorre individuare modi che aiutino il ri-uso delle informazioni geo-riferite e la valorizzazione delle applicazioni della geomatica per tutte le sfide che attendono la nostra società, (ICT per l’ambiente, assistenza medica sostenibile, promozione della diversità culturale, eGovernment, mobilità di persone e merci, …).

Infine, una terza peculiarità delle informazioni territoriali è quella di essere essenziale per far prosperare la ricerca e l’innovazione del comparto: realizzare nuovi prodotti e servizi legati all’intrattenimento, alla mobilità individuale e collettiva, all’assistenza alle persone, ecc.; per la corretta comprensione dei fenomeni che avvengono nella realtà; per creare nuove professionalità e nuove occupazioni. Rafforzare il dialogo tra il mondo della Geographic Information e l’ICT nella sua globalità può generare nuove idee per la ricerca e orientare le strategie per attuare servizi in scenari futuri, in contesti di complessità crescente, coinvolgendo i cittadini, soprattutto per rispondere alle esigenze delle giovani generazioni.

Il mondo dell’Informazione Geografica deve partecipare e contribuire –uno tra tutti- come portatore d’interesse per la costruzione di una prospettiva condivisa per l’Italia e per un cambio effettivo nella politica dell’innovazione, verso la realizzazione di un sistema di innovazione diffusa, un’innovazione che nasce dalle comunità e che al benessere delle comunità, in quanto reti relazionali, economiche e sociali, è principalmente rivolta.

Perché discuterne in Stati Generali Innovazione

A partire dall’epoca napoleonica fino agli anni ottanta del secolo scorso la gestione delle informazioni geografiche di una nazione sono state governate prevalentemente da soggetti statali: ad esempio Ordnance Survey – UK, Service du Cadastre – Francia; gli enti cartografici militari e catastali, dell’Italia unitaria).

Questa soluzione organizzativa ha assolto le esigenze per il governo del territorio sino a quando l’incremento della produzione di cartografica da parte di altri enti, soprattutto a livello regionale e locale, indotto da un maggiore fabbisogno di dati territoriali e di migliore qualità, supportata dall’avvento di nuove tecnologie, hanno fatto emergere l’esigenza di definire nuove modalità organizzative.

Dall’inizio degli anni novanta è iniziata la ricerca di soluzioni per razionalizzare la produzione dei dati territoriali tra i diversi livelli della Pubblica Amministrazione, originariamente in un’ottica molto pragmatica: ridurre l’impegno economico e garantire un uso più efficiente delle risorse per acquisire e gestire i dati geospaziali. Si deve alla presidenza Clinton la costituzione della National Spatial Data Infrastructure, nel 1994: una deliberazione per promuovere le relazioni intergovernative, coinvolgendo i governi statale e locale nella produzione di dati geospaziali e migliorare le prestazioni del governo federale. A seguire, altri Paesi hanno avviato progetti analoghi (Australia, Canada, Giappone, …). Nel 2002 la Commissione europea ha lanciato un progetto, denominato INSPIRE, che mira a creare una Spatial Data Infrastructure  europea.

Nel tempo, gli obiettivi di queste infrastrutture sono stati ampliati: si è fatta strada anche la promozione dell’uso dei dati geospaziali e del loro riutilizzo per molteplici scopi, non solo in ambito pubblico ma anche con crescente attenzione verso il settore privato, stante l’incremento di prodotti e applicazioni rivolte al mercato consumer.

Mentre questo processo è ancora in corso, nuovi temi sono apparsi, e influiscono sull’implementazione delle Spatial Data Infrastructure: espressi dal mercato (“l’uragano” Google maps), tecnologici (il semantic web, Internet of things, il cloud computing, …), sociali (Volunteered  Geographic Information), del settore pubblico (Open Government).

Dato per scontato il coinvolgimento del mondo della geomatica in questo scenario, le sue implicazioni e le sue diramazioni offrono lo spunto per ampliare ad altri ambiti la discussione e il confronto sulle prospettive, le opportunità che si prospettano, come sfruttarle, come affrontare e risolvere le problematiche e le criticità che si presenteranno.

Ho volutamente affrontato l’argomento prendendolo “da distante”. Le scelte per soddisfare i bisogni di informazioni geografiche di un Paese, sono state prese in passato (remoto e recente) dal livello politico, e non vi è ragione di immaginare un approccio differente: l’Informazione Geografica oggi, come le mappe in passato, sono un pilastro per il governo e lo sviluppo di un Paese. Proprio in ragione di ciò, essa è anche patrimonio della collettività. Seguendo l’invito di Stati Generali dell’Innovazione, l’estensione a un più ampio spettro di portatori d’interesse il dialogo sull’informazione geografica potrebbe dare contributi alla classe dirigente per attuare scelte rivolte “alla realizzazione di un sistema di innovazione diffusa, un’innovazione che nasce dalle comunità e che al benessere delle comunità, in quanto reti relazionali, economiche e sociali, è principalmente rivolta.”

Il melting pot su #opendata, #opendataitaly e #opengov ribolle sempre più anche qui in Italia, lo confermano le numerose Pubbliche Amministrazioni che stanno progressivamente mettendo in piedi portali che consentono l’accesso ai propri dati (con i dovuti distinguo riguardo le licenze adottate), un trend culminato con il recente lancio di dati.gov.it

Gli Stati Generali dell’Innovazione (@SGInnovazione) sono un movimento di associazioni, cittadini e aziende che, rimestando nel melting pot, contribuiscono a creare massa critica attorno ad alcuni degli argomenti che sono alla base di ciò che ci interessa maggiormente: “l’innovazione nel governo dell’Italia”.

L’appuntamento odierno di Bari, tenutosi al Cineporto presso la Fiera del Levante, prevedeva una sessione mattutina con una prima tavola rotonda dal titolo “Open source, software libero e formati aperti per i dati pubblici: esperienze, criticità, prospettive”, alla quale hanno partecipato l’Assessore regionale all’Innovazione Nicola Fratoianni, Davide Pellegrino – Dirigente Servizio Innovazione della Regione Puglia, Marco Curci – Direttore Divisione IT di Innovapuglia, Giuseppe Santo Barile (@realforense) del LUG Bari e Giuseppe Nicosia – Circolo dei Giuristi Telematici Gur@work, in collegamento Skype è stata con noi anche Flavia Marzano (@flavia_marzano) di Stati Generali dell’Innovazione, moderava Morena Ragone (@morenaragone) di Puglia Creativa.

La seconda sessione intitolata “I diritti dei cittadini e delle imprese nel Codice dell’Amministrazione Digitale” ha visto come relatori Ernesto Belisario (@diritto2punto0) – Circolo Giuristi Telematici, Andrea Lisi – ANORC Associazione Nazionale per Operatori e Responsabili della Conservazione Sostitutiva, Morena Ragone – Puglia Creativa e Giovanna Brunetti – CSIG Bari, moderava Ennio del Turco – CSIG Bari.

Numerosi e di notevole spessore sono stati gli interventi del pubblico, che hanno contribuito a rendere l’appuntamento particolarmente ricco di spunti, idee, confronti e anche scontri costruttivi. Io ho dovuto lasciare i lavori alla conclusione della mattinata, che comunque proseguivano con due ulteriori interessanti sessioni pomeridiane “Presentazione degli Stati Generali dell’Innovazione di Roma del 25-26 novembre 2011″ e la tavola rotonda “Pensare l’innovazione, realizzare l’innovazione: dalle parole ai fatti, idee e problematiche aperte”.

Vi invito a scorrere il succedersi degli eventi qui sotto, nella timeline dell’hashtag dedicato all’evento #SGIBari

I nostri più assidui lettori sicuramente ricorderanno un “vecchio” post di Andrea Borruso dal titolo “Il tasto destro per alleggerire un po’ il lavoro di chi si occupa di GIS (su Windows e su Linux)”, un evergreen del nostro blog tra i più visitati di sempre. Ebbene, in accordo con la postilla che scriviamo in calce ai nostri post dopo un anno dalla loro pubblicazione (ci teniamo a ricordarlo!), il post di Andrea, pur sempre attualissimo, merita un aggiornamento in virtù del fatto che il software Open++ da lui brillantemente recensito ha subito di recente alcune evoluzioni significative tali da rendere inefficaci le istruzioni scritte all’epoca (…ben due anni e mezzo fa!).

In particolare, Andrea ci mostrava come configurare Open++ in modo da “automatizzare” l’utilizzo di alcune utility dello swiss knife geospaziale per eccellenza: la libreria GDAL. Cercheremo pertanto di ottenere lo stesso risultato di allora, utilizzando stavolta l’ultima release di Open++ (v. 1.5.1).

Partiamo innanzitutto dal notare che la struttura della finestra di dialogo di Open++ è leggermente cambiata rispetto al passato. In luogo della scheda Language, ora ne sono presenti altre due: Install/Uninstall e About. Tralasciando l’ovvio significato di quest’ultima, la scheda Install/Uninstall è stata introdotta in sostituzione del vecchio installer, rendendo quindi l’applicazione portabile (può essere eseguita su una semplice chiavetta USB). La scheda principale (Commands) è apparentemente rimasta invariata rispetto al passato. Tuttavia, come ci fa notare Chiara (una lettrice che di recente ha commentato il post di Andrea, sollevando il problema), qualcosa è cambiato nella versione 1.5.1 (probabilmente anche prima): si tratta essenzialmente delle variabili utilizzabili nella casella di testo in cui andiamo a configurare i nostri comandi e, in particolare, quella degli argomenti (Arguments), come mostrato nella figura seguente.

Tali variabili, per quanto siano di una chiarezza quasi disarmante, risultano però meno flessibili da gestire rispetto alle versioni precedenti specie quando, come nel caso delle utility della libreria GDAL, il nostro comando accetta due o più parametri basati sul nome del file in ingresso. Fortunatamente, ci viene in soccorso l’unica FAQ presente nell’help file di Open++ (abbastanza criptico, in verità…) in cui è mostrato l’utilizzo di un ciclo for in linguaggio batch all’interno degli argomenti. Dunque, se è possibile usare il linguaggio batch, è altrettanto possibile usare anche i parametri batch e trarne così beneficio nel gestire i nomi dei file con o senza le loro estensioni. Ovviamente un ciclo for è applicabile anche su un singolo file e quindi il gioco è fatto!

Andando al sodo, per prima cosa consiglio di aggiungere la cartella dei binari di GDAL (o di FWTools, se preferite) all’interno della variabile PATH di sistema. Così potrete facilmente eseguire qualsiasi tool di GDAL all’interno di una qualsivoglia cartella, senza la necessità di dover riscrivere il suo percorso. In questo altro post sempre di Andrea (lo “swiss knife” di TANTO ) è descritto come fare. Nel seguito, assumerò che lo abbiate fatto.

Quindi aggiungiamo un separatore delle opzioni di menù nella scheda Commands di Open++ e proviamo a configurare l’utility relativamente più semplice tra quelle trattate da Andrea: gdalinfo. Per prima cosa, scriviamo “GDALinfo” come titolo. Poi, trattandosi di una utility che si esegue da riga di comando, il programma da utilizzare sarà %ComSpec%, ovvero il nome della variabile di ambiente usata da Windows per indicare l’interprete da linea di comando (CLI), solitamente cmd.exe. Fin qui nulla di nuovo rispetto al post di Andrea. Negli argomenti, invece, scriveremo:

/k gdalinfo %FilePath%

La spiegazione è piuttosto semplice: /k significa che vogliamo mantenere la finestra aperta dopo l’esecuzione del comando (altrimenti non riusciremmo a leggere le informazioni), gdalinfo è il nome dell’eseguibile dell’utility e, quindi, %FilePaths% è una variabile che rappresenta il vettore dei percorsi dei file passati come parametro. La directory di lavoro coincide con la directory del file stesso (%FileDir%), scegliamo eventualmente un’icona per rappresentare il comando, associamo il comando al singolo file e, infine, esplicitiamo le estensioni possibili del file in ingresso. Nulla di trascendentale, verrebbe da pensare.

Le cose si complicano, invece, quando andiamo a mettere in pratica l’esempio di Andrea relativo a gdal_translate. La procedura è sostanzialmente identica al caso precedente, ad eccezione dell’argomento. Tuttavia, come anticipavo in precedenza, ci viene ottimamente in soccorso l’unica FAQ a disposizione. E, pertanto, l’argomento da scrivere per convertire in formato JPEG sarà:

/c for %i in (%FilePaths%) do start gdal_translate -of JPEG %~nxi %~ni.jpg

che, in pratica, significa che per tutti i file contenuti nel vettore dei percorsi %FilePaths% (nel nostro caso, contiene un unico percorso in quanto selezioneremo un unico file) esegue il comando gdal_translate -of JPEG %~nxi %~ni.jpg, dove %~nxi è il nome compreso di estensione del raster sorgente, mentre %~ni è il nome privo di estensione del raster di destinazione, seguito poi da .jpg.

E non è ancora tutto! Visto che usiamo un ciclo for come argomento e che Open++ prevede l’associazione dei suoi comandi anche ad un insieme di file, possiamo quindi rendere la conversione in JPEG in modalità batch. A tal fine, creeremo sostanzialmente una copia del Convert to JPEG in cui aggiungeremo solo il termine (batch) alla fine del titolo e poi cambieremo l’opzione Associate with da Single File a Multiple File. Possiamo quindi selezionare più file raster e da menù contestuale scegliere l’opzione Convert to JPEG (batch) per avere la conversione in blocco di tutti i file selezionati. E’ quindi adesso facile definire altri comandi di conversione verso altri formati raster supportati da GDAL …e non solo!

Per i più pigri, ecco il file di configurazione OpenXX.ini dei comandi descritti in precedenza. Basta copiarlo nella cartella contenente Open++, eseguirlo …et voilà …si otterrà la stessa identica configurazione. Si tratta di un metodo semplice e rapido per condividere le proprie raccolte di comandi con i colleghi.

Una nota a margine: in caso si decida di definire comandi per effettuare operazioni di coordinate, occorre aggiungere alla variabile PATH di sistema anche il percorso della cartella di GDAL (o eventualmente della libreria proj.4) che contiene le definizioni dei vari sistemi cartografici definiti da EPSG.

Infine, un grosso ringraziamento a Chiara per averci costretti a rivalutare un post obsoleto.

Questo post nasce a seguito della sollecitazione a descrivere le modalità con cui abbiamo elaborato il modello per l’individuazione della rete strategica in condizioni di esercizio. E’ la naturale continuazione del mio precedente “Definizione di una rete stradale strategica di ambito provinciale” che invito a leggere per maggiore chiarezza, in quanto alcuni passaggi comuni alle due analisi sono stati descritti nel primo post con maggiore dettaglio.

Ricordo comunque, a titolo di completezza, alcuni concetti generali.

Lo scopo dell’analisi è stato quello di definire, all’interno dei 1400 Km della rete viaria della Provincia di Bologna, tre categorie di importanza funzionale indicative della rilevanza strategica di un tronco stradale.

La definizione di una rete strategica è finalizzata a garantire un livello di servizio dell’infrastruttura stradale adeguato alla sua funzione, a programmare e gestire la manutenzione dell’infrastruttura stradale sul territorio provinciale in maniera mirata e a ottimizzare le risorse disponibili per gli interventi definendo priorità e fornendo supporto nella definizione dei piani triennali dei lavori.

L’individuazione della rete strategica viene effettuata tenendo conto di due diversi scenari:

• scenario di servizio: valuta la funzionalità richiesta all’infrastruttura in condizione di normale esercizio;

• scenario di emergenza: valuta la funzionalità richiesta all’infrastruttura nella condizione di emergenza legata ad un evento sismico.

Nel caso dell’analisi in condizioni di esercizio si è tenuto conto dei flussi di traffico e lo studio dei percorsi (routing) ha valutato i percorsi tra centroidi di attrazione e generazione di spostamento secondo la relazione residenti-edificato, residenti-imprese e caselli autostradali-edificato.

L’analisi GIS utilizza:

• una mappa di densità dei residenti ottenuta dal dato geometrico dalle sezioni di censimento ISTAT;
• una mappa di densità delle imprese ottenuta della banca dati della Camera di Commercio georeferenziata;
• una mappa di densità dell’edificato ricavata secondo quanto descritto in questo post.

Queste mappe raster vengono filtrate utilizzando un valore minimo di soglia che permetta di identificare un numero di “isole” ritenuto rappresentativo del contesto provinciale mediante un’analisi qualitativa. Di queste isole vengono poi calcolati i baricentri passando per la trasformazione in poligoni. I baricentri, assieme agli accessi ai caselli autostradali, rappresentano i centroidi dell’analisi dei percorsie sono costituiti da:

• 48 centroidi di aree ad elevata densità residenziale, ottenuti elaborando le sezioni relative all’ultimo censimento della popolazione, che definiremo centroidi residenti
• 61 centroidi di aree densamente edificate, ottenuti elaborando la densità edilizia calcolata dai dati catastali secondo la metodologia proposta da questo post, che definiremo centroidi edificato
• 46 centroidi di aree ad elevata presenza di imprese ottenuti elaborando i dati della Camera di Commercio di Bologna georiferiti, che definiremo centroidi imprese
• 24 accessi ai caselli autostradali

Individuati i centroidi di generazione/attrazione degli spostamenti vengono definite nel modello le regole secondo le quali il software deve calcolare i percorsi di collegamento che sono rappresentati dalla seguente matrice.

 

Per ogni relazione è espresso un parametro di calcolo utilizzato dall’algoritmo di routing del software:

• 1C, 5C numero di connessioni del centroide di generazione degli spostamenti con i più prossimi punti di attrazione degli spostamenti, es. tra centroidi residenti e centroidi edificato e è indicato 5C, cioè il centroide di ogni area ad elevata densità residenziale deve raggiungere il centroide delle cinque aree densamente edificate più prossime.

• TB calcolo del percorso utilizzando il percorso più breve in termini di tempo.

Ad ogni arco stradale è attribuito un peso basato sul numero dei percorsi, tra quelli calcolati, che lo utilizzano, la parte relativa al calcolo dei percorsi a questo punto è conclusa. Si opera l’estrazione del grafo delle strade provinciali dal grafo complessivo.

Oltre ai percorsi, per il calcolo della categoria di importanza funzionale, in condizioni di esercizio, delle strade provinciali, sono utilizzati anche i dati sui flussi di traffico che provengono da Mobiliter, il sistema di consultazione dei flussi online della regione Emilia-Romagna. I dati forniti sono rilevati da circa 40 postazioni, in funzione 24 ore su 24, installate sulle strade provinciali. Questi dati di flusso sono integrati dai dati rilevati in fase di definizione del quadro conoscitivo del Piano della Mobilità Provinciale.

I dati relativi ai flussi di traffico sono stati inseriti come attributi nel grafo provinciale a livello di singolo arco stradale. Sono state individuate tre classi di traffico attraverso un’analisi di significatività statistica (Jenks). La scelta dei valori di soglia, operata secondo questo metodo, consente di determinare classi di aggregazione (classe 1, 2 e 3) con i valori di gruppo più simili e che massimizzano le differenze tra le classi stesse.

Il calcolo dell’indice di importanza funzionale, basato sulle classi di traffico e sul peso determinato dall’analisi dei percorsi, è stato effettuato in maniera diversificata tra le strade di pianura e quelle collinari o montane. Si è operata una distinzione basata sulla definizione geografica di pianura come territorio compreso al di sotto della quota di 200 m s.l.m. Lo scopo di questa differenziazione, che si traduce nella creazione di due sub-grafi, è quello di amplificare l’importanza funzionale delle strade appenniniche, cioè quelle poste a 200 m s.l.m., che presentano in termini di flussi di traffico un’importanza spesso secondaria. Tale scelta si è concretizzata nel calcolo dell’indice di importanza funzionale che segue la logica di seguito descritta.

Una volta calcolato l’indice di importanza funzionale nel contesto di pianura ed in quello appenninico si può riunificare il grafo. L’indice di imporanza funzionale che ogni arco si trova come attributo viene normalizzato a 100 e vengono individuate tre categorie di importanza funzionale mediante l’analisi di significatività statistica di Jenks.

Quello che si ottiene è un grafo che presenta per ogni singola strada provinciale diversi tratti con categoria di importanza funzionale diversa. Con un’analisi qualitativa si operano delle scelte per attribuire le categorie di importanza funzionale in maniera più continua ad interi tratti di strada.

Un’illustrazione interessante può essere quella di un utilizzo “pratico” della rete strategica in condizioni di esercizio quale la valutazione dell’indice di equilibrio nell’attività di pulizia della neve. Si calcola per ogni arco stradale l’indice di servizio, cioè il rapporto tra il numero dei mezzi ed il percorso assegnato (es. 1 mezzo / 15 Km = 0.067). Il valore dell’indice di servizio, attraverso l’analisi di significatività di Jenks, viene classificato in tre classi: massimo (classe 1), medio (classe 2) e minimo (classe 3) servizio. Successivamente per ogni arco si confronta la classe di servizio con la categoria di importanza funzionale in condizioni di esercizio. Gli scenari possibili sono i seguenti.

	Classe servizio 1	Classe servizio 2	Classe servizio 3
Cat. importanza funzionale 1	Indice servizio equilibrato	Indice servizio basso	Indice servizio molto basso
Cat. importanza funzionale 2	Indice servizio alto	Indice servizio equilibrato	Indice servizio basso
Cat. importanza funzionale 3	Indice servizio molto alto	Indice servizio alto	Indice servizio equilibrato

La mappa dell’indice di equilibrio risultante è la seguente.

Spero di essere riuscito nell’intento di esemplificare il flusso di lavoro seguito. Invito chi possa essere interessato all’argomento a contribuire, chiedere informazioni o criticare utilizzando i commenti