Milo's Tec

Il termine GIS è obsoleto?

Lavorai al mio primo Viewer GIS per la Direzione Generale del Territorio di Regione Lombardia nel “lontano” 2003. Mi ricordo che impiegammo molti mesi a realizzare il prodotto perché la nostra idea (oggi assolutamente non applicabile) era provare a replicare le funzionalità di un GIS desktop sul Web. Questo approccio, naturalmente, oltre ad essere alquanto oneroso ha determinato che le applicazioni sviluppate successivamente avessero un target solo di tecnici o esperti della materia trattata.

Queste applicazioni non avevano assolutamente il concetto “dell’around me” ovvero di identificare i servizi che si trovano attorno alla mia posizione. Concetto, naturalmente, molto difficile da applicare in una applicazione WebDesktop ;-), ma assolutamente fondamentale per una applicazione mobile. Insomma i device tipo SmartPhone e Tablet hanno fatto ripensare al concetto di “Applicazioni Geografiche”. Questa trasformazione si vede anche nei profili professionali di chi si occupava di GIS prima e di applicazioni Geografiche oggi. Una quindicina di anni fa il GIS era solo per tecnici come geografi, geologici o ingegneri ambientali che usavano queste applicazioni complicate per fare elaborazioni geografiche anche molto complesse e che restituivano dati che andavano interpretati da esperti della materia, ora invece non vi è più necessità di competenze (o quanto meno in numero molto più limitato) di questo tipo ed è “sufficiente” un buon informatico per realizzare ottime applicazioni geografiche di tipo “Around Me”.

Qualcuno potrebbe obiettare che così facendo ci si indirizza solo verso il mercato consumer, assolutamente no e, come ho già sottolineato in un mio precedente post, va colta l’occasione da parte delle aziende di “cavalcare” l’onda del “mobile”. Quindi con un device di tipo “mobile”  io posso sapere le informazioni di cosa e chi è vicino a me e quindi, se sto lavorando per una società che controlla le tubature delle fognature (se naturalmente esiste il layer geografico) posso, in base alla mia posizione effettuare una analisi di tipo network e identificare, per esempio, la valvola che alimenta il tratto di tubo sotto ai miei piedi e sapere di conseguenza dove intervenire.

Se invece volessimo fare una applicazione consumer potrei chiedere che venissero identificati i miei amici che si trovano ad una certa distanza da me.  Con il mobile tutto è riferito alla nostra posizione.

Quindi la domanda conclusiva potrebbe essere: non usiamo più il termine GIS, ma passiamo ad un termine più nuovo che permetta di identificare i servizi in base alla posizione (Location Based Services Available oppure Location Based Service)? La mia risposta è: Nì! Nel senso che il termine GIS va usato ancora per quelle applicazioni che necessitano di elaborazioni geografiche avanzate, mentre per applicazioni che necessitano di identificare i servizi attorno alla propria posizione usiamo LBS o LBSA oppure definiamo insieme un acronimo e poi in alcuni casi (vedere l’esempio sopra della fognatura) GIS e LBA possono lavorare insieme per aumentare il business ;-).

Mi porto la città in tasca

ArcGIS Explorer è un prodotto di ESRI che non ha certo avuto molto successo a causa sia del confronto (sebbene siano prodotti molto diversi tra loro) con il maggior conosciuto (e molto più usabile) GoogleEarth sia per una serie di bugs che hanno “segnato” ogni versione rilasciata.

La storia di questo prodotto potrebbe avere un futuro roseo, almeno da quanto si legge da questo post di ESRI.
La grossa novità è che con la prossima versione (ArcGIS Explorer 2012) sarà possibile portarsi la propria città in tasca. Cosa significa?
Che in una chiavetta USB avremo la ns città virtuale ed il SW per visualizzarla ed analizzarla.
La città sarà memorizzata in un GeoDatabase ed il SW per la visualizzazione sarà ArcGISExplorer 2012 (in rilascio a fine anno).
La cosa interessante è che l’applicazione funzionerà senza necessità di installare nessun SW (ma su quali Sistemi operativi? Ad oggi non è noto)

Se vi chiedete come mai non vi sia una applicazione 3D Web è che le WebApp (per ragioni di sicurezza) non possono accedere a dati in locale e quindi sarebbe impossibile accedere a Geodatabase locali o Enterprise, o anche usare WorkFlows.

Naturalmente ho parlato di città in tasca, ma i temi su cui questa soluzione potrà essere applicata potranno essere i più diversi e vari: analisi geografiche per la stabilità dei pendii, redazione di percorsi turistici ed escursionistici (il 3D su questi aiuta molto), ma anche individuazione di postazione di atterraggio per gli elicotteri per la protezione civile e poi in base alle ns necessità.

Le applicazioni mobile sono indirizzate solo al mondo consumer oppure possono portare vantaggi anche al business?

Il mercato mobile negli ultimi anni, ma è meglio dire negli ultimi mesi (se non giorni) ha mostrato un dinamismo tale da far diventare i PC degli investimenti a “lungo termine”; basti pensare al continuo rilascio di nuovi device, ai diversi approcci nello sviluppo di applicazioni, ed alla disponibilità di OS in continua evoluzione.
 Il mercato però è ancora orientato principalmente all’utente consumer in quanto le aziende, in alcuni casi, vedono il mercato mobile non ancora sufficientemente maturo. Questa incertezza deve essere superata e le aziende devono capire quali grandi miglioramenti in efficienza e di operatività un device mobile può portare nelle normali attività che si compiono ogni giorno in qualsiasi ambito lavorativo.

Ma guardando dal punto di vista aziendali quali considerazioni andrebbero fatte?

Il Mercato dell’hardware
Come è noto i device di tipo mobile più diffusi sono quelli di Apple con IPhone (37% delle attivazioni da inizio 2012) e IPad2 (con il 17,7% di attivazione da inizio anno), il sistema operativo Android occupa la terza posizione con 26.1 di attivazioni da inizio anno per gli smartphone e 2,7% per i tablet.

Il mercato dal punto di vista utente è suddiviso in questo modo:

-          I prodotti Apple sono la scelta all’interno delle aziende,

-          Android domina nel mercato consumer.

Esiste anche l’OS di Microsoft che nella versione 7 ha fatto dimenticare quell’obsoleto sistema operativo che era Windows Mobile 6.5, ma la vera innovazione avverrà con Windows 8 un Sistema Operativo trasversale: Desktop, Tablet e Mobile, vedremo come risponderà il mercato.

Il Mercato delle Applicazioni
Il mercato delle applicazioni mobile è concentrato sulle piattaforme Android e IOS e, come avete letto nel post precedente, la modalità di realizzazione di una applicazione può essere o tramite lo sviluppo di una app installabile (che sia nativa o ibrida) oppure con una web application. Ma quale deve essere la scelta?
Facciamo un potenziale esempio di uso per capire quale può essere il migliore approccio in base al contesto.

Se dovessimo pensare ai lavori che svolge un veterinario per il controllo dei capi di bestiame delle aziende agricole si capisce che la maggior parte dell’attività è svolta “on site”, ma un device mobile potrebbe aiutare nelle operazioni, per esempio, di controllo? Assolutamente sì! Basti pensare ai:
-Dati relativi all’ubicazione;
-Il tempo;
-Il testo ed immagini di controllo

Sono tutte informazioni che devono essere raccolte e memorizzate ed uno smartphone ha tutti gli strumenti necessari per svolgere questo lavoro: una macchina fotografica, una app mobile progettata per fornire un flusso di lavoro destinato al compito da svolgere ed una archiviazione locale e di rete dei dati.

Quindi ecco la “domandona”: per gli scopi del “ns veterinario” sarebbe necessario sviluppare un’applicazione di tipo WebApp o di tipo App? In questo caso sicuramente un App, ma perché vi chiederete (ve lo chiedete vero? ;-))

Ci sono due ragioni per cui questo è il caso:
In primo luogo, si lavora con immagini e la memorizzazione locale non è possibile attraverso una applicazione basata su browser. Come  per i PC, in gran parte per ragioni di sicurezza, i browser hanno un accesso limitato alle risorse locali.
In secondo luogo, è del tutto possibile che il ns veterinario debba lavorare in zone prive di accesso alla rete “mobile” ed anche wi-fi. Quindi in assenza di rete dati e di wi-fi viene eliminata la possibilità di utilizzare applicazioni web based ed e’ invece necessario sviluppare una App in cui i  i dati operativi richiesti, devono essere memorizzati ed acceduti localmente. Quindi, mappe interattive, mappe di base e strati di “business” (nel nostro caso le aziende agricole interessate al controllo), dovranno essere conservati come informazioni all’interno del device.

Di conseguenza un dispositivo mobile, senza dover essere esperti di tecnologia,  migliorerebbe drasticamente il modo in cui completare le proprie attività quotidiane incrementando l’efficienza e riducendo così i costi.

L’unione di 2 mondi
Il settore della GeoInformatica (se mi permettete il termine) sta progressivamente cambiando. La “nicchia” delle funzionalità di “location”, che fino a qualche anno fa erano ad uso solo per i tecnici GIS, si stanno fondendo con altri servizi anche molto diversi.  Questo cambiamento sta portando che sempre piu’ un maggiore di aziende che si occupano di GIS sta ampliando e modificando il proprio “core business” andando ad investire sulle tecnologie di location.

Questo cambiamento sta determinando anche un forte avvicinamento tra chi si è occupato sempre di GIS e chi invece l’ha considerato solo marginalmente perché più orientato ad altro business.

Così abbiamo che:
- alle presentazioni ESRI si vedono sempre più spesso utenti non-GIS, quindi consumer o tecnici di altri ambiti (Es. sanità, turismo, etc), che sono molto soddisfatti di questo cambiamento di “rotta”.
-  Google si sta muovendo nel campo dei GIS e ha incominciato a fare la sua comparsa in workshop legati al mondo petrolifero e sta chiedendo agli sviluppatori di ArcGIS di guardare anche nella loro direzione (una azienda non GIS che vuole entrare nel mercato GIS);
- I providers di servizi di location di tipo consumer come FourSquare stanno usando la tecnologia di location a scopo di marketing e pubblicitario.
- IPS (Indoor Position System) è un sistema di navigazione che lavora all’interno degli edifici, sebbene sia in fase di sviluppo permetterà di passare dalla “classica” geoinformatica all’aperto alla geoinformatica da interni.

Questi cambiamenti permetteranno a tutto ciò che è “geoinformatica” di passare dalla periferia al centro del palco della tecnologia dell’informazione, vale la pena investirci, no? ;-)

Applicazioni Mobile Ibride

Negli ultimi mesi si sta assistendo alla definizione di un nuovo standard: HTML5.

HTML5 sarà sicuramente (vista la spinta dei maggiori Vendor) il nuovo linguaggio di sviluppo per il Web, sebbene bisogna ancora capire se nel 2014, data in cui è previsto il rilascio definitivo delle specifiche, i PC avranno browser che ne permetteranno la piena compatibilità basti pensare ai milioni di PC che hanno ancora installato Windows Xp.

Se il discorso per il mondo Web Desktop, sebbene ancora non completamente definito, sembra tracciato per il mondo Mobile il discorso è più difficile in quanto l’uso del device da parte dell’utente è molto diverso rispetto a quello di un PC desktop; infatti è molto più comune usare una App piuttosto che scrivere uno scomodissimo URL. E’ vero che molte volte si riesce a bypassare questa “scomodità” usando un QRCode,ma in questo caso l’utente deve avere un software di decodifica e diciamolo pure l’utente stesso deve essere più “sgamato”.

Il vantaggio, naturalmente, nell’uso di sviluppare applicazioni in HTML5 anche per Mobile è che si avrebbe un unico sviluppo che poi funziona (ad oggi almeno per le App mobile Geografiche questa affermazione non è vera) in maniera identica su tutti i browser…il naso mi si sta allungando ;-).

Naturalmente una soluzione completamente all’opposto rispetto allo sviluppo di HTML5 per il mobile è usare codice nativo per creare delle vere e proprie App. Questo approccio ha il grandissimo vantaggio che mette a disposizione tutte le funzionalità del device, ma ha il grosso problema che occorre uno sviluppo specifico per ogni device e quindi costi e tempi molto più elevati-

Quindi esiste una terza soluzione?
Sì ed alcune aziende la stanno percorrendo e sono quelle che si chiamano applicazioni Ibride (Hybrid) in cui il codice viene scritto con un linguaggio comune per tutti i device (es. HTML5, C#, FLEXetc) poi viene convertito in codice nativo in funzione del device di dove essere deployata l’applicazione.

Qual’è il vantaggio per l’utente?
Il vantaggio è che l’applicazione Ibrida è a tutti gli effetti una App Nativa, scaricabile (quindi niente URL da scrivere) e che per l’utente è indistinguibile da una nativa.

Vantaggio per lo sviluppatore?
Il grandissimo vantaggio è che crea applicazioni “native”  scrivendo il codice una sola volta usando HTML5, CSS e Javascript (esistono anche altri framework scritti in C#).

Quindi da quello che si evince HTML5 sarà il linguaggio di programmazione delle prossime applicazioni Mobile e Web, quello che non è ancora certo è la modalità di fruizione delle applicazioni.

Ma come mai alcune aziende non vogliono ancora adottare HTML5 per il Mobile?
Perché non si può accedere a tutte le feature native del device. Il W3C sta lavorando in questo senso, ma ad oggi i mobile browser, per esempio, non permettono accesso alla fotocamera, micofono, ribrica, etc.

Questo limite è però superato nelle applicazioni Ibride, per esempio il Framework Open Source PhoneGap, permette, utilizzando javascript, di interrogare la bussola, acquisire immagini, trovare un contatto e appuntamento e così molte altre funzioni.

Ricordiamo che oltre alla possibilità di accedere alle funzioni del device una dei maggiori pregi è che una App Ibrida è scaricabile ed installabile sul device.

Ma allora le applicazioni ibride sono “l’uovo di Colombo”?
Beh diciamo che sono una bella soluzione, ma qualche limite l’hanno anche loro. Per esempio a differenza delle applicazioni native, le quali fanno uso di API grafiche e servizi di UI forniti dal Sistema Operativo, nelle applicazioni ibride la maggior parte delle pagine sono eseguite dal motore di rendering di un browser. Questo significa che, almeno per quanto riguarda i giochi, solo con applicazioni native si riesce ad avere qualità elevata e performance accettabili. Fortunatamente gli smartphone di fascia alta hanno motori di rendering HTML molto potenti i quali supportano HTML5 e CSS3.

A livello di User Interface i Toolkit Javascript: Sencha Touch, jQuery Mobile e dojox.mobile sono compatibili pienamente con il modello di sviluppo di applicazioni ibride, rendendo il look and feel indistingubile da una App Nativa.

Quali sono le conclusioni?
Da un punto di vista strategico, per le applicazioni che non hanno bisogno di elaborazioni grafiche complesse, le aziende dovrebbero adottare HTML5 per lo sviluppo di applicazioni Mobile e ciò deve avvenire al più presto possibile.

Il modello di applicazione ibrida, anche se non adatto per le esigenze di sviluppo tutte le app, fornisce una soluzione conveniente per una vasta gamma di tipi di app scaricabili e consente l’inserimento graduale nel nuovo mondo dell’ HTML5.

Ci vuole Classe

Usando le classi Layer dalle API per Javascript è possibile riferirsi ai servizi di mappa erogati da ArcGISServer e da altri MapServers.
Se analizzassimo l’Object Model si vedrebbe che tutte le classi layer ereditano dalla classe “core” Layer. La classe Layer non  ha costruttori così non può essere creato un oggetto direttamente da questa classe. La classe layer definisce giusto i metodi, le proprietà e gli eventi poi ereditati dalle sotto-classi di layer.

Le sotto-classi di Layer sono:
- DynamicMapServiceLayer;
- TiledMapServiceLayer;
- GraphicLayer

DynamicMapServiceLayer e TiledMapServiceLayer agiscono anche come classi core rispettivamente per i servizi di mappa dinamici e per i servizi tiled. Come per Layer non è possibile creare oggetti da queste classi, ma bisogna usare le sue sottoclassi.
Per i TiledMapServiceLayer le sotto classi sono:
— ArcGISTiledMapServiceLayer;
— VETiledLayer;
— OpenStreetMapLayer
Per i DynamicMapServiceLayer le sotto classi sono:
— WMSLayer;
— ArcGISDynamicMapSericeLayer;
— ArcGISImageServiceLayer

Incominciamo ad analizzare le sottoclassi dei TiledMapServiceLayer
ArcGISTiledMapServiceLayer
I servizi di mappa tiled referenziano immagini cached pre-elaborate e salvate sul fileSystem del Server. Spesso i servizi Tiled sono usati come Sfondi delle Mappe.

La classe ArcGISTiledMapServiceLayer è usata quando si vuole riferirsi ad un servizio di mappa tiled esposto da ArcGISServer.
// creare il layer di tipo tiled
var tiled = new esri.layers.ArcGISTiledMapServiceLayer (“http://server.arcgisonline.com/ArcGIS/rest/services/World_Imagery/MapServer”);
Map.addLayer(tiled);

Il costruttore ArcGISTiledMapServiceLayer  accetta un URL ad un servizio di mappa
con le opzioni che consentono di assegnare un ID al servizio di mappa, e controllare
la trasparenza e la visibilità.
Dopo che una istanza della classe ArcGISTiledMapServiceLayer è stato creata viene poi aggiunta alla mappa usando il metodo Map.addLayer() che accetta una variabile che contiene un riferimento al mapServiceLayer Tiled.
Apri Mappa ArcGISTiledMapServiceLayer

VeTiledLayer e OpenStreetMapLayer sono le classi usate per caricare le mappe di Bing o OpenStreetMap. Questi set di tiles non sono forniti da ArcGIS, ma da Microsoft e dal progetto OpenSource OpenStreetMap.
Esempio per usare le mappe OpensOurce OpenStreetMap:
osmLayer = new esri.layers.OpenStreetMapLayer();
map.addLayer (osmLayer);
Apri Mappa OpenStreetMapLayer

Per la classe DynamicMapServiceLayer si analizzerà in primis la sotto-classe ArcGISDynamicMapServiceLayer.
Come per i TiledMapServiceLayer il costruttore dell’ArcGISDynamicMapServiceLayer
accetta un URL che punta al servizio di mappa con una serie di opzioni:
- ID;
- Trasparenza;
- livello di visibilità settato a true o false.
Rispetto al TiledService i singoli Layers all’interno del map service può essere acceso o spento attraverso il metodo setVisibleLayers();
Esempio per un ArcGISDynamicMapServiceLayer:
opLayer = new esri.layers.ArcGISDynamicMapServiceLayer (“http://www.studioat.eu/ArcGIS/rest/services/Demo/GeneraleRF/MapServer”);
Una volta creata l’istanza di un Layer ArcGISDynamicMapServiceLayer
map.addLayer (opLayer);
Apri Mappa DynamicMapServiceLayer

Con una istanza di ArcGISDynamicMapServiceLayer è possibile eseguire diverse operazioni.
Naturalmente è possibile creare mappe che mostrano i dati del servizio, ma anche eseguire query sui layers dei servizio, controllare le feature attraverso layer definitions, controllare la visibilità dei singoli Layer, settare l’informazione temporale, esportare  la mappa come immagine controllare la trasparenza dello sfono ed altro.

Nel link seguente vedete come è stata settata la visibilità solo ai Layer “Camerette” e “Condotti” del servizio Dynamic usato in precedenza andando a settare nel metodo setVisibleLayers gli ID 0 e 1 corrispondenti ai suddetti Layer.
Apri Mappa con 2 layer visibili

Nel prossimo post vedremo nel dettaglio i metodi e proprietà dei Servizi ArcGISDynamicMapServiceLayer.

Sei dinamico o sei una piastrella?

Prima di addentrarci nelle classi Layer occorre spiegare alcuni concetti.

Come è naturale in una applicazione GIS una mappa senza layer è come un pittore con la tela bianca. I layer che vengono aggiunti alla mappa servono a definire il significato della stessa e definiscono quale sarà l’oggetto dell’analisi. Per esempio per effettuare uno studio sul progressivo del consumo di territorio avremo bisogno dei layer delle aree urbanizzate e del suolo agricolo in diversi range temporali per capire l’evoluzione del fenomeno.

Vi sono 2 tipi principali di servizi di mappa che forniscono layers che possono essere aggiunti alla mappa: i Layer dei servizi di mappa dinamici ed i layers dei servizi di mappa tiled (a piastrella).

I servizi di mappa dinamici
I layers dei servizi di mappa dinamici referenziano servizi di mappa che creano
una mappa “al volo” che viene restituita come immagine. Questo tipo
di servizio di mappa può essere composto da una o più layers. Nell’esempio
che segue il servizio di mappa (AreeProtette) è costituito da 7 layers differenti
che rappresentano informazioni di tipo naturalistico a diversi livelli: Parchi regionali,
naturali, monumenti naturali, etc.


I Servizi di mappa dinamici sono molto flessibili poichè è possibile controllare
le features mostrate attraverso la layer definitions, settare la visibilità di vari
layer all’interno del servizio. Per esempio nell’esempio delle Aree protette si
potrebe decidere di rendere visibile per una nostra applicazione solo i Parchi Regionali.
Questa è la versatilità dei servizi dinamici che non è possibile con i servizi di tipo
tiled.

I servizi di mappa tiled
Il modo più semplice per capire il concetto di servizio di mappa è quello di
pensare ad una griglia che è stata posata sulla superficie di una mappa.
Ogni cella all’interno la griglia ha la stessa dimensione e sarà usata per tagliare
la mappa in singoli file immagini chiamati tiles. I singoli tiles sono memorizzati
come un file immagine sul Server e “restituitio” quando è necessario in funzione
della scala e del Map Extent.

Questo processo è ripetuto a diversi livelli di scala. Il risultato finale è una cache
costituita da migliaia di tile (il numero è in funzione dell’extent di cui si vuole generare la cache e dal numero di livelli di scala) generati per rappresentare la mappa scelta nei livelli di scala definiti.
Quando la mappa è mostrata nell’applicazione i tile vengono assemblati per formare una singola immagine.
Questi layers di mappa cached vengono, di solito, usati come sfondi ed includono:
foto aeree, Mappe stradali, mappe topografiche, etc.
Una delle peculiarità delle mappe cached è la loro velocità nel creare la mappa
ogni volta che vi è una richiesta. Questa velocità è da imputare al fatto che il MapServer non deve processare la richiesta per generare la mappa, ma semplicemente andare a recuperare nel fileSystem le immagini che devono essere presenti a quella scala ed a quell’extent.

I layer di business sono poi “spalmati” sopra ai servizi di base tiled. I layer
di business, di solito, derivano da servizi di mappa dinamici, i quali “non essendo pre-elaborati” risultano più lenti nella restituzione in mappa, ma su questi è possibile effettuare elaborazioni che con i dati Tiled non sarebbero possibili.

Mappa in 5 passi

Piccolo esempio di codice HTML che utilizza le API Javascript di ESRI
Ricordiamo in sintesi gli step che devono sempre essere presenti per una WebGIS Application con le API ESRI per Javascript:
1. Referenziare le API Javascript di ESRI ed i file css.
2. Nel tag body Aggiungere un riferimento al foglio di stile;
3. Creare un Container per la mappa;
4. Usare dojo.require per importare le risorse
5. Creare uno script di inizializzazione per i parametri di setup e quindi chiamare la funzione dojo.addOnLoad().

I 5 step sono sintetizzate nelle seguenti righe di codice:
———————————————————————————————————————————————

<html>
<head>
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8”>
<meta http-equiv=”X-UA-Compatible” content=”IE=7,IE=9” />
<title>Mappa Topografica</title>
<!— Reference ai Style Sheet —>
<link rel=”stylesheet” type=”text/css” href=”http://serverapi.arcgisonline.com/jsapi/arcgis/2.6/js/dojo/dijit/themes/claro/claro.css“>
<!— Reference alle API Javascript —>
<script type=”text/javascript” src=”http://serverapi.arcgisonline.com/jsapi/arcgis/?v=2.6“></script>
<script type=”text/javascript”>
dojo.require(“esri.map”); /*riga per importare le risorse per l’applicazione*/

function init(){
/* funzione di inizializzazione eseguita dopo che tutti gli elementi della pagina sono stati caricati
Si usa l’ID che è stato assegnato al tag <div>per piazzare la mappa nel container <div>, naturalmente
dopo aver creato la mappa con la linea map = new esri.Map (“map”) */
map = new esri.Map (“map”);

var imageParameters = new esri.layers.ImageParameters();
imageParameters.format = “jpeg”;
var dynamicMapServiceLayer = new esri.layers.ArcGISDynamicMapServiceLayer(“http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Demographics/ESRI_Population_World/MapServer”, {“opacity”:0.5, “imageParameters”:imageParameters});
map.addLayer(dynamicMapServiceLayer);

}

dojo.addOnLoad (init);
</script>
</head>
<body class=”claro”> <!— riferimento al tema css di Dojo —>
<!— div è il contenitore della mappa e deve avere un proprio ID per essere richiamabile da funzioni javascript —>
<div id=”map” style=”width:1024px; height:512px; border:1px solid #000;”></div>
</body>

</html>

———————————————————————————————————————————————

Visualizza la mappa

Per sapere come ogni tema modifica l’aspetto è disponibile un theme tester messo a
disposizione da Dojo.org:http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/themes/themeTester.html

Ma quali sono le risorse usate normalmente:
esri.map Mappa, geometria, graphics, e symboli
esri.layers.agsdynamic ArcGISDynamicMapServiceLayer
esri.layers.agstiled ArcGISTiledMapServiceLayer
esri.tasks.find Task di ricerca
esri.tasks.geometry Task per la geometria
esri.tasks.gp Task per il Geoprocessing
esri.tasks.identify Task per l’Identify
esri.tasks.locator Task per il localizzaotore
esri.tasks.query Task per le Query
esri.toolbars.draw Disegnare
esri.toolbars.navigation Navigazione

Prima di finire una nota sul Costruttore per la classe Mappa è:
esri.Map(divID,option?)
dove divID è una referenziazione al container per la mappa (di solito <div>) e options
specifica uno o + parametri opzionali come l’extent iniziale.
Esempio:
var map = new esri.Map (“map”, (extent : new esri.geometry.Extent (8,44,9.46));

Attività fisica per il 2012? Dojo!

Come è noto, a chi segue i prodotti Server di ESRI, dalla versione 9.31 sono
state introdotte delle API per la costruzione veloce e facile di Web GIS Application.
Le tecnologie includono Javascript, Flex e Silverlight oltre alle più classiche
ADF per Java e .Net.
Flex e SilverLight permettono di avere una UserExperience a livello di applicazione
desktop, ma alcune volte, per politiche aziendali, non è possibile installare plugin
e quindi si rende necessario l’uso di Javascript. Javascript è un linguaggio
estremamente potente e semplice da usare e su cui sono stati costruiti diversi
framework. In questo articolo faremo uso del framework Dojo. Come si vedrà le API
ESRI per Javascript e il Framework Dojo sono fortemente integrate.

I componenti Dojo
E’ possibile identificare 4 progetti principali Dojo
- Dojo Base and core;
- Dijit;
- Dojox;
- Util;

Dojo Base, che è la base di tutto, fornisce il linguaggio e le utilities Ajax per aggiungere risorse Dojo “al volo” ed altre funzionalità di basso livello.

Dojo core: si occupa di gestire funzioni come permettere le interrogazioni DOM, remote scripting, drag and drop
localizzazione ed internazionalizzazione, integrazione con Firebug, e nota
più importante gestire le differenze tra i browser, nota molto dolente nello sviluppo
con javascript ed HTML.

DJit include 40 HTML user Interface Widgets, includendo: bottoni, text box, color picker, slider, etc… Con un CSS di default di nome Tundra, che naturalmente può essere riscritto.

Dojox sono estensioni di Dojo e includono progetti come il grid Widget, grafici,
gestione immagini ed oltre.

Util è una collezione di utilities Dojo che includono un FrameWork di unit-test e permette di sviluppare tools per creare versioni custom di Dojo per i settaggi di produzione.

Integrazione di ArcGIS Server con Dojo
Come detto in precedenza le API ESRI per ArcGISServer sono state sviluppate su Dojo quindi vi è una integrazione molto forte tra i 2.
Questa integrazione significa che per usare le API ESRI occorre:
1. Includere le reference alle API e StyleSheet
2. Referenziare nel tag <body> una reference allo Style Sheet.
3. Creare un contenitore per la mappa
4. Usare lo statement “dojo.require” per importare le risorse che sarà necessario usare nell’applicazione.
Invece di caricare tutte le risorse in una volta, che causerebbe gravi problemi di performance all’applicazione, si includeranno solo quelle strettamente necessarie. Quali risorse includere? Beh almento “esri.map” altrimenti no mappa ;-)
5. Aggiungere una funzione JavaScript di inizializzazione che esegue diverse funzioni di configurazione per l’applicazione
in fase di startup. Per convenzione questa funzione di inizializzazione prende il nome di “init” o “initialize”. Poi alla funzione dojo.addOnLoad è passato il nome della funzione di inizializzazione e si occupa di gestire le chiamate a questa funzione solo dopo che tutti i componenti della pagina sono stati caricati. Attendere il caricamento di tutta la pagina è talvolte necessario quando ci si riferisce ad alcuni componenti nella pagina ed occorre essere sicuri che siano stati caricati, altrimenti si generano errori nell’applicazione.

Con questo POST abbiamo introdotto Dojo e la sua integrazione con le API javascript di ESRI, la prossima volta vedremo una sua applicazione.

WEBGISMOBILE 2

Quali sono le applicazioni MobileGIS gratuite disponibili
Se la ns attività lavorativa si svloge prevalentemente fuori ufficio, perchè
esempio siamo un agente della polizia locale, oppure ci occupiamo di pozzi, tubature,
rilievi geologici.
Avere la possibilità di accedere ad informazioni GIS da un device mobile ci è
molto utile, ma non solo per la consultazione di informazioni, ma anche per effettuare
editing.
ESRI ha realizzato una applicazione mobile per i principali OS mobile:
IOS, Android e Windows Phone. Questa applicazione permette di acceder ai dati
pubblicati in ArcGISOnline.
E’ anche da segnalare l’applicazione GeoMobile della WebMapSolutions(URL) un
Viewer Gis “customizzabile”. L’app permette all’utente di caricare i propri layer
ed inoltre include diversi tools: misura, OverView, geo-coder, cerca, routing.

Offline Mobile GIS
Come è ben noto non sempre la zona in cui ci si trova è coperta da un segnale dati
sufficiente o anche è possibile che sia totalmente assente, lo sanno bene i geologici
che fanno rilevamenti in zone impervie, ma anche chi deve fare dei rilievi in zone di
campagna.
La soluzione in questo caso è che l’applicazione abbia caricato sul device gran parte
dei dati geografici di sfondo (come per esempio le BaseMap), ma anche di business.
Ciò è possibile perchè i moderni device hanno capacità di storage notevole e permette
la memorizzazione di grandi mole di dati.
Di conseguenza sul ns device possiamo visualizzare il dato, ma anche modificarlo e registrarlo
usando, di solito, un databae locale che funziona sul device.
Una volta che vi è una connessione dati suffciente il dato geografico aggiunto/modificato
o cancellato verrà sincronizzato con la Banca Dati principali.
Un approccio simile a quello descritto si ha da ESRI sviluppando delle applicazioni
ad hoc usando le SDK disponibili per i diversi ambienti.

La rivoluzione in atto
Come è noto le applicazioni Mobile stanno sostituendo la modalità classica di raccolta dati. Vediamo infatti sempre più persone (studenti, Manager, insegnanti) che hanno sostituito la più tradizionale penna e carta con Tablet. Ora è possibile raccogliere i dati “sul campo” e fare l’upload su Server con un DB alfanumerico o DB geografico, tutte queste operazioni avvengono facilmente usando semplicemente un device di tipo “mobile”. Il mercato del GIS mobile è ancora in fase di startup, ma usando i moderni device avere funzioni quali la posizione e l’uso delle mappe tematiche permette di aprire nuovi orizzonti sulle AppMobile GIS.

WebGISMobile

Il Mobile è la nuova sfida ed è in continua evoluzione. E’ possibile che tra breve
ci chiederemo come abbiamo vissuto senza un GIS su device mobile. Il Mobile GIS è
una esperienza in trasformazione. Lo scopo di una applicazione Mobile GIS non
è solo quello di mostrare il “contesto”, ma riuscire a fare analisi sulla posizione corrente.

Breve storia del GIS
Come è noto negli anni 90 il GIS era una application desktop. Poi il GIS è passato
sul Web verso i primi anni 2000. ESRI realizzo ArcIMS per soddisfare queste richieste,
ma l’evoluzione per l’utente “consumer” fu l’arrivo di Google con mappe veloci,
facili da usare e con molti servizi associati.
Contemporaneamente nascevano nuove tecnologie Web: Flex, Silverlight e AJAX che
andavano a costituire le RIA (rich Internet applications) ovvero applicazioni Web
con una user experience tipo applicazione desktop.
ESRI metteva a disposizione delle API in tecnologia Flex, JS e Dilverlight per
costruire le proprie applicazioni, ed il mondo OpenSource rispondeva con
Open Layers e OpenScale.
Anche gli spatial Server si sono evoluti con l’arrivo di AGServer e GeoServer. Con
l’avvento del mobile, l’industria del GIS è pronta ad una nuova rivoluzione.

The Mobile Market 2011
Il Mercato del mobile è un continuo cambiamento con continue uscite di nuovi device “smartphone” e Tablet che variano di dimensioni e specifiche, ma attualmente sono 4 le piattaforme che si dividono il mercato: Android ed Apple nelle prime posizioni e poi BlackBerry e Windows.
Ora è chiaro che è necessario costruire un codice che vada bene su tutte le piattaforme mobile (usare lo stesso codice per Mobile e desktop, sebbene possibile, lo sconsiglio perchè la User Experience è completamente diversa).
Il raggiungimento di questo scopo è possibile con HTML5 e Adobe AIR (Applicazioni Ibride).

Credo che vi siano due modi per accedre alle applicazioni su device mobili.
La prima è di usare il Web Browser del device e caricare al suo interno l’applicazione, occorre ricordare che i siti Web attuali sono pensati per una interazione con il mouse.
L’interazione con i device mobili è con il dito ciò significa che i siti devono essere ottimizzati per il Mobile Web.
Questo significa un rifacimento delle funzionalità e del design.

La seconda soluzione consiste nell’installazione di applicazioni.Queste possono essere scaricate dai diversi AppStore. Molti sono scritti in linguaggio nativo, Object C, Java etc…
I linguaggi nativi sono specifici di una piattaforma, il che significa molteplici
versioni della stessa app. AIR di Adobe sta creando una soluzione trasversale per costruire applicazioni ibride.