[Gfoss] Rilascio MapStore 1.5.1 con versione Mobile per Android

Maurizio Trevisani maurizio.trevisani a gmail.com
Lun 24 Mar 2014 09:39:30 CET


Ciao Simone,
intervengo esclusivamente sulle tue riflessioni

"In qualità di rappresentante di GeoSolutions mi sento in dovere di
rispondere ancora una volta puntualizzando alcuni aspetti non solo dal
punto di vista tecnico e se questo comporterà di non lavorare piu' con
enti vicini o legati a RT lo prenderò come uno stimolo in piu' per
decidermi finalmente a spostare l'azienda all'estero. Fatto questo,
GeoSolutions e tutti i  suoi collaboratori dovranno necessariamente
smettere di intervenire su questa lista per evitare che l'immagine
aziendale venga deliberatamente danneggiata senza apparenti motivi e,
a mio parere, spesso con critiche fuori luogo e scarsamente
documentate tecnicamente.".

Non esiste assolutamente una preclusione nei confronti di
Geosolutions, che infatti sta lavorando (tramite altri soggetti che
operano per conto di RT) anche per RT.

Vi sono alcune strategie che abbiamo costruito nel tempo:
1) adozione esclusivamente di soluzioni GFLOSS per l'implementazione
dell'infrastruttura spaziale regionale;
2) adozione esclusivamente di soluzioni GFLOSS quali client Desktop di
cui tentare la diffusione all'interno dell'Ente (tramite percorsi
formativi ed helpdesk);
3) affidamento di attività evolutive di alcuni specifici prodotti per
meglio supportare la capacità di conservare, gestire, elaborare,
fruire e far fruire i dati prodotti o raccolti da RT:
3.1) Evoluzioni del prodotto Spatialite (prodotto Toscano) per
favorire la memorizzazione, insieme ai dati, delle vestizioni e della
metainformazione;
3.2) Evoluzioni del prodotto Qgis per favorire l'interfacciamento con
Spatialite (ed in prospettiva per gestire le metainfo e le vestizioni
all'interno di Splite) con rilascio degli sviluppi all'interno dei
repository ufficiali (evitando fork) e passando tramite aziende (di
recente essenzialmente toscane) in grado di interagire con i
manutentori dei repository;
3.3) In prospettiva, adozione di Splite come geodatabase open source
per la cessione di dati geografici;
3.4) Ulteriore implementazione di Spatialite per aggiungere le
funzionalità di gestione dei dati raster (abbiamo un patrimonio
importante di immagini, Lidar, ecc. che vorremmo utilizzare/fornire in
un geodatabase open source).
3.5) Favorire i processi di formazione dei dati geografici adottando,
nei nostri capitolati, specifiche che vincolino all'utilizzo di
formati OS (Shapefile, Spatialite, SVG, QML, ecc.);
3.6) Favorire lo sviluppo dei SW prodotti per noi con rilascio su
Github dei codici sorgenti;
4) attivazione di servizi WMS, WFS (CSW, WCS, ....) interoperabili;
5) adozione del prodotto toscano Tolomeo quale framework per
l'implementazione dei nostri webgis (utilizzando esclusivamente WMS,
WFS, CSW, ecc., senza dati in locale, e quindi in grado potenzialmente
di testimoniare dati di provenienza RT insieme a dati di altri
soggetti pubblici);
6) adozione del prodotto OS IIPSERVER per la pubblicazioni di
cartografie storiche e foto aeree (vedi ad esempio
http://www502.regione.toscana.it/grandimmagini/fotogrammi_smartviewer.html?img=cv001_142_355_08lug2010&sect=2010
 o http://www502.regione.toscana.it/castoreapp/1_viewer-layer-others.jsp?tipo=report&id=139_F01A
).

Chiaro che ci confronta con mille problemi, che piano piano, anche con
l'aiuto con la comunità GFOSS, speriamo possano essere gestiti.

Evidenzi una serie di problemi (dal "thread safe", alla robustezza, ai
driver JDBC obsoleti, alla non scalabilità di GeoTools per quanto
riguarda spatialite, ecc.) dove mi chiedo se esista la volontà, la
curiosità, l'interesse, la disponibilità, la valutazione di
opportunità a lungo termine o di utilità per "tutti" (in raccordo o
anche in complementarietà con quanto in RT cerchiamo di perseguire) ad
affrontarli.

Ciao,
Maurizio




Il 23/03/14, Simone Giannecchini<simone.giannecchini a geo-solutions.it>
ha scritto:
> Salve Andrea,
> trovi le mie risposte inline sotto.
>
>> Interessante questo mapstore 1.5.1
>>
>> Veod che gestisce pure un db spatialite.
>>
>> Come RT abbiamo finanziato anche uno studio per vedere se si riusciva a
>> far
>> funzionare spatialite con l'ambiente java.
>> Ma la ditta a cui per vie traverse era stato dato l'incarico, una ditta
>> esperta su geotools, non ci risulta che alla fine avesse concluso
>> alcunche'
>> di significativo.
>>
>
> Onestamente, essendo GeoSolutions un' azienda con sede legale e
> operativa in Toscana che da lavoro a 15 persone di cui almeno 10
> residenti in Toscana facendo il 70% del fatturato all'estero e pagando
> circa 14k di IRAP l'anno, ci dispiace (a me e al management di
> GeoSolutions) dover constatare questo ormai ovvio risentimento nei
> confronti di GeoSolutions da parte della nostra regione con cui
> peraltro non abbiamo MAI lavorato direttamente.
>
> In qualità di rappresentante di GeoSolutions mi sento in dovere di
> rispondere ancora una volta puntualizzando alcuni aspetti non solo dal
> punto di vista tecnico e se questo comporterà di non lavorare piu' con
> enti vicini o legati a RT lo prenderò come uno stimolo in piu' per
> decidermi finalmente a spostare l'azienda all'estero. Fatto questo,
> GeoSolutions e tutti i  suoi collaboratori dovranno necessariamente
> smettere di intervenire su questa lista per evitare che l'immagine
> aziendale venga deliberatamente danneggiata senza apparenti motivi e,
> a mio parere, spesso con critiche fuori luogo e scarsamente
> documentate tecnicamente.
>
> Aggiungo anche che vedendo come altre regioni e province italiane ma
> anche altri paesi (tutti) proteggano le loro aziende (spesso dobbiamo
> fare forzatamente da subcontractor per lavorare all'estero pagando
> pesante dazio) questa situazione è quantomeno assurda.
>
>
> Andando sul lato tecnico, innanzitutto, il supporto a spatialite di
> cui si parla si limita alla versione Android che non ha niente a che
> fare con il java standard come sicuramente saprai in quanto il codice
> non è (quasi) mai portabile tra una JVM standard e Dalvik.
>
> Oltretutto si basa su una versione non aggiornata di spatialite e NON
> usa driver JDBC ma istanzia la libreria e parla con essa direttamente
> via JNI, ergo mi sfugge il parallelo e sarei portato a pensare che sia
> solo un modo, come spesso è accaduto anche in passato, per criticare
> trasversalmente visto che la azienda che citi siamo noi.
>
> Visto che ci hai citato spiego l'antefatto. Spatialite si puo' usare
> abb tranquillamente in applicativi desktop basati su Java, ma su
> applicativi lato server come GeoServer, perlomeno al  momento in cui
> abbiamo fatto il famoso studio di ben 9 ore (o giu' di li non ricordo
> nel dubbio posso anche condividerei timesheet giornalieri e le
> relative fatture) aveva grossi (enormi?) problemi di gestione di
> thread multipli e di scalabilità (questo a livello dei driver JDBC).
>
> Noi, nella persona di Andrea Aime non l'ultimo arrivato, abbiamo
> evidenziato con test di scalabilità (che possiamo fornire a tutti) che
> questi problemi esistevano ed abbiamo testato tutti i diver JDBC
> esistenti. Abbiamo quindi chiesto di coinvolgere Furieri per validare
> i nostri risultati visto che chi meglio di lui poteva commentare e non
> mi risulta che qualcuno abbia detto che ci siamo sbagliati.
>
> Senza voler criticare Furieri, mi ricordo una sua email girata anche
> in questa lista dove evidenziava (su suggerimento di Even Roualt btw)
> che spatialite inizializzava male GEOS (in modo non thread-safe) e
> questo poteva portare a dei crash, cosa non accettabile in una
> applicazione Java e che sicuramente era una delle sorgenti dei crash
> che vedevamo.
>
> In 9 ore di studio spero che sia ovvio per tutti che non si sarebbero
> potuti risolvere tutti i problemi del supporto java verso spatialite e
> noi abbiamo correttamente suggerito i tempi ed i modi per intervenire
> nel caso ci fosse stato richiesto (dopo allego scambio email).
>
>
>
>> Tante' che l'unico reale aiuto viene fornito dall'intervento dalle
>> istruzioni di Furieri.
>> Alla fien dei slmi, esperti, ingegneri, informatici, tante chiacchere,
>
>
> Si in effetti siamo d'accordo, non è che gli ingegneri informatici
> servano a molto per la programmazione informatica. Credo che saranno
> d'accordo su questa osservazione anche tutti gli altri ingegneri
> informatici che leggono la lista. Però in qualità di ingegneri
> informatici laureati in meno di 6 anni con lode almeno la
> documentazione la archiviamo bene, per cui per chi fosse interessato
> alcuni degli scambi, perlomeno la nostra parte è reperibile qui:
>
> https://docs.google.com/document/d/1YzTeCyo6q1Lj5Kj3C3dsSOzBXs_2hne-f1wyBcqgWrQ/edit?usp=sharing
>
> Diro' di piu', se qualcuno vuole posso anche passare le classi di test
> che abbiamo scritto.
>
>
> Dall'interazione con Furieri abbiamo poi appreso che in effetti l'uso
> di Spatialite da Java in applicazione thread safe non è cosa
> immediata, soprattutto con i binari già disponibili nei pacchetti
> binari a disposizione nelle distribuzioni (la ricompilazione dai
> sorgenti è spesso un tabù, una libreria che la imponga diventa in
> questi casi inutilizzabile), cito un pezzo di mail dello stesso ( di
> nuovo non me ne verrà, visto che sa che lo stimo):
>
> "se mi passate la facile battuta, non parrebbe che quella di fare
> sviluppo thread safe sia stata una priorita' elevata per tutti quanti
> i principali team che curano le librerie di base C/C++ perlomeno non
> prima degli ultimi due anni o giu' di li quando poi ci e' premuniti di
> inserire qualche patch appiccicata un po' in qualche modo e spesso
> tenendole ben nascoste dentro a documentazioni un po' criptiche e con
> pochissima visibilita'.
>
> ...
>
> riassuntino ultra-short:
>
> - tutte le versioni di spatialite rilasciate fino ad oggi (Aprile
> 2013, ndr) sono  sicuramente thread unsafe
> "
>
> Ora, lo studio lo si è fatto in autunno 2013, quindi i problemi di
> thread safety erano risolti nelle versioni sorgente, ma non nelle
> versioni binarie disponibili nelle varie distribuzioni.
>
> Come problema ulteriore, spatialite stesso al momento dei test andava
> in crash a causa di problemi nel caricamento dinamico della libreria,
> cosa risolta dopo la fine del nostro studio e non so se già rilasciata
> in forma stabile e ufficiale (mi pare di no, l'ultima versione è di
> Giugno 2013, noi abbiamo fatto i test durante l'autunno).
>
> In buona sostanza, il nostro breve lavoro ha messo in luce una serie
> di criticità che richiedono lavoro per essere risolte. La cosa non è
> oltrettuto banale perchè non si lavora su campo libero, GeoTools ha
> già un modulo Spatialite vecchio di qualche anno che punta alla
> semplicità facendo embedding delle librerie native necessarie,
> staticamente compilate dentro alcune lib java (pagando però il prezzo
> di scalabilità pressochè nulla), proporre una versione che funzioni
> solo se sono installate librerie native di recente aggiornamento
> (anche visto il problema che spesso aggiornare le librerie sui server
> non è permesso) non è immediato, una nuova soluzione deve tener conto
> delle problematiche di semplicità d'uso, e evitare di cozzare contro
> il lavoro di supporto a GeoPackage, che per quanto non usi Spatialite,
> usa lo stesso driver JDBC Xerial usato dal modulo Spatialite: il
> driver JDBC in uso deve rimanere allineato, visto che non si possono
> agganciare due volte le librerie native di sqlite con versioni diverse
> dallo stesso processo, ne conseguen che qualunque passo venga fatto
> non si può limitare alla sola revisione del modulo Spatialite, ma
> necessariamente coinvolge anche un aggiornamento dei moduli
> GeoPackage.
>
> Vista l'ampiezza dello sforzo necessario e le inevitabili discussioni
> in comunità una operazione come quella sopra descritta richiede un
> significativo sforzo in termini di tempo, cosa che noi abbiamo
> sottolineato nelle nostre comunicazioni scritte con il committente.
> _______________________________________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 666 iscritti al 22.7.2013


Maggiori informazioni sulla lista Gfoss