Ultimamente mi è stato richiesto un applicativo di webmapping che mettesse chiunque (o quasi…) in condizione di gestire agevolmente un geodatabase, aggiornando nel tempo le informazioni contenute, comprese le feature geografiche. In due parole: un gestionale web, ma con delle funzionalità proprie dei GIS desktop.
Il committente ha richiesto una soluzione open source ed io sono stato ben contento di proporre il rodato quartetto composto da UMN-Mapserver, PostGIS, PHP e MapFish.
In passato avevo già realizzato qualcosa di simile, ma si trattava di inserire dei punti a partire da una coppia di coordinate, operazione semplicissima grazie a PostGIS. Questa volta era necessario che l’utente disegnasse le geometrie online, direttamente nella finestra del browser, ed ho colto l’occasione per dare finalmente un’occhiata alle funzioni di editing vettoriale di OpenLayers 2.8. Ne sono rimasto estremamente soddisfatto, come sempre avviene quando si tratta di OpenLayers.
Scorrendo la pagina degli esempi ed inserendo il filtro “vector”, ci si rende subito conto della potenza dei controlli dedicati all’editing.
Grazie agli esempi, che coprono quasi tutto lo spettro delle possibilità, è stato facile produrre la parte client del mio lavoro.
L’editor ottenuto è adattabile a qualsiasi back-end “spatial enabled”, è indipendente dal mapserver scelto per pubblicare i dataset online, dal geodbms usato per contenerli e dal linguaggio di programmazione lato server.
Il cuore del client è costituito dalle funzioni presentate in questo esempio, che consentono di disegnare una feature da serializzare sotto forma di stringa in ben 6 formati standard differenti. Ottenuta la stringa, il gioco è fatto: uno script lato server si occupa di recuperarla e lanciare una query di inserimento nel geodabase (ci sono, come sempre, anche altre soluzioni).
L’operazione inversa, vale a dire deserializzare una stringa ed ottenere una feature, è ugualmente possibile e può essere molto utile.
Per esempio, volendo rifinire degli shapefile su una base Google Maps o Openstreetmap, basta trasformarli KML (o in uno degli altri 5 formati supportati), aprire il file con un editor di testo e, infine, copiare ed incollare il contenuto dentro la textarea del nostro editor. A questo punto si è liberi di modificare a piacimento le feature importate.
Questo è solo un esempio grezzo di import, dispobile “out of the box”, ma una volta collegato l’editor ad un back-end spaziale si può dare sfogo alla fantasia e creare delle funzioni di importazione più raffinate.
Cliccando qui potete vedere una versione super-generica del client di editing da me realizzato. Ho usato MapFish 1.1[1] per dare un aspetto un po’ più carino[2] al tutto ed ho modificato il codice degli esempi affinché le diverse funzioni di editing potessero essere attivate da una toolbar invece che da una serie di checkbox e radiobutton. I commenti nel codice dovrebbero essere abbastanza esplicativi.
[1] Si tratta di una versione leggermente modificata in cui ho sostituito OpenLayers 2.7 con OpenLayers 2.8
[2] Qualcuno potrebbe cimentarsi con Dojo o jQuery… sono sicuro che non verrebbe affatto male 
Nota
Devo scusarmi con i lettori di TANTO iscritti al feed RSS.
Stamattina ho accidentalmente cliccato sul bottone “Pubblica” mentre scrivevo la bozza e nonostante mi sia precipitato a recuperare, non sono riuscito ad evitare che l’articolo incompleto finisse nel feed. Per farmi perdonare mi sono incollato al computer ed ho fatto il possibile per finire l’articolo e la demo alla svelta! In futuro starò più attento a dove clicco e soprattutto non inizierò a scrivere bozze di domenica mattina prima di colazione! 
Sono un biologo marino specializzato in geomatica con master in Sistemi Informativi Territoriali e Telerilevamento presso il Centro di Geotecnologie dell'Università di Siena.
Lavoro con queste tecnologie dal 2006 ed il mio principale campo d'azione è la progettazione e sviluppo di applicazioni di webmapping (WebGIS).
Nutro particolare interesse nei confronti del software libero (geografico e non) e dei suoi impieghi nel monitoraggio biologico ed ambientale.
Sono stato consulente di diverse aziende, dell'Università Politecnica delle Marche e del Parco Nazionale della Majella; attualmente lavoro nel reparto Statistica e GIS dell'IZSA&M. Mi sono unito con grande piacere alla redazione di TANTO nell'Aprile del 2009 :)
I contenuti potrebbero non essere più adeguati ai tempi!
By Pietro Blu Giandonato on set 21, 2009
Molti complimenti Alessio, un gran bel lavoro.
La cosa che mi piace sottolineare è come ormai i “webgis” (brutto termine, ma comprensibile) abbiano raggiunto una certa maturità e affidabilità dal punto di vista anche dell’editing online.
La soluzione da te proposta con OpenLayers è anche molto potente dal punto di visìta dell’interoperabilità, poichè mette a disposizione strumenti di importazione e di esportazione dei dati nei principali formati geografici aperti.
Interoperabilità, condivisione e affidabilità: il futuro delle applicazioni di webmapping e mapsharing…
By Alessio on set 21, 2009
Grazie Pietro.
Sul discorso interoperabilità sono completamente d’accordo. OpenLayers è una delle librerie più complete e la sua totale indipendenza dalla piattaforma la rende ideale per lavorare con qualsiasi back-end che supporti gli standard del settore. Per esempio, rispetto alle promettenti API Javascript di ArcGIS, OpenLayers è molto più matura e quando posso scegliere la preferisco anche per lavorare sui servizi generati dal “mapserver” di ESRI.
By Giovanni on set 22, 2009
Bella presentazione Alessio. Sono perfettamente d’accordo che OpenLayers ormai si è imposto per tutte le sue qualità, e anche l’abbinata con ExtJS (Mapfish/GeoExt) è ottima se la questione della licenza non è vincolante (GPL, quindi nessuna distribuzione di/con software proprietario).
Per quanto riguarda l’editing online bhè, certo non sostituisce un desktop gis, ma se verranno aggiunte funzionalità per la validazione delle geometrie (isSimple, isValid secono la specifica Simple Features di OGC) ed eventualmente per l’applicazione delle più semplici regole topologiche (evitare overlapping, ecc.), può diventare uno strumento utile in certi ambiti (es. field mapping). Senza questi controlli il rischio è di ritrovarsi DB di dati inconsistenti (esperienza personale!).
Siamo d’accordo, questo è un discorso che va oltre le finalità dell’esempio, ma visto che siamo in argomento…
Di nuovo complimenti Alessio.
By Alessio on set 22, 2009
Grazie del commento Giova
ti rispondo (amaramente ed anche io per esperienza personale) sul discorso del rischio di creare dati inconsistenti:
in molte realtà purtroppo siamo lontani anche solo dal capire l’importanza di creare dataset validi dal punto di vista topologico. Spesso chi si occupa di sistemi informativi *geografici* si trova a lavorare a stretto contatto con chi si occupa di sistemi informativi *e basta*. E’ già dura far comprendere che non si tratta di “mappette in flash” (flash??? flash!!!!… scusate il termine), quando poi nomini la topologia il rischio è quello di provocare lo svenimento dell’interlocutore o (alla meglio) passare per uno che si vuole riempire la bocca di tecnicismi fini a se stessi per farsi il figo (o come si dice dalle mie parti “il fregno”).
Questo per dire che, anche con i controlli per la validazione topologica, secondo me l’utente finale (spesso un non tecnico) riempirebbe lo stesso il db di schifezze.
Ciò non toglie che avere un editor online che se la batta con i gis desktop da questo punto di vista sarebbe una gran cosa!
By Giovanni on set 22, 2009
Ahimé, Ale, la tua esperienza ricorre spesso! Per molti tecnici (ingegneri, informatici) di sistemi informativi l’aspetto spaziale è solo un noioso attributo di cui, se potessero, farebbero volentieri a meno!
Ma a noi sta dargli il giusto valore, e la sfida è farlo nella maniera più trasparente possibile all’utente medio. Quando, in un form, inserisco una stringa al posto di un numerico è naturale che venga rigettato. Perché non dobbiamo richiedere lo stesso per una geometria?! Non chiedo all’utente di controllare le regole, ma basta dirgli: guarda, “questo poligono si interseca su se stesso, e quindi non può essere salvato”… ok, è già una frase troppo complicata (mi sa) ma ci siamo capiti: dare ad una geomatria almeno la stessa dignità di una stringa o di un numero!
By Italo Mairo on set 22, 2009
Articolo davvero interessante …
La frontiera dell’editing poligonale con questi strumenti si sta ormai rendendo sempre più fattibile …
Sto facendo indigestione di Google Maps api anche in questo senso, ma mi convinco sempre più che dovrò quanto prima esplorare il mondo ancora più opensource di Openlayers.
Grazie mille a tutti di TANTO. Siete bravissimi …
Italo
By Pietro Blu Giandonato on set 22, 2009
Certamente un applicativo web cartografico non potrà in nessun caso sostituire una soluzione desktop, non solo per le -attuali- ridotte potenzialità del primo rispetto al secondo, ma anche ad esempio per gli errori insiti nella digitalizzazione a schermo effettuata su imagery fornita da terzi (Google, Bing, Yahoo!, avete mai notato come il grafo stradale sia spesso sfasato rispetto al dato satellitare?).
Se poi parliamo di topologia… il problema sta proprio nella consapevolezza degli utenti! Eppure un ingegnere, un architetto o un geometra dovrebbe pensare topologicamente di suo.
Io ritengo (esperienza personale anche qui) che l’editing basato su web mapping sia formidabile essenzialmente nelle applicazioni di emergenza, di protezione civile, di localizzazione generica, laddove le esigenze di topologia e di precisione spaziale possano essere ragionevolmente sacrificate alla rapidità di accesso degli strumenti in qualunque condizione e alla collaboratività.
By Giovanni on set 22, 2009
D’accordissimo Pietro. Infatti mi riferivo a quei casi di utilizzo, non alla digitalizzazione catastale o al controllo di qualità di una carta CARG
ma anche nei contesti che citi mi aspetto che un minimo di correttezza sia da considerare, altrimenti il caos regna.
By Andrea Borruso on set 22, 2009
Quanta bella gente!!
Le features della demo messa su da Alessio sono un bel vedere; anche per chi non è web-addicted (come me).
Avete quasi detto tutto voi. Aggiungo un contesto di utilizzo, in cui ho spesso usato applicazioni di web-mapping con possibilità di creazione e modifica di oggetti vettoriali: la didattica a scuola.
Ho trovato molto comodo, con studenti delle scuole medie, potere creare rapidamente delle piccole banche dati “spaziali”. Si scavalcano subito due problemi: l’installazione del software (scoglio insormontabile nelle amministrazioni pubbliche), ed il prendere “confidenza” con interfacce nuove (gli studenti hanno facilità di approccio con le interfacce web). Ci sono anche tanti svantaggi, ma il web-mapping è uno strumento che dovrebbe entrare definitivamente nella didattica.
A proposito di piccole magie da fare dentro una pagina web, vi segnalo queste chicche che ho trovato dentro un cinguettio di Diego Guidi.
Che piacere questo movimento; grazie a tutti.
By Italo Mairo on set 22, 2009
Mah!? … scusate se da ultimo arrivato mi permetto … ma per quello che vedo in giro, per quanto vedo si muove velocemente, sono pronto a scommettere che da qui a breve si riuscirà davvero a fare definitivamente a meno di applicazione desktop, soprattutto proprietarie e basate su formati proprietari.
E personalmente non mi sento così terrorizzato di fronte a quest’idea …
Pensandoci è già un bel pò di tempo sempre meno Arcgis ecc., ecc. … e mi godo una ormai perdurante e compiaciuta dieta ed astinenza da shapefile. Kml, Georss, Json … ah!, che bontà a confronto, molto più sani e digeribili. Come potersi cibare di prodotti in cui si possono assolutamente gestire gli ingredienti, sapendo esattamente quali sono (o quasi).
La precisione di digitalizzazione e le proprietà topologiche si ottengono con gli strumenti adeguati in grado di farlo. Cartografie di supporto sufficientemente estese e dettagliate (e condivise!) e opportuni strumenti di digitalizzazione, dotati di adeguate funzioni di snap, ecc., ecc. …
Non mi pare che i linguaggi di programmazione sul web, per come si stanno evolvendo, avranno difficoltà a stare dietro a queste esigenze.
Pensate alle applicazioni mobile o gps. Chi ormai non si rivolgerebbe ad applicazioni di web mapping per acquisire i dati remoti, magari in tempo reale, con la stessa identica precisione di una applicazione desktop, che necessariamente porrebbe molti più ostacoli (fisici) al trasferimento ed all’acquisizione dei dati al suo interno.
Non so. Ammetto di non essere un cartografo puro (anche se con i GIS ci lavoro da circa 10 anni …), e forse sto solo farneticando …
Ma mi pare che ormai un pò tutti nel settore GIS si stanno buttando sullo sviluppo web 2.0, ed anche i più blasonati desktop producer cercano di starci dietro (vedi ARCGIS Javascript api).
Inoltre questo scenario mi sembra tremendamente più bello e creativo di quello precedente, pre rivoluzione Google Maps / Google Earth … per intenderci. Quindi cin cin, un brindisi !
Piuttosto per ora i veri limiti mi pare siano dovuti alle capacità di calcolo dei browser e di carico tra client e server. Ma anche in questo senso ormai la strada mi sembra segnata: le cose miglioreranno sempre più (come già succede), e chissà, magari verrano fuori dei browser più specializzati. Ma penso (e confido) che sempre di web mapping si tratterà …
By Giovanni on set 22, 2009
Mi permetto anch’io. Le analisi “globali” di questo tipo sono sempre rischiose. Non dubito sull’evoluzione dei sistemi web 2.0, where 2.0 e dintorni, e neanche che i motori dei browser beneficeranno sempre di più della potenza di calcolo della macchina (vedi gli sforzi per permettere a Webkit di usare direttamente le librerie grafiche OpenGL e le risorse delle schede grafiche) percui magari si riusciranno a gestire vettoriali di dimensioni verosimili (non la dozzina di punti dei vari esempi) e anche a gestire oggetti 3D nativamente.
Stiamo comunque parlando di un certo tipo di impieghi che è, e resterà, complementare a tutto il resto del mondo del GIS (produzione cartografica, analisi dati, modellistica, ecc.). Questo per dire, Italo, viva l’entusiasmo ma evitiamo di dire che ArcGIS o l’impiego di formati binari efficienti (non mi riferisco agli shp!) non servono più
Aggiungo: il webgis è comunemente inteso come impiego dei browser per funzionalità GIS, ma questo è solo un aspetto del futuro che avanza: il computing distribuito (Amazon C2, Google App, ecc.) che chiama in causa soprattutto RIA, desktop thick-client, ecc.
By Pietro Blu Giandonato on set 22, 2009
Permettendoci permettendoci
… come sempre la virtù sta nel mezzo.
Soluzioni web e desktop hanno i loro pro e contro, e sappiamo che non c’è bisogno di detrattori o di entusiasti a senso unico.
Sono convinto che come professionisti del settore, il vero valore aggiunto possiamo portarlo soprattutto nello scegliere/suggerire la soluzione che viene meglio fuori da un’analisi costi/benefici, in funzione delle esigenze del committente. A volte è sufficiente usare una cosa tipo MapSpread, ben ingegnerizzata, altre volte magari ERDAS Apollo. In mezzo ci sta sicuramente benissimo OpenLayers+MapFish.
L’importante a mio avviso, è evitare di adottare una logica da “dealer” di specifici software o prodotti, che siano commerciali o aperti, e agire con basi analitiche solide, per arrivare a suggerire soluzioni robuste e affidabili, tecnologicamente ed economicamente adeguate a chi chiede la nostra consulenza.
Una cosa è certa: il futuro avanza, è vero, e le soluzioni tecnologiche che stanno venendo man mano fuori sono semplicemente entusiasmanti, proprio come il cloud computing.
By Vigj on set 29, 2009
ho notato ( e credo sia un problema di di openlayers) che il layer vettoriale (quello che disegni) scompare a livelli di zoom molto spinti
se usato in internet explorer mentre il problema non cè
con chrome o firefox
cè maniera di porvi rimedio?
By vigj on set 29, 2009
purtroppo internet explorer è un must in molte situazioni
By Alessio on set 29, 2009
Grazie della segnalazione Vigj.
Non se ho capito bene, però ho fatto una prova: ho disegnato un poligono e zoomato fino al massimo livello previsto. Così facendo non ho riscontrato il problema da te descritto né con IE7 né con IE8 (IE6 non lo considero più alle soglie del 2010).
Il layer vettoriale rimane al suo posto sulla mappa. Quello che “sparisce” è ovviamente il layer di base se si è in una zona per la quale non esiste un dato di grosso di dettaglio.
PS
IE più che un must è un virus
By vigj on set 29, 2009
io non ho proprio disegnato
ho messo questo GEOJSON
{
“type”: “FeatureCollection”,
“features”: [
{ "geometry": {
"type": "GeometryCollection",
"geometries": [
{
"type": "LineString",
"coordinates":
[[13.2, 46.1],
[13, 46]]
},
{
“type”: “Polygon”,
“coordinates”:
[[[11.0878902207, 45.1602390564],
[14.931640625, 40.9228515625],
[0.8251953125, 41.0986328125],
[7.63671875, 48.96484375],
[11.0878902207, 45.1602390564]]]
},
{
“type”: “Point”,
“coordinates”: [13.2, 46.1]
}
,
{
“type”: “Point”,
“coordinates”: [13.21, 46.12]
}
]
},
“type”: “Feature”,
“properties”: {}
}
]
}
con IE se zoomi a un certo punto poi sparisce
forse allora il problema sta nel GEOJSON
By Alessio on set 29, 2009
Testato con la tua stringa e la feature scompare su IE come hai detto.
Non saprei se è un problema della gestione delle feature GeoJSON in OL.
Ho fatto lo stesso sull’esempio del sito di OL e lì il problema non si verifica. Non so se la proiezione possa influire da questo punto di vista.
By vigj on set 29, 2009
credo che il problema si verifichi con sfondi commerciale (VE, Google maps) ad alti livelli di zoom, con IE, e se la feature è molto estesa.
se usi feature più “ridotte territorialmente” ho verificato che funziona anche su IE (che virus!)
mi sa che è un bacherozzo di OL