Rilascio MapStore 1.5.1 con versione Mobile per Android
Locked
Rilascio MapStore 1.5.1 con versione Mobile per Android
 
|
Buonasera a tutti, siamo felici di annunciare il rilascio di MapStore 1.5.1. La presente release comprende la versione per Android
MapStore Mobile 0.1, gratuita ed OpenSource, le cui principali caratteristiche sono: - Local Database (ricerche spaziali ed altro)
- Styling (gestione tematismi) - GPS (funzioni di posizione su mappa) - Mappe Offline (Offline background, uso di spatialite database e molto altro)
Maggiori informazioni su MapStore Mobile sono disponibili nel blogpost di GeoSolutions.
MapStore 1.5.1 può essere scaricato ai seguenti link: Di seguito una lista degli aggiornamenti principali: #138 Introduce limits in servicebox
#152 Merge MapManager and MapComposer source trees #155 Add final reference link for WPS async request
#227 Write doc for sphinx documentation build #266 Text style component
#271 Help Plugin #281 SpatialSelectorField Form Widget for MapStore
#285 Overview Plugin #286 Make the Navigation Toolbar Icons bigger and more visible
#287 Make MapManager open maps into a tab rather than in an IFrame #288 Fixes for MapManager ‘de’ translation
#292 Improve the Embed Link functionalities #293 Fix sub-components layout in BBOXQueryForm
#299 Allow display of google maps messages and labels in current locale #312 Spanish translation
Si possono avere maggiori informazioni riguardo a questa release sul blogpost di GeoSolutions, sulla lista completa degli aggiornamenti o alla pagina MapStore 1.5.1 release notes.
Se non avete mai usato MapStore prima, potete leggere la guida rapida e navigare gli esempi
di mappe o creare velocemente la vostra prima mappa! Non dimenticatevi di visitare il sito web di MapStore al seguente link: per provare la galleria dei nuovi esempi di utilizzo (tra cui potete trovare anche MapStore Mobile) e trovare molte altre informazioni. Distinti saluti a tutti,
Il Team MapStore di GeoSolutions == Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK for more information. == Dott. Ing. Tobia Di Pisa Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- _______________________________________________ [hidden email] 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 |
|
|
Scusate l'ignoranza, ma se uno è primitivo come me, bisogna farsene una ragione.
Come si installa MapForge Mobile su smartphone Android? Dalla pagina https://github.com/geosolutions-it/MapStoreMobile/tree/v0.1 ho cliccato su download ZIP e mi sono scaricato, sul PC, MapstoreMobile -01.zip ...e poi? ...che devo fa'? Tramite cavetto USB devo copiarmi la cartella MapstoreMobile-01 nello smartphone? ...se si, ...dentro quale cartella dello smartphone? ...e poi? ...come faccio a far partire l'installazione dell'applicativo nello smartphone? P.S. dentro la cartella MapstoreMobile-01 ho visto delle sottocartelle "Geopaparazzi". Dato che Geopaparazzi installato nel mio smartphone funziona come un orologio svizzero e, da quando mi girano senza problemi su QGIS sia GeopapaTile (che in realtà non mi ha mai dato problemi) che GeopaparazziTags converter, non riesco più a farne a meno dall'usarlo e sono diventato Geopaparazzi-dipendente ...non è che installando queste cartelle, mi si scombussola tutto? ...lo so, lo so, sto esagerando ;-) Buona domenica. |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
Interessante questo mapstore 1.5.1 Veod che gestisce pure un db spatialite.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. Alla fien dei slmi, esperti, ingegneri, informatici, tante chiacchere, ma oi alla fine basta un programmatore esperto e tutto si risolve senza tanti fronzoli e chiacchere inutili. Questo mapstore ne è la prova. Infatti vedo che contiene un sacco di cose interessanti. E chi lo adottasse avrebbe tutto quanto gratuitamente..... Andrea.
Il giorno 23 marzo 2014 12:08, Marco <[hidden email]> ha scritto: Scusate l'ignoranza, ma se uno è primitivo come me, bisogna farsene una -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
On Sun, Mar 23, 2014 at 12:50:26PM +0100, Andrea Peri wrote:
> Alla fien dei slmi, esperti, ingegneri, informatici, tante chiacchere, > ma oi alla fine basta un programmatore esperto e tutto si risolve senza > tanti fronzoli e chiacchere inutili. s/un programmatore esperto/un programmatore esperto con sufficiente tempo disponibile/ -- Francesco P. Lovergine _______________________________________________ [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
Si, hai perfettamente ragione . Anche il tempo a disposizione è importante.
Il giorno 23 marzo 2014 15:08, Francesco P. Lovergine <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Marco
Ciao Marco
> Scusate l'ignoranza, ma se uno è primitivo come me, bisogna farsene una > ragione. > Come si installa MapForge Mobile su smartphone Android? > Dalla pagina > https://github.com/geosolutions-it/MapStoreMobile/tree/v0.1 > ho cliccato su download ZIP e mi sono scaricato, sul PC, MapstoreMobile > -01.zip ...e poi? ...che devo fa'? > Tramite cavetto USB devo copiarmi la cartella MapstoreMobile-01 nello > smartphone? ...se si, ...dentro quale cartella dello smartphone? ...e poi? > ...come faccio a far partire l'installazione dell'applicativo nello > smartphone? non hai alcuna ragione a sentirti ignorante. La app non va installata in questo modo. Sono sicuro che gli autori della app hanno piazzato l'applicazione da qualche parte per l'installazione e lo faranno sapere. > P.S. dentro la cartella MapstoreMobile-01 ho visto delle sottocartelle > "Geopaparazzi". Dato che Geopaparazzi installato nel mio smartphone funziona > come un orologio svizzero e, da quando mi girano senza problemi su QGIS sia > GeopapaTile (che in realtà non mi ha mai dato problemi) che GeopaparazziTags > converter, non riesco più a farne a meno dall'usarlo e sono diventato > Geopaparazzi-dipendente Ecco una cosa che si sente con piacere in una giornata di pioggia e neve dopo l'illusione della primavera :) > ...non è che installando queste cartelle, mi si > scombussola tutto? ...lo so, lo so, sto esagerando ;-) Nel momento in cui installerai la app con un pacchetto ufficiale fornito, non sara' possibile che le parti di libreria utilizzate (al momento ignoro quali siano) vadano in conflitto con l'installazione di geopaparazzi. Ma immagino che Tobia in caso mi correggera'. Ciao, Andrea > > Buona domenica. > > > > -- > View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Rilascio-MapStore-1-5-1-con-versione-Mobile-per-Android-tp7587316p7587419.html > Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. > _______________________________________________ > [hidden email] > 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 [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Andrea Peri
> 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. > > Tante' che l'unico reale aiuto viene fornito dall'intervento dalle > istruzioni di Furieri. > Alla fien dei slmi, esperti, ingegneri, informatici, tante chiacchere, > ma oi alla fine basta un programmatore esperto e tutto si risolve senza > tanti fronzoli e chiacchere inutili. > > Questo mapstore ne è la prova. > Infatti vedo che contiene un sacco di cose interessanti. > E chi lo adottasse avrebbe tutto quanto gratuitamente..... Non so bene quali siano state le tue esperienze riguardo a spatialite e java, ma per quanto riguarda spatialite e android ci si rifa' tutti a: https://code.google.com/p/spatialite-android/ Inoltre in geopaparazzi spatialite e' supportato in lettura da un bel pezzo. Tant'e' che il buon Mark Johnson sta mantenendo una versione il piu' allineata possibile con spatialite per android qui: https://github.com/geopaparazzi/libjsqlite-spatialite-android Andrea > > Andrea. > > > > > Il giorno 23 marzo 2014 12:08, Marco <[hidden email]> ha scritto: > >> Scusate l'ignoranza, ma se uno è primitivo come me, bisogna farsene una >> ragione. >> Come si installa MapForge Mobile su smartphone Android? >> Dalla pagina >> https://github.com/geosolutions-it/MapStoreMobile/tree/v0.1 >> ho cliccato su download ZIP e mi sono scaricato, sul PC, MapstoreMobile >> -01.zip ...e poi? ...che devo fa'? >> Tramite cavetto USB devo copiarmi la cartella MapstoreMobile-01 nello >> smartphone? ...se si, ...dentro quale cartella dello smartphone? ...e poi? >> ...come faccio a far partire l'installazione dell'applicativo nello >> smartphone? >> >> P.S. dentro la cartella MapstoreMobile-01 ho visto delle sottocartelle >> "Geopaparazzi". Dato che Geopaparazzi installato nel mio smartphone >> funziona >> come un orologio svizzero e, da quando mi girano senza problemi su QGIS >> sia >> GeopapaTile (che in realtà non mi ha mai dato problemi) che >> GeopaparazziTags >> converter, non riesco più a farne a meno dall'usarlo e sono diventato >> Geopaparazzi-dipendente ...non è che installando queste cartelle, mi si >> scombussola tutto? ...lo so, lo so, sto esagerando ;-) >> >> Buona domenica. >> >> >> >> -- >> View this message in context: >> http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Rilascio-MapStore-1-5-1-con-versione-Mobile-per-Android-tp7587316p7587419.html >> Sent from the Gfoss -- Geographic Free and Open Source Software - Italian >> mailing list mailing list archive at Nabble.com. >> _______________________________________________ >> [hidden email] >> 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 > > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty àèìòù > ----------------- > > _______________________________________________ > [hidden email] > 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 [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Andrea Peri
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. _______________________________________________ [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
Ciao Simone.
Interessante questo tuo dettaglio per cui te lasci l'italia per questo mio intervento. Ove, oltre tutto un aspetto non secondario era l'apprezzamento per il tuo prodotto. Per il resto mi pare che il tuo intervento sia esso stesso la migliore risposta che io potrei darti. Visto l'attegiamento che hai anche nei confronti dei tuoi collaboratori. Ionon ci vedo niente di male nel recriminare visto che veod un prodotto valido fare uso di spatialite su una piattaforma di per se' abbastanza ostica (dalvik) e non avere niente di analogo su una piattaforma che non è piu' complessa (java) >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. Quindi se capisco la tua spiega, secondo te è stato piu' facile portare spatialite su dalvik piuttosto che su una piattaforma Java Standard. il porting di spatialite su Dalvik lo avete finanziato voi di Geosolutions di vostra iniziativa ? >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). Non ho dubbi che su geoserver non sia facile da usare, ma strnaamente a me non risulta che mai ci si sia sognati di commissionare ad alcuna persona di supportare spatialite su geoserver. Se proprio devo dirla tutta, a me risulta che ci fossimo interessati per la realizzazione di un driver spatialite per Geotools. Evidentemente certe persone immaginano geotools e geoserver come due faccie della stessa medaglia e non si puo' agire sull'uno senza agire contestualmente anche sull'altro. Questo pero' aumenta i costi a carico di chi finanzierebbe non credi ? Comunque non sapevo di questo dualismo obbligato geotools-geoserver, lo scopro ora. >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. A suo tempo , quando mi giunse questa tua notizia, mi informai e emerse che la geos non è thread-safe (lo sapevi ?) Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il resto non lo è. Per cui la parte rilevante, quella della elaborazione non lo è. Io non sono un programmatore di geos, ma se chi lo è mi dice che non è thread-safe io gli credo. Queste notizie a te erano state fatte pervenire. Con la ovvia conclusione che se la geos non e' thread-safe non ha senso parlare di inizializzarla in modalit'a thread-safe. e comunque spatialite per questo ha implementato dei meccanismi di lock che se non sono thread-safe almeno impediscono le collisioni. Credevo che queste cose le avessi contemplate. Invece capisco da questo tuo intervento che ti eri fermato ben prima. Termino qui perche' vedo che fai un gran mescolone di tante cose. In ogni caso io facevo un apprezzamento del tuo prodotto recriminando sulla mancata occasione su spatialite con le geotools. E non potendo non notare che pero' nel tuo prodotto alla fine spatialite ci è entrato. bello o brutto che fosse. Non credo che ci fosse niente di cosi' male in tale intervento. Forse cercavi solo la scusa buona e io non sapendolo te la ho fornita ? almeno dimmi grazie. :) A. On 23/03/2014 18:27, Simone Giannecchini wrote: > 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. _______________________________________________ [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Simone Giannecchini
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§=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<[hidden email]> 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. > _______________________________________________ > [hidden email] > 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 [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Andrea Peri
Andrea, non abbiamo ancora esaminato insieme i risultato
dell'approfondimento. Visto che l'ho commissionato io devo precisare: - il comportamento multithread è parte dell'incarico non per le implicazioni geoserver ma perchè volendo usare l'accoppiata geotools-spatialite in ambito web servlet siamo a tutti gli effetti in una casistica multithread a prescindere da geoserver - se da questo lavoro potesse venire un buon supporto di spatialite per geoserver è un valore aggiunto per la comunità, quindi questo aspetto era sicuramente da indagare e quindi parte dello studio. Poi si sarebbe in seguito deciso in funzione delle complicazioni/costi se perseguirlo o meno - ho ricevuto da qualche mese il risultato dello studio, che evidenzia problemi e possibili soluzioni. Non immediate ma nemmeno impossibili. Devo ancora approfondirlo per poi parlarne con gli altri soggetti interessati, tra cui Andrea, per decidere se e come muovermi. Quindi non siamo andati avanti dipende dalle priorità (non si fa a tempo a seguire tutto..) nostre ma anche tue Andrea... Il 23/03/2014 20:39, aperi2007 ha scritto: > Ciao Simone. > > Interessante questo tuo dettaglio per cui te lasci l'italia per questo > mio intervento. > Ove, oltre tutto un aspetto non secondario era l'apprezzamento per il > tuo prodotto. > > Per il resto mi pare che il tuo intervento sia esso stesso la migliore > risposta che io potrei darti. > Visto l'attegiamento che hai anche nei confronti dei tuoi collaboratori. > > Ionon ci vedo niente di male nel recriminare visto che veod un > prodotto valido fare uso di spatialite su una piattaforma di per se' > abbastanza ostica (dalvik) e non avere niente di analogo su una > piattaforma che non è piu' complessa (java) > > >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. > > Quindi se capisco la tua spiega, secondo te è stato piu' facile > portare spatialite su dalvik piuttosto che su una piattaforma > Java Standard. > > il porting di spatialite su Dalvik lo avete finanziato voi di > Geosolutions di vostra iniziativa ? > >> 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). > > > Non ho dubbi che su geoserver non sia facile da usare, ma strnaamente > a me non risulta che mai ci si sia sognati di commissionare ad alcuna > persona di supportare spatialite su geoserver. > > Se proprio devo dirla tutta, a me risulta che ci fossimo interessati > per la realizzazione di un driver spatialite per Geotools. > > Evidentemente certe persone immaginano geotools e geoserver come due > faccie della stessa medaglia e non si puo' agire sull'uno senza agire > contestualmente anche sull'altro. > Questo pero' aumenta i costi a carico di chi finanzierebbe non credi ? > > Comunque non sapevo di questo dualismo obbligato geotools-geoserver, > lo scopro ora. > > >> 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. > > > A suo tempo , quando mi giunse questa tua notizia, mi informai e > emerse che la geos non è thread-safe > (lo sapevi ?) > Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il > resto non lo è. > Per cui la parte rilevante, quella della elaborazione non lo è. > Io non sono un programmatore di geos, ma se chi lo è mi dice che non è > thread-safe io gli credo. > Queste notizie a te erano state fatte pervenire. > > Con la ovvia conclusione che se la geos non e' thread-safe non ha > senso parlare di inizializzarla in modalit'a thread-safe. > e comunque spatialite per questo ha implementato dei meccanismi di > lock che se non sono thread-safe almeno impediscono le collisioni. > > Credevo che queste cose le avessi contemplate. > Invece capisco da questo tuo intervento che ti eri fermato ben prima. > > Termino qui perche' vedo che fai un gran mescolone di tante cose. > > In ogni caso io facevo un apprezzamento del tuo prodotto recriminando > sulla mancata occasione su spatialite con le geotools. E non potendo > non notare che pero' nel tuo prodotto alla fine spatialite ci è entrato. > bello o brutto che fosse. > Non credo che ci fosse niente di cosi' male in tale intervento. > > Forse cercavi solo la scusa buona e io non sapendolo te la ho fornita ? > > almeno dimmi grazie. > :) > > A. > > On 23/03/2014 18:27, Simone Giannecchini wrote: >> 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. > > _______________________________________________ > [hidden email] > 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 [hidden email] 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 |
|
|
In reply to this post by Andrea Antonello
Grazie per le informazioni. Resto in attesa che l'applicazione sia fruibile. |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Andrea Peri
2014-03-23 20:39 GMT+01:00 aperi2007 <[hidden email]>: -- Non ho dubbi che su geoserver non sia facile da usare, ma strnaamente a me non risulta che mai ci si sia sognati di commissionare ad alcuna persona di supportare spatialite su geoserver.
Il driver spatialite per GeoTools esiste da anni (almeno 3, non ho cercato la data precisa di introduzione),
in modalità single threaded funziona correttamente:
Chi ha commissionato il nostro studio lo ha fatto pensando al suo uso in Tolomeo, che è una applicazione Java server side, e pertanto multithreaded (richieste concorrenti sono servite da thread diversi).
In effetti i test di caricono sono stati svolti con un test scritto ad hoc che estrae dati direttamente lo store, non mediante GeoServer, per evitare che il carico extra legato a rendering/encoding di immagini in uscita, o encoding GML, andasse a attenuare le
differenze di prestazoni e scalabilità fra le diverse soluzioni.
Non è diverso dal finanziare modifiche a proj, geos, ecc, una funzionalità esistente non può essere modificata
facendo regredire caratteristiche già in uso da applicazioni che stanno a valle
Il legame fra GeoTools e GeoServer è stretto, non lo nego, perchè praticamente tutti gli sviluppator di GeoServer
lavorano anche su GeoTools, detto questo, non è che si possa andare a toccare qualcosa che tocchi uDig (che usa GeoTools, e a proposito, ha un renderer multithreaded che risente dei limiti del driver corrente)
con facilità. Le procedure per effettuare cambiamenti sostanziali sono chiare e documentate, in sostanza, si propone una modifica ufficiale mediante un improvement proposal (http://docs.codehaus.org/display/GEOTOOLS/Proposals),
questo viene discusso in mailing list fino a trovare un accordo su come debba essere sviluppato, e in questa fase è necessario piegare la proposta al feedback ricevuto, dopo di che si vota e si procede allo sviluppo.
Il modulo GeoPackage che citavo come possibile sorgenti di conflitto è in particolare un nuovo modulo GeoTools: Spero che questo chiarisca la situazione Cordiali saluti Andrea Aime Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187
55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 ------------------------------------------------------- _______________________________________________ [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Marco
Ciao Marco,
vedi sotto le mie risposte. == Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK for more information. == Dott. Ing. Tobia Di Pisa Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- Il giorno 23 marzo 2014 12:08, Marco <[hidden email]> ha scritto: Scusate l'ignoranza, ma se uno è primitivo come me, bisogna farsene una A quel link si trova solo il codice sorgente.
Per istallare MapStore Mobile sul proprio cellulare bisogna scaricare questo pacchetto http://demo.geo-solutions.it/share/mapstoremobile/MapStoreMobile.apk direttamente dal browser del cellulare Android.
Se si ha un barcode scanner installato sul cellulare (ad esempio questo: https://play.google.com/store/apps/details?id=com.google.zxing.client.android) si può scaricare il pacchetto scannerizzando questo QR Code.
Come terza alternativa si può scaricare sul proprio pc il pacchetto, copiarlo via USB e utilizzare il file browser del proprio cellulare per aprire il pacchetto.
Alla fine del download cliccare sul file appena scaricato e accettare di istallare il pacchetto.
P.S. dentro la cartella MapstoreMobile-01 ho visto delle sottocartelle GeoPaparazzi e MapStore mobile lavorano su file distinti. La coesistenza delle due applicazioni sullo stesso device non risulta aver mai dato problemi.
_______________________________________________ [hidden email] 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 |
Re: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
In reply to this post by Andrea Peri
On Sun, Mar 23, 2014 at 08:39:03PM +0100, aperi2007 wrote:
> A suo tempo , quando mi giunse questa tua notizia, mi informai e > emerse che la geos non è thread-safe > (lo sapevi ?) > Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il > resto non lo è. > Per cui la parte rilevante, quella della elaborazione non lo è. Non e' che non lo sia, non e' stata testata in maniera approfondita. Se Simone ha condotto questo studio magari ci sa dire. > Con la ovvia conclusione che se la geos non e' thread-safe non ha > senso parlare di inizializzarla in modalit'a thread-safe. In realta' ha senso usare la cosidetta api thread-safe perche' sicuramente risolve alcuni problemi (appunto i messaggi) subito, e poi perche' rende piu' facile beneficiare delle future risoluzioni di problemi di thread-safety. Considera che quella API venne contribuita proprio da qualcuno che evidentemente ne aveva sentito l'esigenza durante lo sviluppo di una applicazione thread-safe. Evidentemente a quel qualcuno la parte messaggistica (e di allocazione memoria) e' stata sufficiente a risolvere i problemi che aveva. --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt _______________________________________________ [hidden email] 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 |
|
|
Ciao Strk,
On Mon, 24 Mar 2014 13:55:13 +0100, Sandro Santilli wrote: >> giusto per semplificare la vita, non e' invece thread-safe la >> gestione dei messaggi di errore, a meno di non avventurarsi in >> soluzioni abbastanza "creative/fantasiose" (come quelle poi >> adottate da splite). > > Mi rinfreschi la memoria ? > I messaggi di errore vengono passati alla funzione che fornisci > con il "contesto" GEOS, dove fallisce la thread-safety ? Non puo' > essere che all'esterno di GEOS... > sorry, mi sono purtroppo espresso in modo frettoloso e poco preciso. non c'e' nulla nella gestione degli errori che offenda la sicurezza dei theads, funziona perfettamente bene. e' semplicemente molto poco pratico da usare; e vediamo perche': extern GEOSMessageHandler GEOS_DLL GEOSContext_setErrorHandler_r(GEOSContextHandle_t extHandle, GEOSMessageHandler nf); fino a qua tutto perfetto; passi un context diverso per ciascun thread, e tutto va perfettamente a posto. poi pero' passiamo a vedere il prototipo della funzione handler che viene chiamata in callback: typedef void (*GEOSMessageHandler)(const char *fmt, ...); dov'e' il problema ? non appare mai da nessuna parte il riferimento al context che ha dato origine all'errore; cosi' come non e' possibile gestire un qualunque pointer "custom" e quindi diventa abbastanza complicato tracciare a ritroso la causa scatenante dell'errore. molte altre librerie (libxml2, libproj, ma anche la stessa libsqlite3) quando devono affrontare problemi analoghi consentono sempre di passare avanti ed indietro un generico pointer void * fornito dal chiamante, su cui la funzione chiamata evita accuratamente di ficcare il becco limitandosi semplicemente a propagarlo tal quale a tutte le chiamate callback. una soluzione di questo tipo e' flessibile al massimo, e consente facilmente al codice chiamante di mettere in piedi con minimo sforzo tutte le diavolerie possibili per tenersi le cose ben allineate e chiaramante tracciate per origine. con la soluzione GEOS questo diventa invece un po' piu' incasinato; tutto qua. alla fine per splite ho risolto prevedendo un numero massimo di contexts possibili, ed ho associato una funzione handler diversa per ciascun context; in questo modo si riesce a tracciare individualmete ciascun contesto senza violare la thread-safety. funziona perfettamente: ma comunque e' una soluzione "barocchetta/roccoco'" On Mon, 24 Mar 2014 13:42:19 +0100, Sandro Santilli wrote: > On Sun, Mar 23, 2014 at 08:39:03PM +0100, aperi2007 wrote: > >> A suo tempo , quando mi giunse questa tua notizia, mi informai e >> emerse che la geos non è thread-safe >> (lo sapevi ?) >> Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il >> resto non lo è. >> Per cui la parte rilevante, quella della elaborazione non lo è. > > Non e' che non lo sia, non e' stata testata in maniera approfondita. > Se Simone ha condotto questo studio magari ci sa dire. > io a suo tempo ho condotto un test abbastanza spinto sull'uso concorrente spinto della GEOS CPU quad-core, smacinamento ciclico all'infinito di tutti i testcases spatialite basati su GEOS, da quattro fino a 16 threads concorrenti, il tutto protratto a sfinimento per un paio d'ore abbondanti (milioni e milioni di iterazioni). non ho avuto il piacere di beccare neppure una singola criticita'. ok, non e' un test rigoroso: ma immagino che permetta quantomeno di affermare che la GEOS regge discretamente bene, e che i rischi di qualche collisione tra threads sono assai poco probabili ;-) ciao Sandro _______________________________________________ [hidden email] 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 |
Re: R: Rilascio MapStore 1.5.1 con versione Mobile per Android
|
|
On Mon, Mar 24, 2014 at 04:12:53PM +0100, [hidden email] wrote:
> typedef void (*GEOSMessageHandler)(const char *fmt, ...); > > dov'e' il problema ? > non appare mai da nessuna parte il riferimento al context che > ha dato origine all'errore; cosi' come non e' possibile gestire > un qualunque pointer "custom" > e quindi diventa abbastanza complicato tracciare a ritroso > la causa scatenante dell'errore. Ah, gia' gia', ora ricordo. Ed ecco pure un ticket di 7 mesi fa. Con pull request !! Ti va di dare un'occhiata ed un tuo contributo ? http://trac.osgeo.org/geos/ticket/663 --strk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt _______________________________________________ [hidden email] 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 |
|
|
In reply to this post by Tobia Di Pisa
Buona la prima ! Installazione riuscita senza problemi. Grazie. |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |