Re: [Gfoss] Importare shapefile in postgis

2017-11-04 Per discussione Vittorio Bisaglia
Grazie Amedeo proverò come dici tu  buona serata

Il 04 nov 2017 9:24 PM, "Amedeo Fadini"  ha scritto:

> Quoto Andrea, in ogni caso ti suggerirei di usare direttamente db manager
> in qgis per l'import, potresti ad esempio copiare lo shapefile su memory
> layer (forse prende l'alias come nome) e poi importare in postgis
>
> amedeo
>
> Il 04/nov/2017 05:32 PM, "Andrea Peri"  ha scritto:
>
> Ciao
> e' impossibile che te abbia un campo "enominazione" sullo shapefile.
> Questo perche' lo shapefile prevede il DBF come parte alfanuerica e il DBF
> ammette da standard al massimo 10 caratteri per i nomi dei campi.
>
> Se te vedi un campo che si chiama "Denominazione" devi guardare al tuo
> ambiente GIS.
> Se ad esmepio usi qgis,
> la spiegazione e' che te o qualcun'altro ha impostato sulprogetto qgis la
> propeita' ALIAS dello specifico layer su cui visualizzi il tuo shapefle
> impoennedo da alias
>
> il campo al nome "Denominazione".
> Mentre invece esso si chiama "Denom".
>
> Postgis ovviamente uando caricalo shapefile usa lo shapefile e gnora il
> progetto QGIS.
> Per cui se ilcampo realmente si chiama DENOM, tale sara' il nome su
> postgis.
>
> A.
>
>
>
>
> Il giorno 4 novembre 2017 16:20, Vittorio Bisaglia <
> vittorio.bisag...@gmail.com> ha scritto:
>
> > Ciao a tutti come faccio a importare shapefiles in postgis mantenendo la
> > stessa formattazione dei campi? esempio: ho una campo "Denominazione" in
> > shape ma quando lo importo in postgis mediante shp2pgsql-gui mi diventa
> > "Denom". Ho provato cambiando l'encoding ma nulla. Sto lavorando con Qgis
> > 2.14 e pgAdmin3 in ambiente ubuntu xenial.
> > Grazie mille
> >
> > Vittorio
> > ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> > dell'Associazione GFOSS.it.
> > 801 iscritti al 19/07/2017
>
>
>
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017
>
>
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

Re: [Gfoss] Importare shapefile in postgis

2017-11-04 Per discussione Amedeo Fadini
Quoto Andrea, in ogni caso ti suggerirei di usare direttamente db manager
in qgis per l'import, potresti ad esempio copiare lo shapefile su memory
layer (forse prende l'alias come nome) e poi importare in postgis

amedeo

Il 04/nov/2017 05:32 PM, "Andrea Peri"  ha scritto:

Ciao
e' impossibile che te abbia un campo "enominazione" sullo shapefile.
Questo perche' lo shapefile prevede il DBF come parte alfanuerica e il DBF
ammette da standard al massimo 10 caratteri per i nomi dei campi.

Se te vedi un campo che si chiama "Denominazione" devi guardare al tuo
ambiente GIS.
Se ad esmepio usi qgis,
la spiegazione e' che te o qualcun'altro ha impostato sulprogetto qgis la
propeita' ALIAS dello specifico layer su cui visualizzi il tuo shapefle
impoennedo da alias

il campo al nome "Denominazione".
Mentre invece esso si chiama "Denom".

Postgis ovviamente uando caricalo shapefile usa lo shapefile e gnora il
progetto QGIS.
Per cui se ilcampo realmente si chiama DENOM, tale sara' il nome su postgis.

A.




Il giorno 4 novembre 2017 16:20, Vittorio Bisaglia <
vittorio.bisag...@gmail.com> ha scritto:

> Ciao a tutti come faccio a importare shapefiles in postgis mantenendo la
> stessa formattazione dei campi? esempio: ho una campo "Denominazione" in
> shape ma quando lo importo in postgis mediante shp2pgsql-gui mi diventa
> "Denom". Ho provato cambiando l'encoding ma nulla. Sto lavorando con Qgis
> 2.14 e pgAdmin3 in ambiente ubuntu xenial.
> Grazie mille
>
> Vittorio
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017




--
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

Re: [Gfoss] Visualizzazione dati espressi in sistemi di riferimento ad assi invertiti

2017-11-04 Per discussione a . furieri

On Sat, 4 Nov 2017 17:57:55 +0100, Andrea Peri wrote:

Quindi:
internamente un software GIS puo' ragionare sempre in X,Y, ma quando
esporta o importa dati da o verso formati che supportano l'inversione 
degli
assi e in sistemi di riferimento che richiedono l'inversione degli 
assi,
deve rispettare la specifica, altrimenti si pone fuori da una logica 
di

colloquio con tutto il resto del mondo.



Andrea,

sostanzialmente concordo con la tua analisi che mi pare impeccabile.

purtroppo pero' il mondo reale non e' mai cosi' semplice, e prima o
poi inevitabilmene capita di incontrare dati prodotti da componenti
sw che non seguono le regole, oppure che le interpretano a capocchia.

ragion per cui e' sempre saggio gestire un parametro aggiuntivo ad
hoc che permetta di fare l'override dell'impostazione standard:
p.es. per le funzioni di supporto WFS / WMS di SpatiaLite e
RasterLite2 ho dovuto introdurre "swap_axes=0 | 1" che consente di
forzare o meno l'inversione degli assi quando eventualmente si
incontra un server non conforme alle regole (e capita di incontrarne
molto piu' spesso di quanto uno si immagini).
e mi par di capire che pure GDAL offre qualcosa di analogo per
il GML.

insomma, alla fin fine il fatto che tutti gli standard OGC piu'
recenti impongano di invertire gli assi quando si tratta di
sistemi di coordinate geografici (ed in pochi altri casi, come
i nostri ultimi italici IGM) non e' una tragedia, ma e'
sicuramente una fonte di confusione di cui si sarebbe fatto
volentieri a meno.

giusto per finire, penso che sia illuminante rocordare come e
perche' da un certo punto in poi le specifiche OGC hanno cambiato
improvvisamente rotta introducendo questo strano criterio di
inversione degli assi per le coordinate geografiche.
Sono personalmente al corrente dei fatti perche' me li ha
riferiti Paul Daisey di OGC quando collaboravamo per la messa
a punto della specifica GPKG.

- inizialmente tutte le specifiche OGC davano sempre per
  scontato che la prima coordinata rappresentasse la X e
  la seconda la Y.
  ergo, nel caso delle coordinate geografiche prima veniva
  la longitudine e seconda la latitudine, cosi' come pareva
  logico e scontato (almeno: agli occhi di tutte le persone
  di formazione prevalemente informatica).

- a quel punto pero' hanno iniziato a fioccare le proteste
  di chi invece aveva una formazione geografica nel senso
  piu' tradizionale: ormai da secoli vale la regola universale
  per cui si parla sempre di latitudine e longitudine in
  questo esatto ordine; e quindi l'ordine "informatico"
  longitudine e latitudine e' stato giudicato innaturale
  e da respingere tout court.

- ovviamente gli informatici hanno provato a resistere con
  le unghie e con i denti, ma alla fine hanno perso.
  ed ecco che ora tutti gli standard piu' recenti di OGC
  (WMS, WFS, GML etc) impongono l'inversione degli assi
  quando sono in ballo le coordinate geografiche.
  Peccato pero' che tutti gli Spatial DBMS si sono ben
  guardati dal seguire la nuova regola "inversa", e
  quindi si e' venuto a creare un ovvio punto di
  conflitto.

conclusione: a volte il meglio e' nemico del bene :-D

ciao Sandro




___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

Re: [Gfoss] Visualizzazione dati espressi in sistemi di riferimento ad assi invertiti

2017-11-04 Per discussione Andrea Peri
Ciao,

lo so' e capisco la posizione espressa al link che hai postato.

Ma mi pare che il suo ragionamento sia piu' rivolto a come dovrebbe operare
internamente un software GS, pouttosto che alla capacit'a di
leggere/scrivere correttamente un formato di dati di esportazione.

Secondo questi sono due aspetti differenti.

Posso capire che per chi realizza il software GIS sia preferibile che il
suo software debba sempre sempre ragionare nel medesimo modo.
Anche io farei in tal modo, altrimenti sarebbe complicaissimo da gestire.

Ma questo non vuol dire che esso non debba capire i dati "altri" quando li
apre e li legge.

Mi spiego meglio.

Un software GIS quando apre un file di dati , le prime due cose che vede
sono :
il formato dei dati che puo' essere uno dei tanti supportati, vvero nel
nostro caso potrebbe essere SHAPEFILE oppure GML.
Poi la seconda cosa che il software GIS vede e' il sistema di riferimento
di tali dati.
Nel caso dello shapefile lo legge dal file PRJ associato, oppure lo chiede
all'utente. Nel caso del GML lo trova espresso all'inizio del file GML o
anche in ogni riga di dti del file stesso.

Nel caso di un shapefile e di un dato in coordinate epsg:4326, ilsoftware
puo' benissimo caricarsi i dati correttamente e trattarlilui come fossero
espressi in X,Y anziche' in Y,X.

Questo perche' il formato shapefile espreime sempre come X,Y.

Nel caso del GML con dati in un sistema di riferimento che inverte gli assi.
Il software GIS puo' dire:

Hey! questo e' un sistema di riferimento ad assi invertiti per cui devo
stare attento a leggere i suoi dati perche' gli assi sono invertiti.
Quindi il primo valore che leggo e' Y e il secondo e' X.

Poi una volta che il software GIS si e' caricato i dati puo' benissimo
porseli in formato interno in X,Y perche' cosi' le sue procedure , che sono
tutte realizzate per funzionare bene in X,Y funzionano al top.


Quindi:
internamente un software GIS puo' ragionare sempre in X,Y, ma quando
esporta o importa dati da o verso formati che supportano l'inversione degli
assi e in sistemi di riferimento che richiedono l'inversione degli assi,
deve rispettare la specifica, altrimenti si pone fuori da una logica di
colloquio con tutto il resto del mondo.

A.


Il giorno 4 novembre 2017 16:17, aborruso  ha scritto:

> Ciao Andrea,
> segnalo questa pagina https://macwright.org/lonlat/
>
> Io sono d'accordo con Tom - "longitude, latitude is the right way" [1] - ma
> il panorama è ricco
>
> Saluti
>
> [1]
> https://macwright.org/2016/07/15/longitude-latitude-is-the-right-way.html
>
> -
> Andrea Borruso
>
> 
> twitter: https://twitter.com/aborruso
> website: https://medium.com/tantotanto
> 38° 7' 48" N, 13° 21' 9" E
> 
> --
> Sent from: http://gfoss-geographic-free-and-open-source-software-
> italian-mailing.3056002.n2.nabble.com/
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

Re: [Gfoss] Importare shapefile in postgis

2017-11-04 Per discussione Andrea Peri
Ciao
e' impossibile che te abbia un campo "enominazione" sullo shapefile.
Questo perche' lo shapefile prevede il DBF come parte alfanuerica e il DBF
ammette da standard al massimo 10 caratteri per i nomi dei campi.

Se te vedi un campo che si chiama "Denominazione" devi guardare al tuo
ambiente GIS.
Se ad esmepio usi qgis,
la spiegazione e' che te o qualcun'altro ha impostato sulprogetto qgis la
propeita' ALIAS dello specifico layer su cui visualizzi il tuo shapefle
impoennedo da alias

il campo al nome "Denominazione".
Mentre invece esso si chiama "Denom".

Postgis ovviamente uando caricalo shapefile usa lo shapefile e gnora il
progetto QGIS.
Per cui se ilcampo realmente si chiama DENOM, tale sara' il nome su postgis.

A.




Il giorno 4 novembre 2017 16:20, Vittorio Bisaglia <
vittorio.bisag...@gmail.com> ha scritto:

> Ciao a tutti come faccio a importare shapefiles in postgis mantenendo la
> stessa formattazione dei campi? esempio: ho una campo "Denominazione" in
> shape ma quando lo importo in postgis mediante shp2pgsql-gui mi diventa
> "Denom". Ho provato cambiando l'encoding ma nulla. Sto lavorando con Qgis
> 2.14 e pgAdmin3 in ambiente ubuntu xenial.
> Grazie mille
>
> Vittorio
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017




-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

[Gfoss] Importare shapefile in postgis

2017-11-04 Per discussione Vittorio Bisaglia
Ciao a tutti come faccio a importare shapefiles in postgis mantenendo la
stessa formattazione dei campi? esempio: ho una campo "Denominazione" in
shape ma quando lo importo in postgis mediante shp2pgsql-gui mi diventa
"Denom". Ho provato cambiando l'encoding ma nulla. Sto lavorando con Qgis
2.14 e pgAdmin3 in ambiente ubuntu xenial.
Grazie mille

Vittorio
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

Re: [Gfoss] Visualizzazione dati espressi in sistemi di riferimento ad assi invertiti

2017-11-04 Per discussione aborruso
Ciao Andrea,
segnalo questa pagina https://macwright.org/lonlat/

Io sono d'accordo con Tom - "longitude, latitude is the right way" [1] - ma
il panorama è ricco 

Saluti

[1]
https://macwright.org/2016/07/15/longitude-latitude-is-the-right-way.html

-
Andrea Borruso


twitter: https://twitter.com/aborruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E

--
Sent from: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

Re: [Gfoss] Visualizzazione dati espressi in sistemi di riferimento ad assi invertiti

2017-11-04 Per discussione Andrea Peri
Salve,
volevo ringraziare quanti si sono interessati del problema e hanno fornito
soluzioni.

Nel frattempo avevo risolto.
Infatti avevo segnalato il problema all'autore del nostro software di
conversione dipartimentale il quale pure esso aveva il "bugghe" di non
considerare l'inversione di coordinate in epsg:4326 nel formato GML.
L'autore, espertissimo della materia, ha corretto il software e ora siamo
di nuovo operativi su questo fronte.

Tra le risposte mi e' stato segnaalto un workaround tramite il comando
swapcoordinates (o qualcosa di simile) di spatialite e usato da pgr per
generare un nuovo GML con le coordinate invertite e quindi corrette per
qgis.

Il workaround e' sicuramente valido e aiuta nel momento del bisogno.
Pero' da un punto di vista piu' generale , il problema resta, infatti.
Doversi ricondurre da un GML in epsg:4326 che ha correttamente le
coordinate espresse in
"latitudine longitudine" a un altro GML che in coordinate pesg:4326 ha le
coordinate espresse in maniera errata
ovvero in "longitudine latitudine" e' una sconfitta.
Perche' siamo in un caso i cui uno standard deve piegarsi alla volonta' di
una serie di softwares che impongono una cosa differente.

Poi, mi domando quanti saranno gli utenti che di fronte a una mappa ruotata
capiranno che il problem e' dovuto a una non inversione di assi.
E non ultimo il fatto che mi sono accorto che la mappa era invertita
perche' lo stivale d'italia si riconosce abbastanza bene, se erano poligoni
di forma generica,
il fatto di rilevarli lontano dalla zona attesa poteva essere imputabile a
un errore di georefereniazione del dato originale.

Insomma capire dove sta il vero problema rischia di divenire difficile.
Per cui 'unica difesa e' ricordarselo e nel caso ci si trova di fronte a
cose di questo genere ricordarsi che forse siamo di fronte a una mancata
inversione di assi.

Anche in virtu' , ricordo, che il nuovo sistema di riferimento italiano
prevede anche lui gli assi invertiti , e quindi quando comincera' a
circolare del gml espresso in epsg:6707/6708 e' facile prevedere parecchi
problemi.
Il workaround segnalato da Paolo Craveri sara' veramente gettonato.

Infine una curiosita' su QGIS:
A questo proposito mi era stato fornito una risposta in merito a QGIS in
particolare:
Sembra infatti che qgis avesse un settaggio con cui lo si istruisce di non
eseguire l'inversione degli assi e mi hanno fatto notare che probabilmente
il mio qgis era settato per non eseguire l'inversione degli assi.
Non sapevo di questo settaggio , lo ho cercato in qgis , ma non sono
riuscito a trovarlo.
Se riesco a scoprire qualcosa faccio sapere.

Saluti e di nuovo grazie per i contributi.
A.


Il giorno 2 novembre 2017 08:58, Andrea Peri  ha
scritto:

> Salve,
> l'argomento mio riguarderebbe QGIS, ma penso che in realta' abbia una
> valenza piu' larga perche' sospetto che il problema possa essere presente
> anche in altri prodotti.
>
> In soldoni:
> mi sono scaricato dal portale nazionale un dataset italiano in epsg:4326 e
> in formato GML.
>
> Quando vado a visualizzarlo con QGIS (2.18), mi accorgo che viene
> visualizzato ribaltato sui due assi.
>
> La spiegazione che io mi do' e'che QGIS non gestisce correttamente i dati
> espressi in sistemi di riferimento ad assi invertiti quando pesca da
> formati che ribaltano i valori.
> Nel caso del GML, se si esprime dati in epsg:4326,
> le coordinate dei punti anziche' essere
>
>  
>
> diventano
>  
>
> Questa cosa qui provoca su qgis una visualizzazione errata.
>
> Sospetto che questo problema possa essere comune anche ad altri sistemi
> gis.
> E' importante notare che la comparsa del problema e' legata anche
> all'impiego del formato GML.
> Infatti uno shapefile non si comporta come il GML e non usa invertire il
> significato dei valori nella coppia  .
>
> Per cui unoshapefle in epsg:4326 e' sempre visualizzato correttamente.
>
> La questione non e' trascurabile se si considera che anche il sistema di
> riferimento epsg:6707 e epsg:6708 nuovi sistemi da usare per la produzione
> dei dati a livello nazionale sono ad assi invertiti.
> Per cui temo che un GML espresso in epsg:6707 sarebbe analogamente
> visualizzato male (e quindi gestito male) dai software gis che non
> supportano l'inversione degli assi.
>
> Andrea.
>
> --
> -
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017

Re: [Gfoss] Visualizzazione dati espressi in sistemi di riferimento ad assi invertiti

2017-11-04 Per discussione Andrea Peri
In effetti e' un workaround interessante e valido .
Grazie.

A.


Il giorno 3 novembre 2017 09:20, Paolo Craveri  ha
scritto:

> non so se può essere utile
>
> https://trac.osgeo.org/gdal/wiki/FAQVector#HowdoIflipcoordinateswhentheya
> renotintheexpectedorder
>
> in pratica:
>
> ogr2ogr -dialect SQLite -sql "SELECT SwapCoordinates(geometry) AS
> geometry, * FROM source" dest.shp source.shp
>
>
>
> ciao
>
> Il giorno 2 novembre 2017 09:01, Luca Delucchi  ha
> scritto:
>
>> 2017-11-02 8:58 GMT+01:00 Andrea Peri :
>> > Salve,
>>
>> Ciao Andrea,
>>
>> > l'argomento mio riguarderebbe QGIS, ma penso che in realta' abbia una
>> > valenza piu' larga perche' sospetto che il problema possa essere
>> presente
>> > anche in altri prodotti.
>> >
>> > In soldoni:
>> > mi sono scaricato dal portale nazionale un dataset italiano in
>> epsg:4326 e
>> > in formato GML.
>> >
>>
>> potresti mandare il link così provo su GRASS?
>>
>> > Andrea.
>> >
>>
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>> ___
>> Gfoss@lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 801 iscritti al 19/07/2017
>>
>
>
>
> --
> --
> Paolo Craveri
>



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
801 iscritti al 19/07/2017