Aggiornate!
Locked
 
|
Salve.
Leggendo il n° 3 della rivista Geomedia, sono incappato in un articolo su cartografia digitale, GIS e remote sensing. C'e' un confronto, ovviamente superficiale visto il contesto, ma mi pare abbastanza neutrale, fra un noto GIS proprietario ed alcuni GIS liberi. Quello che ho trovato bizzarro e' che l'autore dichiara di usare QGIS nella versione 1.5, pubblicata ai tempi di isau'. Come ovvia conseguenza, si dice (a sproposito IMHO) che la gestione dei dati tabulari in QGIS non e' all'altezza del GIS proprietario. Mi aiutate a capire perche' si fa talvolta cosi' fatica a recepire il mantra "se pubblichiamo una nuova versione di un programma libero e' perche' ci sono tante funzioni nuove e migliori, aggiornate"? Saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [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 |
|
|
> Salve. > Leggendo il n° 3 della rivista Geomedia, sono incappato in un articolo > su cartografia digitale, GIS e remote sensing. C'e' un confronto, > ovviamente superficiale visto il contesto, ma mi pare abbastanza > neutrale, fra un noto GIS proprietario ed alcuni GIS liberi. Quello che > ho trovato bizzarro e' che l'autore dichiara di usare QGIS nella > versione 1.5, pubblicata ai tempi di isau'. > Come ovvia conseguenza, si dice (a sproposito IMHO) che la gestione dei > dati tabulari in QGIS non e' all'altezza del GIS proprietario. A questo punto, per coerenza, avrebbe dovuto effettuare il confronto con la versione 3.3 del famoso software commerciale. ;) > Mi aiutate a capire perche' si fa talvolta cosi' fatica a recepire il > mantra "se pubblichiamo una nuova versione di un programma libero e' > perche' ci sono tante funzioni nuove e migliori, aggiornate"? Beh, direi che dovresti inviare ufficialmente una precisazione, che dovranno pubblicare (pena, citazione in giudizio per danni morali e materiali :) sulla rivista (anche se web), con la stessa visibilità dell'articolo. Scherzo, ovviamente. Ma mica tanto... ! Ciao Roberto _______________________________________________ [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 pcav
se ricordo bene. Circa due anni fa' te, Paolo, facesti un intervento lamentando che su internet , ma non ricordo in che contesto .Un tizio aveva fatto un confronto tra qgis e altri softwares. E anche in quel caso era stato usato qgis 1.5 (all'epoca il piu' recente prodotto qgis era la 1.7). Ora guarda caso spunta fuori un altro articolo sempre basato su qgis 1.5. Ma guarda un po'. :)) Il giorno 10 gennaio 2014 15:59, Paolo Cavallini <[hidden email]> ha scritto: Salve. -- ----------------- 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 |
|
|
Aggiungo che in linea di rincipio sono sempre stato contrario agli articoli comparativi. Anche tra i vari softwares GFoss. Sono una perdita ditempo a prescindere e non servono a niente. E' utile un articolo che insegna a fare il caffe' con una data caffettiera, ma l'articolo che fa il confronto tra vari tipi di caffettiere mi pare alquanto inutile. Il gis deve servire per fare il proprio lavoro e non è una gara a chi è il migliore. Chi è piu' produttivo con altri software fa bene a continuare a usarli. Chi non ha idea di come funzione qgis farebbe bene a non perderci tempo sopra.A. Il giorno 10 gennaio 2014 16:48, Andrea Peri <[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 |
|
Opinione rispettabile ma non condivisibile, e mi spiego. Le prestazioni della singola caffettiera sono fini a se stesse, invece nettamente piu' utile e' un raffronto fra i vari modelli, in una rigorosa ottica costi/benefici. A maggior ragione se parliamo di fondi pubblici, tu dirigente P.A., prima di decidere quale Gis introdurre nei tuoi uffici tecnici, puoi (anzi, DEVI) basarti su un'analisi comparativa di cio' che offre il mercato. Se cosi' non fosse, non sapresti manco che esiste il software Gfoss, e compreresti il piu' "famoso e compatibile" di tutti (a spese del contribuente) delegando gli eventuali problemi al servizio post-vendita. La questione non sono gli indispensabili 'benchmark', ma CHI li conduce e COME. Nella fattispecie dell'articolo Geomedia, sono stati prodotti da uno sciagurato pseudo-tecnico, la cui miopia ha portato nocumento alla causa opensource. Ecco quindi che, in fase decisionale, conviene leggersi non uno ma diversi confronti tecnico-commerciali, in modo da farsi un quadro completo ed oggettivo. |
|
|
ok,
proseguiamo il confronto: :) Io non sono convinto che leggersi molti articoli comparativi serva un gran-che'. Altrimenti basterebbe scrivere tanti articoli e pubblicarli sulle riviste online. Ti faccio un esempio: io da ingegnere elettronico, ai tempi dell'universita', ma anche prima (sigh), mi leggevo una famosissima rivista che si chiamava BYTE (americana). Avevo anche ll'abbonamento. BYTE era considerata dagli addetti "la bibbia" dell'informatica. I suoi test sui singoli prodotti software ed hardware (ma principalmente hardware) erano realizzati BENISSIMO. scavava a fondo nei dettagli e spesso precorreva le novita' dei vari settori. La differenza tra byte e le altre riviste , era che le altre riviste compravano articoli da chi capitava. Bastava che uno scrivesse un articolo e glielo spediva a una rivista e se piaceva , se era variopinto e avevam molti numerelli che fanno fico veniva preso e pubblicato. Compenso, credo andasse intorno a 100.000 lire ad articolo ma dipendeva dalla rivista. Era nato proprio un mercato degli articoli, gente che scopiazzava dalle faq dei vari prodotti, oppure che si inventava di sana pianta teorie pur di scrivere qualcosa per incassare. BYTE invece era lei che chiamava di volta in volta persone con curriculum (veri) lunghi come lenzuoli e commissionava determinate prove. Ora tale rivista non esiste piu'. Ne esiste una versione online , ma con una attivita' molto piu' ridotta. Questo perche' tale modo di operare costava caro e non vi era resa. Ma conosco tanta gente che si è formata sulle colonne di Byte (me compreso). Ora non è piu' cosi'. Le riviste che danno un vero aiuto e che possono rappresentare un punto di riferimento per determinate scelte, non esistono piu'. Tornando al discorso originale. AI giorni d'oggi scrivere un articolo e pubblicarlo su internet costa pochissimo. Te ipotizzi di andare per numero. Se cosi' fosse, un diigente che trova su internet 10 articoli qua' e la' che parlano male del software GFoss in contraddizione a due solamente che ne parlano bene che dovrebbe concludere ? Te dici chi ha scritto l'articolo è uno pseudo-tecnico. Puo' darsi , ma chiunque potrebbe esserlo. Come si fa a capire chi è tecnico e chi no. Scrivere un po' di paroloni alla "supercazzora" (stile conte mascetti) ormai lo sanno fare tutti. Per cui conta solo il numero. E i numeri vanno dalla parte di chi puo' investire in una campagna martellante di articoli sparsi qua' e la'. Tornando a quelloche ho detto: io non ho detto che uno deve usare software commerciale. Un dirigente ha il dovre di documentarsi. Ma documentarsi non vuol dire leggersi un po' di articoli su internet. Perche' a un dirigente si chiede in primis di saper prendere decisioni in autonomia. E senza lasciarsi influenza da chicchessia, ne' dal piazzista della ditta X o Y. E non deve limitarsi chiedere ma deve saper valutare le risposte, saper capire se la risposta che ha ottenuto è frutto di conoscenza o frutto di altro. Ad esempio immagino che molti usino softwares commercale perche' gia' presente al loro arrivo e quindi continuino a usarlo per semplicita'. In un tale scenario un dirigente sarebbe chiamato , secondo la nuova legge, a documentarsi e capire se per il suo lavoro il software che sta usando è ancora valido e compatibile con tale normativa o se deve muoversi in altra direzione, ma non puo' attenersi per questo agli articoli su internet in un senso o nell'altro. Deve costruirsi lui la risposta, studiando , indagando, anche chiedendo, ma sapendo discernere. Ti faccio un esmepio: proprio due giorni fa' parlando con un collega dell'ufficio si discuteva di una procedura che effettuasse il clip di geometria in una deterinata maniera. Ne abbiamo passate in rassegna alcune, sia in qgis che in saga. Ma non ne abbiamo trovata una che facesse le cose come serviva a noi. Il mio collega mi diceva che su un noto software commerciale gis tale modalit'a si poteva fare. Purtroppo nei softwares che abbaimo non si puo' fare e quindi al collega è toccato mettersi li' e clippare a mano come voleva lui, uno per uno tutti gli elementi del dataset. Spendnedoci una giornata intera e non so se gli è bastata. Ma da dire questo a dire che il software commerciale è meglio direi una castroneria e non ci penso proprio. Perche' per una cosa che tizio fa meglio, ce ne una altra che fa meglio caio. Ribadisco i test comparativi non servono perche' tanto non sai cosa serve realmente. Le esigenze cambiano di giorno in giorno e il programmam "enciclopedia" che racchiude tutto quanto non potra' mai esistere. ciao, A. On 11/01/2014 08:33, antoniovinci wrote: > / > Andrea Peri wrote >> gli articoli comparativi ... sono una perdita ditempo a prescindere e non >> servono a niente > / > Opinione rispettabile ma non condivisibile, e mi spiego. > > Le prestazioni della singola caffettiera sono fini a se stesse, invece > nettamente piu' utile e' un raffronto fra i vari modelli, in una rigorosa > ottica costi/benefici. > > A maggior ragione se parliamo di fondi pubblici, tu dirigente P.A., prima di > decidere quale Gis introdurre nei tuoi uffici tecnici, puoi (anzi, DEVI) > basarti su un'analisi comparativa di cio' che offre il mercato. > > Se cosi' non fosse, non sapresti manco che esiste il software Gfoss, e > compreresti il piu' "famoso e compatibile" di tutti (a spese del > contribuente) delegando gli eventuali problemi al servizio post-vendita. > > La questione non sono gli indispensabili 'benchmark', ma CHI li conduce e > COME. > > Nella fattispecie dell'articolo Geomedia, sono stati prodotti da uno > sciagurato pseudo-tecnico, la cui miopia ha portato nocumento alla causa > opensource. > > Ecco quindi che, in fase decisionale, conviene leggersi non uno ma diversi > confronti tecnico-commerciali, in modo da farsi un quadro completo ed > oggettivo. > > > > ----- > > > -- > View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Aggiornate-tp7585812p7585823.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 |
|
|
In reply to this post by antoniovinci
Salve a tutti,
Io, personalmente, considerando anche le nuove funzionalita' gia' implementate per Qgis 2.2 (multi-threading in primis) sceglierei senza dubbio QGis :-) Questo pur stimando molto il software commerciale GIS di cui immagino si faccia riferimento nella rivista Geomedia... Anche secondo me le tabelle comparative tra i software lasciano un po' il tempo che trovano... Soprattutto, secondo me, sono difficilissime da effettuare "bene" (come tempo necessario e competenze tecniche richieste). Sono pero' dell'idea che siano *molto* utili (se pero' non sono aggiornate...). E' vero che un utente puo' scegliere diversi tipi di caffetteria (esempio di Andrea). Non e' pero' scontato che: - il caffe' sia buonissimo in tutti i modelli; - che il consumo elettrico sia simile; - che il prodotto acquistato non si rompa il giorno esatto dopo la scadenza dell'utensile (la cosidetta "obsolescenza programmta"...); - etc etc (es. costo, facilita' di utilizzo). La difficolta' che rimane e' pero' quella di dover consigliare "correttamente" un software GIS ad un nuovo utente. Attualmente, i software GIS open source sono gia' molto avanzati per cui le funzionalita' di "base" sono gia' tutte sviluppate... In linea di principio, qualunque software GIS open source andrebbe quindi bene... Poniamo quindi che un tecnico consigli di usare il Software X (che sia Grass, Qgis, gvSIG, Udig oppure...). Io ci vedo 2 rischi successivi: 1. Quello di salvare dei progetti con delle vestizioni cartografiche poco compatibili in seguito con altri software analoghi. Per es. Qgis 2.2 dovrebbe avere un ottimo supporto per il "Gradient Fill" negli shapes [1]. Se uno salva il suo progetto con questa nuovissima funzionalita' anche gli altri software open source GIS dovrebbero fornire questa opzione per aprire corretamente i progetti di Qgis. Ovviamente, qui il problema NON e' cosi' rilevante rispetto all'utilizzo di formati proprietari... 2. Le interfacce (GUI) sono piuttosto diverse nei vari software open source GIS. E' chiaro che per dei tecnici GIS di professione il problema e' "facilmente" aggirabile con un po' di sforzo (e di documentazione aggiornata). Tuttavia, per i non addetti ai lavori, si tratterebbe di imparare nuovamente moltissime procedure. Chi ha qualche esperienza nell'insegnamento sa per certo le difficolta' enormi che questo comporta (gia' sento le urla degli studenti...) :-) Comunque, per tornare seriamente al punto della discussione, recentemente ho letto un confronto tra diversi software GIS open source [2]. L'articolo pubblicato e' in spagnolo [3] e il lavoro di comparazione e' stato effettuato da docenti di una Universita' della Colombia. E' stato presentato a Ottobre 2013, durante le 5° giornate di gvSIG per gli utenti dell'America Latina e Caraibi. In questo articolo (comparazione), secondo me, il problema e' opposto a quello presentato da Paolo Cavallini. Dalla sua lettura non si evince quale sia stata la versione dei software GIS testati... :-) Dalle date della bibliografia inclusa sembrerebbe pero' di dedurre che siano state utilzzate "vecchie" versioni degli applicativi (es. Qgis 1.8 se va bene...) E qui torniamo nuovamente ai punti critici *molto* interessanti sollevati giustamente da Andrea Peri nei giorni scorsi... Cordiali saluti Silvio Grosso [1] http://nyalldawson.net/2014/01/waiting-for-qgis-2-2-gradient-fills/ [2] http://andersonmedeiros.com/artigo-comparacao-softwares-livres-sig/ [3] http://downloads.gvsig.org/download/events/jornadas-lac/5as-jornadas-lac/articles/Article-5asLAC_Comparacion.pdf |
QGIS Multithread - ex Re: Aggiornate!
|
|
On 11/01/2014 09:32, Silvio Grosso wrote:
> Io, personalmente, considerando anche le nuove funzionalita' gia' > implementate per Qgis 2.2 (multi-threading in primis) sceglierei senza > dubbio QGis:-) Spero tu abbia ragione. A me questa storia del multithreading mi sembra una enorme boiata di stile accademico buttata li' giusto per vedere che succedeva se..... E temo che complichera' tanto il funzionamento complessivo di qgis con tanti malfunzionamenti in tanti settori. Con il rischio di rendere qgis pochissimo credibile in ambito corporative. Premesso che non lo ho provato e non avrei il tempo di provarlo per cui spero ardentemente di sbagliarmi. Mi sono formato questa opinione leggendo i vari thrad sui problemi che sono sorti e sulle soluzioni che sono state adottate, per cui ci sta bene che mi sbagli, ma francamente, spero che il mutlithtread faccia la sua comparsa dopo il qgis 2.2. :) Mi spiego con un esmepio: sembra che si siano accorti che l'approccio multithr esauriva le connession sul postgres (che di default ne circa 100). Che le esaurisca mi torna anche , perche' se su un progetto complesso si mette tanti strati dal postgis e ognuno agisce in multithread vuol dire che consuma una propria connessione. Trovato il baco si cerca la soluzione. La soluzione adottata è forse peggio del male. Infatti hanno impplementato un sistema di pooling lato client. Per cui ogni client qgis si crea un proprio pooling di connessione sul postgres e ricicla sempre quelle. Questa soluzione puo' andare bene se uno ragione del proprio postgres personale, ma se si comincia a pensare che debba essere adottata da un postgres corporative su cui insistono contemporaneamente centinaia di utenze distinte. se ogni utenza qgis si crea un pooling lato client con sopra chesso' 10-20 connessioni, le necessita' di risorse del server dbms aumenteranno a dismisura. Certo non se ne accorge il singolo utente che usa in proprio una istanza di postgis sul proprio qgis. Ma se ne accorge chi usa il postgis in un ambiente corporative. Con il rischio di rovesciare sul sevre dbms e su chi lo gestisce tutti i problemi di connettivita' e di performance. Tra l'altro chi usa un postgis isolato sul proprio pc potrebbe usare spatialite, ma questo è una altra storia. Per il resto, so' benissimo che prima di parlare bisogna provare. E io non sto provando niente, ma solo seguendo con una certa trepidazione questa storia e incrociando le dita di mani e piedi. E scongiuri a 260 gradi. E quindi dovrei stare zitto, ma sono talmente pessimista su questa storia del multithread che mi è difficile far finta di niente. Riporto i miei timori solo perche' spero che qualcuno mi possa dire che ho capito fischi per fiaschi. A. _______________________________________________ [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 antoniovinci
> Nella fattispecie dell'articolo Geomedia, sono stati prodotti da uno
> sciagurato pseudo-tecnico, la cui miopia ha portato nocumento alla causa > opensource. Beh, vabbè. Comunque, l'articolo sarà stato firmato da qualcuno, che dovrà scrivere per correttezza delle precisazioni al suo articolo. Mandiamogli una eMail, tramite la redazione. O no? Roberto _______________________________________________ [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: QGIS Multithread - ex Re: Aggiornate!
|
|
In reply to this post by Andrea Peri
On 11/01/2014, Andrea Peri wrote:
> A me questa storia del multithreading mi sembra una enorme boiata di stile accademico buttata li' giusto per vedere che succedeva se..... Beh, sicuramente, come hai gia' evidenziato benissimo, e' ancora troppo presto per pronunciarsi in proposito... :-) Io, personalmente, posso confermare che almeno per Krita [1], un software di disegno open source che conosco piuttosto bene, questa nuova funzionalita' ha migliorato di *molto* il suo utilizzo in termini di prestazioni. A me personalmente poter sfruttare in pieno, con Qgis, il mio computer con una CPU Intel I7 non dispiacerebbe affatto :-) Scherzi a parte, per Qgis 2.2. temo che in futuro un possibile rischio sia la maggiore difficolta'di contribuire al progetto per degli sviluppatori software *esterni* (NON mi riferisco qui alla scrittura di "semplici" plugin opzionanli esterni in Python...). E' verosimile, temo, che sara' piu' difficile inserire delle patch senza creare casini vari in altre parti del codice (bachi vari) ... Per esempio, attualmente, lo sviluppatore che si sta occupando di sviluppare il multi-threading non a caso e' Martin Dobias, cioe' colui che ha partecipato fin dall'inizio al suo sviluppo (anche con un Summer of Code di Google). Martin, tra l'altro, ha migliorato di moltissimo in passato il supporto in Python per Qgis. Tra le sue innumerevoli attivita' per Qgis ha anche creato il plugin Db-Manager poi migliorato da molti altri sviluppatori (quindi dovrebbe conoscere piuttosto bene PostGIS ). Secondo me, il punto fondamentale e' che Qgis e' ormai arrivato ad essere cosi' avanzato in termini di funzionalita' che il multi-threading e' quasi una "scelta obbligata" perche' le altre funzionalita' di base sono state gia' state quasi tutte implementate :-) Lascio pero' la risposta al tempo (che e' sempre di gran lunga il migliore giudice...) ed agli altri sviluppatori di software GIS molto presenti in questa lista :-) Cordiali saluti Silvio Grosso [1] http://krita.org/ |
|
|
Il 11/01/2014 13:59, Silvio Grosso ha scritto:
> Lascio pero' la risposta al tempo (che e' sempre di gran lunga il migliore > giudice...) ed agli altri sviluppatori di software GIS molto presenti in > questa lista :-) Salve. Ovviamente questo e' un cambiamento architetturale notevole, e sicuramente il passaggio non sara' semplicissio ed immediato. Infatti ne stiamo parlando da anni, e solo ora, avendo a disposizione uno sviluppatore di prim'ordine a tempo pieno, ci siamo avventurati. L'approccio preso pero' e' piuttosto "morbido" (si apre un nuovo thread per layer, mentre quello che sarebbe davvero complesso sarebbe spezzare la lettura di un singolo layer su >1 thread. In ogni caso, ormai il assaggio e' fatto, non si torna indietro a meno di tragedie non prevedibili. Quello che possiamo fare tutti e' provare il piu' possibile la versione in sviluppo, in modo da far presenti il prima possibile gli eventuali problemi residui. Saluti, e grazie. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [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: QGIS Multithread - ex Re: Aggiornate!
|
|
Ciao Paolo, intendi dire che gia' nella 2.2 è previsto il multithreading sul rendering ? Il giorno 13 gennaio 2014 08:23, Paolo Cavallini <[hidden email]> ha scritto: Il 11/01/2014 13:59, Silvio Grosso 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 |
|
|
Il 13/01/2014 08:27, Andrea Peri ha scritto:
> Ciao Paolo, > intendi dire che gia' nella 2.2 è previsto il multithreading sul rendering ? ne stiamo discutendo. saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |