Gfoss -- Geographic Free and Open Source Software - Italian mailing list

Editing in PostGIS

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Andrea Peri

Editing in PostGIS

>Mi sembra un caso d'uso molto comune.
>Quale pensi possa essere un comportamento migliore ?
>
>Immagino che assegnare un nuovo id potrebbe farti perdere di vista i
>componenti risultanti dallo split.

E' un problema concettualmente particolare.

A mio parere il sezionamento dovrebbe generare una multigeometria.
Avrebbe la sua logica, e non impatterebbe sulla chiave primaria.

Pero' se la tabella non e' multigeometria questo non è possibile.
E poi se si va a tagliare un quadrato in due generando una multigeometria, si ottiene una geometria invalida . :(

Non è facile trovare un comportamento generalizzabile.

La scelta di mettere sempre un nuovo record e' probabilmente legata alla considerazione che e' un caso piu' generalizzabile. Infatti cade solamente in presenza di una PK autoincrementante.
Se siamo in una tale situazione, pero' non vedo altra soluzione che non quella di generare da codice un nuovo record e popolarlo.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

Luca Lanteri-3

Re: Editing in PostGIS

Quando un utente divide la gemetria in 2 parti è per assegnarli un significato (e quindi un attributo) diverso, quindi la multigeometria non è una soluzione valida.

A me pare un caso uso talmente comune che mi mette in crisi doverlo gestire. Se qgis vuole, giustamente, un gid univoco per ogni geometria, non dovrebbe generarne uno anche quando divide le geometrie visto che a tutti gli effetti ne genera una nuova. O forse già lo fa ma sbaglio io in qualcosa ?

Il giorno 19 aprile 2012 11:57, Andrea Peri <[hidden email]> ha scritto:

>Mi sembra un caso d'uso molto comune.
>Quale pensi possa essere un comportamento migliore ?
>
>Immagino che assegnare un nuovo id potrebbe farti perdere di vista i
>componenti risultanti dallo split. 
E' un problema concettualmente particolare.

A mio parere il sezionamento dovrebbe generare una multigeometria.
Avrebbe la sua logica, e non impatterebbe sulla chiave primaria.

Pero' se la tabella non e' multigeometria questo non è possibile.
E poi se si va a tagliare un quadrato in due generando una multigeometria, si ottiene una geometria invalida . :(

Non è facile trovare un comportamento generalizzabile.

La scelta di mettere sempre un nuovo record e' probabilmente legata alla considerazione che e' un caso piu' generalizzabile. Infatti cade solamente in presenza di una PK autoincrementante.
Se siamo in una tale situazione, pero' non vedo altra soluzione che non quella di generare da codice un nuovo record e popolarlo.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

giohappy

Re: Editing in PostGIS

Il problema è che, anche ipotizzando il caso più generale della creazione di una nuova feature (come ora avviene), non è banale definire il nuovo id.

Immagino che l'unico modo robusto sarebbe delegare la cosa ai provider, che dovrebbero esporre un proprio metodo per ottenere un nuovo gid. Ad es. nel caso di una vista PostGIS e di un gid autoincrementante, il provider dovrebbe interrogare il currval() per sapere il prossimo id disponibile.

giovanni

Il giorno 19 aprile 2012 12:48, Luca Lanteri <[hidden email]> ha scritto:

Quando un utente divide la gemetria in 2 parti è per assegnarli un significato (e quindi un attributo) diverso, quindi la multigeometria non è una soluzione valida.
A me pare un caso uso talmente comune che mi mette in crisi doverlo gestire. Se qgis vuole, giustamente, un gid univoco per ogni geometria, non dovrebbe generarne uno anche quando divide le geometrie visto che a tutti gli effetti ne genera una nuova. O forse già lo fa ma sbaglio io in qualcosa ?
Il giorno 19 aprile 2012 11:57, Andrea Peri <[hidden email]> ha scritto:
>Mi sembra un caso d'uso molto comune.
>Quale pensi possa essere un comportamento migliore ?
>
>Immagino che assegnare un nuovo id potrebbe farti perdere di vista i
>componenti risultanti dallo split. 
E' un problema concettualmente particolare.

A mio parere il sezionamento dovrebbe generare una multigeometria.
Avrebbe la sua logica, e non impatterebbe sulla chiave primaria.

Pero' se la tabella non e' multigeometria questo non è possibile.
E poi se si va a tagliare un quadrato in due generando una multigeometria, si ottiene una geometria invalida . :(

Non è facile trovare un comportamento generalizzabile.

La scelta di mettere sempre un nuovo record e' probabilmente legata alla considerazione che e' un caso piu' generalizzabile. Infatti cade solamente in presenza di una PK autoincrementante.
Se siamo in una tale situazione, pero' non vedo altra soluzione che non quella di generare da codice un nuovo record e popolarlo.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

Paolo Corti

Re: Editing in PostGIS

2012/4/19 G. Allegri <[hidden email]>:
> Il problema è che, anche ipotizzando il caso più generale della creazione di
> una nuova feature (come ora avviene), non è banale definire il nuovo id.
> Immagino che l'unico modo robusto sarebbe delegare la cosa ai provider, che
> dovrebbero esporre un proprio metodo per ottenere un nuovo gid. Ad es. nel
> caso di una vista PostGIS e di un gid autoincrementante, il provider
> dovrebbe interrogare il currval() per sapere il prossimo id disponibile.

No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
l'implementazione (corretta) e' richiedere l'id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.

Se si divide un poligono, e' vero che i due poligoni hanno uno stesso
id, ma questo avviene fino al momento del commit, dopo il commit uno dei due
conserva l'id iniziale, l'altro ottiene il progressivo da PostGIS.

Tra l'altro non e' nemmeno (ovviamente) possibile modificare
manualmente l'id, essendo gestito con un serial.

ciao
p

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

Luca Lanteri-3

Re: Editing in PostGIS

Quando commito mi restituisce l'errore:

1 feature(s) not added.

Provider errors:

PostGIS error while adding features: duplicate key violates unique costraint conoidi_piemonte_pkey

Il giorno 19 aprile 2012 14:57, Paolo Corti <[hidden email]> ha scritto:

2012/4/19 Luca Lanteri <[hidden email]>:

>>
> mmm... allora non mi torna qualcosa, perche anch'io mi aspetterei il
> comportamento che dici tu invece non è così:
> questa è la mia tavola
>
> CREATE TABLE conoidi.conoidi
> (
> gid serial NOT NULL,
> id_conoide integer,
> tipo double precision,
> poligenico character varying(4),
> valanga character varying(4),
> corsoacqua character varying(50),
> the_geom geometry,
> modifica integer,
> autore_modifica character varying(50),
> area integer,
> fonte integer,
> cod_macrobacino character varying(10),
> CONSTRAINT conoidi_piemonte_pkey PRIMARY KEY (gid),
> CONSTRAINT enforce_dims_the_geom CHECK (st_ndims(the_geom) = 2),
> CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) =
> 'POLYGON'::text OR the_geom IS NULL),
> CONSTRAINT enforce_srid_the_geom CHECK (st_srid(the_geom) = 32632)
>
> quando inserico un nuovo record nel campo gid ritrovo, giustamente:
> nextval('conoidi.conoidi_gid_seq'::regclass) essendo il valore di default
>
> quando faccio uno split, no! sulle nuove geometrie create il gid rimane
> quello vecchio per entrambe i poligoni. Inserendolo a mano tutto funziona ma
> ritorno nel problema di prima.
>
>

si ma non hai committato le modifiche (e quindi non hai interrogato
PostGIS per ottenere il nuovo id). Se chiudi la sessione di editing e
riguardi gli id, vedrai che tutto torna ;)

ciao
p

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti

giohappy

Re: Editing in PostGIS

In reply to this post by Paolo Corti

No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
l'implementazione (corretta) e' richiedere l'id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.

Intendevo dire questo Paolo.

Però, cito la descrizione iniziale del problema:

> Quando faccio un nuovo inserimento funziona tutto
> ma se divido un poligono già esistente in più parti con la funzione "Split
> feature" il valore di gid viene assegnato ad entrambe i nuovi poligoni.
> Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
> posso più salvare fino a quando non assegno manualmente un nuovo valore al
> campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
> inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
> cornuto e mazziato!

Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l'id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all'originale...

Forse non ho capito il problema?

giovanni

[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921

ciao
p

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti

Luca Lanteri-3

Re: Editing in PostGIS

Acc... forse si svela l'arcano: sto usando la Master 1.9.0.117

Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema limitato sulla versione di sviluppo.

Il giorno 19 aprile 2012 15:03, G. Allegri <[hidden email]> ha scritto:

No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
l'implementazione (corretta) e' richiedere l'id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.

Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:

> Quando faccio un nuovo inserimento funziona tutto
> ma se divido un poligono già esistente in più parti con la funzione "Split
> feature" il valore di gid viene assegnato ad entrambe i nuovi poligoni.
> Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
> posso più salvare fino a quando non assegno manualmente un nuovo valore al
> campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
> inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
> cornuto e mazziato!

Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l'id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all'originale...
Forse non ho capito il problema?

giovanni

[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921

ciao
p

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti

giohappy

Re: Editing in PostGIS

Confermo, ho appena riprodotto l'errore. Vado a vedere cos'è cambiato a livello di codice...

giovanni

Il giorno 19 aprile 2012 15:08, Luca Lanteri <[hidden email]> ha scritto:

Acc... forse si svela l'arcano: sto usando la Master 1.9.0.117
Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema limitato sulla versione di sviluppo.

Il giorno 19 aprile 2012 15:03, G. Allegri <[hidden email]> ha scritto:

No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
l'implementazione (corretta) e' richiedere l'id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.

Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:

> Quando faccio un nuovo inserimento funziona tutto
> ma se divido un poligono già esistente in più parti con la funzione "Split
> feature" il valore di gid viene assegnato ad entrambe i nuovi poligoni.
> Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
> posso più salvare fino a quando non assegno manualmente un nuovo valore al
> campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
> inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
> cornuto e mazziato!

Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l'id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all'originale...
Forse non ho capito il problema?

giovanni

[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921

ciao
p

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti

Luca Lanteri-3

Re: Editing in PostGIS

Ok, allora verifichi tu direttamente. Non è necessario aprire un ticket.
Grazie mille come al solito a tutti dell'aiuto tempestivo.

Luca

Il giorno 19 aprile 2012 15:13, G. Allegri <[hidden email]> ha scritto:

Confermo, ho appena riprodotto l'errore. Vado a vedere cos'è cambiato a livello di codice...

giovanni

Il giorno 19 aprile 2012 15:08, Luca Lanteri <[hidden email]> ha scritto:

Acc... forse si svela l'arcano: sto usando la Master 1.9.0.117
Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema limitato sulla versione di sviluppo.

Il giorno 19 aprile 2012 15:03, G. Allegri <[hidden email]> ha scritto:

No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
l'implementazione (corretta) e' richiedere l'id incrementale al provider
al momento del commit, altrimenti si rischiano conflitti.

Intendevo dire questo Paolo.
Però, cito la descrizione iniziale del problema:

> Quando faccio un nuovo inserimento funziona tutto
> ma se divido un poligono già esistente in più parti con la funzione "Split
> feature" il valore di gid viene assegnato ad entrambe i nuovi poligoni.
> Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
> posso più salvare fino a quando non assegno manualmente un nuovo valore al
> campo gid. Facendo così la sequence non sia aggiorna ed al prossimo nuovo
> inserimento mi trovo di nuovo con il gid duplicato. Insomma come si dice
> cornuto e mazziato!

Dal codice mi sembra di capire che Qgis fornisce un id temporaneo negativo [1], e poi delega l'id definitivo a PostGIS, quindi non capisco perché lui ottenga un gid uguale all'originale...
Forse non ho capito il problema?

giovanni

[1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921

ciao
p

--
Paolo Corti
Geospatial software developer
web: http://www.paolocorti.net
twitter: @capooti
skype: capooti

Giuseppe Sucameli

Re: Editing in PostGIS

Ciao Luca,

2012/4/20 Luca Lanteri <[hidden email]>:
> Ok, allora verifichi tu direttamente. Non è necessario aprire un ticket.

se il problema e' confermato e' bene aprire un ticket.

In questo modo si tiene traccia del problema, si evita che venga
dimenticato e soprattutto si evita che piu' persone spendano tempo
a correggere lo stesso identico problema.

Saluti.

> Grazie mille come al solito a tutti dell'aiuto tempestivo.
>
> Luca
>
> Il giorno 19 aprile 2012 15:13, G. Allegri <[hidden email]> ha scritto:
>
>> Confermo, ho appena riprodotto l'errore. Vado a vedere cos'è cambiato a
>> livello di codice...
>>
>> giovanni
>>
>> Il giorno 19 aprile 2012 15:08, Luca Lanteri <[hidden email]> ha
>> scritto:
>>
>>> Acc... forse si svela l'arcano: sto usando la Master 1.9.0.117
>>> Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema
>>> limitato sulla versione di sviluppo.
>>>
>>>
>>> Il giorno 19 aprile 2012 15:03, G. Allegri <[hidden email]> ha
>>> scritto:
>>>
>>>>> No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
>>>>> l'implementazione (corretta) e' richiedere l'id incrementale al
>>>>> provider
>>>>> al momento del commit, altrimenti si rischiano conflitti.
>>>>
>>>>
>>>> Intendevo dire questo Paolo.
>>>> Però, cito la descrizione iniziale del problema:
>>>>
>>>> > Quando faccio un nuovo inserimento funziona tutto
>>>> > ma se divido un poligono già esistente in più parti con la funzione
>>>> > "Split
>>>> > feature" il valore di gid viene assegnato ad entrambe i nuovi
>>>> > poligoni.
>>>> > Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
>>>> > posso più salvare fino a quando non assegno manualmente un nuovo
>>>> > valore al
>>>> > campo gid. Facendo così la sequence non sia aggiorna ed al prossimo
>>>> > nuovo
>>>> > inserimento mi trovo di nuovo con il gid duplicato. Insomma come si
>>>> > dice
>>>> > cornuto e mazziato!
>>>>
>>>> Dal codice mi sembra di capire che Qgis fornisce un id temporaneo
>>>> negativo [1], e poi delega l'id definitivo a PostGIS, quindi non capisco
>>>> perché lui ottenga un gid uguale all'originale...
>>>> Forse non ho capito il problema?
>>>>
>>>> giovanni
>>>>
>>>>
>>>> [1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
>>>>
>>>>>
>>>>> ciao
>>>>> p
>>>>>
>>>>> --
>>>>> Paolo Corti
>>>>> Geospatial software developer
>>>>> web: http://www.paolocorti.net
>>>>> twitter: @capooti
>>>>> skype: capooti
>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 584 iscritti al 7.4.2012

--
Giuseppe Sucameli
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

Luca Lanteri-3

Re: Editing in PostGIS

ok, allora provvedo.

Grazie

^L^

Il giorno 20 aprile 2012 12:06, Giuseppe Sucameli <[hidden email]> ha scritto:

Ciao Luca,

2012/4/20 Luca Lanteri <[hidden email]>:

> Ok, allora verifichi tu direttamente. Non è necessario aprire un ticket.

se il problema e' confermato e' bene aprire un ticket.

In questo modo si tiene traccia del problema, si evita che venga
dimenticato e soprattutto si evita che piu' persone spendano tempo
a correggere lo stesso identico problema.

Saluti.

> Grazie mille come al solito a tutti dell'aiuto tempestivo.
>
> Luca
>
> Il giorno 19 aprile 2012 15:13, G. Allegri <[hidden email]> ha scritto:
>
>> Confermo, ho appena riprodotto l'errore. Vado a vedere cos'è cambiato a
>> livello di codice...
>>
>> giovanni
>>
>> Il giorno 19 aprile 2012 15:08, Luca Lanteri <[hidden email]> ha
>> scritto:
>>
>>> Acc... forse si svela l'arcano: sto usando la Master 1.9.0.117
>>> Ho provato sulla 1.7.4 e tutto funziona. Si tratta di un problema
>>> limitato sulla versione di sviluppo.
>>>
>>>
>>> Il giorno 19 aprile 2012 15:03, G. Allegri <[hidden email]> ha
>>> scritto:
>>>
>>>>> No, in realta' (ed ho anche verficato che e' effettivamente cosi'),
>>>>> l'implementazione (corretta) e' richiedere l'id incrementale al
>>>>> provider
>>>>> al momento del commit, altrimenti si rischiano conflitti.
>>>>
>>>>
>>>> Intendevo dire questo Paolo.
>>>> Però, cito la descrizione iniziale del problema:
>>>>
>>>> > Quando faccio un nuovo inserimento funziona tutto
>>>> > ma se divido un poligono già esistente in più parti con la funzione
>>>> > "Split
>>>> > feature" il valore di gid viene assegnato ad entrambe i nuovi
>>>> > poligoni.
>>>> > Ovviamente a questo punto ho la chiave primaria duplicata e quindi non
>>>> > posso più salvare fino a quando non assegno manualmente un nuovo
>>>> > valore al
>>>> > campo gid. Facendo così la sequence non sia aggiorna ed al prossimo
>>>> > nuovo
>>>> > inserimento mi trovo di nuovo con il gid duplicato. Insomma come si
>>>> > dice
>>>> > cornuto e mazziato!
>>>>
>>>> Dal codice mi sembra di capire che Qgis fornisce un id temporaneo
>>>> negativo [1], e poi delega l'id definitivo a PostGIS, quindi non capisco
>>>> perché lui ottenga un gid uguale all'originale...
>>>> Forse non ho capito il problema?
>>>>
>>>> giovanni
>>>>
>>>>
>>>> [1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsvectorlayer.cpp#L1921
>>>>
>>>>>
>>>>> ciao
>>>>> p
>>>>>
>>>>> --
>>>>> Paolo Corti
>>>>> Geospatial software developer
>>>>> web: http://www.paolocorti.net
>>>>> twitter: @capooti
>>>>> skype: capooti
>>>>
>>>>
>>>
>>
>
>

> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> Non inviate messaggi commerciali.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
> 584 iscritti al 7.4.2012

--
Giuseppe Sucameli