[Gfoss] QGis e vista PostGIS

fauleman · February 2, 2014, 8:47pm

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

Luca_Mandolesi · February 2, 2014, 9:23pm

La sparo lì che in questi giorni stiamo proprio analizzando un baco che ha Qgis 2 nella lettura di postgis.

nella view geometry_columns hai l’srdid settato correttamente o ti appare uno 0?
c’è in ballo un multipolygon?

···

2014-02-02 Marco Li Volsi <marco.livolsi@gmail.com>:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

Andrea_Peri · February 2, 2014, 9:43pm

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

···

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

fauleman · February 2, 2014, 9:51pm

Buona Sera Luca. Grazie della risposta.
In geometry_columns l'srid è correttamente impostato (4326) e la tabella contiene dei semplici POINT.
Boh!
Saluti.

Il 02/02/2014 22:23, Luca Mandolesi ha scritto:

La sparo lì che in questi giorni stiamo proprio analizzando un baco che ha Qgis 2 nella lettura di postgis.
- nella view geometry_columns hai l'srdid settato correttamente o ti appare uno 0?
- c'è in ballo un multipolygon?

2014-02-02 Marco Li Volsi <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>>:

    Buona sera a tutti Voi.
    Ho un comportamento molto strano riguardo al caricamento di una
    vista geografica su PostGIS.
    Ho creato una vista su PostGIS del tipo
    CREATE OR REPLACE VIEW vista1
        SELECT tabella1.campo1, tabella2.campo2,tabella1.campo2,...,
    tabella1.campogeometrico
        FROM tabella1
        LEFT JOIN tabella2 ON ...
        WHERE tabella1.campo2 = valore;
    La vista viene correttamente trovata nella vista geometry_columns.
    Ho provato a caricare questo layer dal tasto "Aggiungi vettore
    PostGIS" e mi viene restituito un messaggio di alert. Verificando
    il registro degli eventi il layer risulta non valido. Se provo a
    caricare il layer dal DB Manager tutto va come deve andare.
    Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS="2.0.1
    r9979" GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel. 4.8.0, 6 March 2012"
    GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.8" RASTER.
    Qualcuno saprebbe dirmi se sbaglio qualcosa?

    _______________________________________________
    Gfoss@lists.gfoss.it <mailto: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.
    666 iscritti al 22.7.2013

Luca_Mandolesi · February 2, 2014, 9:54pm

Mi piacerebbe cmq avere lumi dai guru di qgis sui differenti comportamenti di DBmanager e del provider postgis di QGis.
Io al momento ho problemi con tabelle che non avevano SRID settato correttamente e nel provider di Qgis apparivano come SRID 0. A quel punto il multiplygon veniva caricato come un polygon e l’editing non era più possibile. Forse il consiglio di Andrea peri coglie nel segno! Facci sapere!
Ciao
Luca

···

2014-02-02 Marco Li Volsi <marco.livolsi@gmail.com>:

Buona Sera Luca. Grazie della risposta.
In geometry_columns l’srid è correttamente impostato (4326) e la tabella contiene dei semplici POINT.
Boh!
Saluti.

Il 02/02/2014 22:23, Luca Mandolesi ha scritto:

La sparo lì che in questi giorni stiamo proprio analizzando un baco che ha Qgis 2 nella lettura di postgis.

nella view geometry_columns hai l’srdid settato correttamente o ti appare uno 0?

c’è in ballo un multipolygon?

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.
666 iscritti al 22.7.2013

2014-02-02 Marco Li Volsi <marco.livolsi@gmail.com>:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

fauleman · February 2, 2014, 9:58pm

Grazie Andrea... ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

.., tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha scritto:

    Buona sera a tutti Voi.
    Ho un comportamento molto strano riguardo al caricamento di una
    vista geografica su PostGIS.
    Ho creato una vista su PostGIS del tipo
    CREATE OR REPLACE VIEW vista1
        SELECT tabella1.campo1, tabella2.campo2,tabella1.campo2,...,
    tabella1.campogeometrico
        FROM tabella1
        LEFT JOIN tabella2 ON ...
        WHERE tabella1.campo2 = valore;
    La vista viene correttamente trovata nella vista geometry_columns.
    Ho provato a caricare questo layer dal tasto "Aggiungi vettore
    PostGIS" e mi viene restituito un messaggio di alert. Verificando
    il registro degli eventi il layer risulta non valido. Se provo a
    caricare il layer dal DB Manager tutto va come deve andare.
    Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS="2.0.1
    r9979" GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel. 4.8.0, 6 March 2012"
    GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.8" RASTER.
    Qualcuno saprebbe dirmi se sbaglio qualcosa?

    _______________________________________________
    Gfoss@lists.gfoss.it <mailto: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.
    666 iscritti al 22.7.2013

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

Andrea_Peri · February 2, 2014, 10:10pm

ok.

Un altro suggerimento:

qgis per il postgres vole disporre di un campo che sia di tipo intero e con una primary-key.
Oppure con un indice di tipo unique.

Verifica che questa condizione sia verificata su uno dei campi che definisci nella vista.
Stai attento che la condizione LEFTJOIN potrebbe falsare questa consizione provocando la ripetizione di records.

···

Il giorno 02 febbraio 2014 22:58, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Grazie Andrea… ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

Luca_Mandolesi · February 2, 2014, 10:14pm

Mi ha battuto sul tempo Andrea… io nelle mie view setto sempre la query con Join per evitare tale problema. Se ad un punto corrispondo più record della tabella alfanumerica, puoi provare a dare dentro al provider di postgis come id singolo la chiave primaria e quindi unica della tabella 2.

···

2014-02-02 Andrea Peri <aperi2007@gmail.com>:

ok.

Un altro suggerimento:

qgis per il postgres vole disporre di un campo che sia di tipo intero e con una primary-key.
Oppure con un indice di tipo unique.

Verifica che questa condizione sia verificata su uno dei campi che definisci nella vista.
Stai attento che la condizione LEFTJOIN potrebbe falsare questa consizione provocando la ripetizione di records.

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.
666 iscritti al 22.7.2013

Il giorno 02 febbraio 2014 22:58, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Grazie Andrea… ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

lrssvt · February 2, 2014, 10:30pm

Ciao,

Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode

···

2014-02-02 Marco Li Volsi <marco.livolsi@gmail.com>:

Buona sera a tutti Voi.

Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido.

puoi riportare il messaggio esatto che vedi nel log?

E se il log ci dice poco, puoi creare un testcase per riprodurre l’eventuale anomalia?

Ho appena provato a creare una vista (usando il tuo esempio) con i miei dati e funziona bene.

Saluti,

-SL

Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

fauleman · February 2, 2014, 10:47pm

Ciao Ragà.
La tabella "LEFT" ha un campo id numerico di tipo bigint ed ha una constraint di PRIMARY KEY.
Per quanto riguarda le varie LEFT JOIN, non fanno altro che collegare chiavi primarie delle tabelle "RIGHT" con le chiavi esterne nella tabella "LEFT".
Ho fatto eseguire sulla vista la seguente query e non ha dato conteggi maggiori di 1.
SELECT id, COUNT(id)
FROM v_poi_airport
GROUP BY id
ORDER BY COUNT(id) DESC;

Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

Mi ha battuto sul tempo Andrea... io nelle mie view setto sempre la query con Join per evitare tale problema. Se ad un punto corrispondo più record della tabella alfanumerica, puoi provare a dare dentro al provider di postgis come id singolo la chiave primaria e quindi unica della tabella 2.

2014-02-02 Andrea Peri <aperi2007@gmail.com <mailto:aperi2007@gmail.com>>:

    ok.

    Un altro suggerimento:

    qgis per il postgres vole disporre di un campo che sia di tipo
    intero e con una primary-key.
    Oppure con un indice di tipo unique.
    Verifica che questa condizione sia verificata su uno dei campi che
    definisci nella vista.
    Stai attento che la condizione LEFTJOIN potrebbe falsare questa
    consizione provocando la ripetizione di records.

    Il giorno 02 febbraio 2014 22:58, Marco Li Volsi
    <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha
    scritto:

        Grazie Andrea... ho provato ma non funge

        Il 02/02/2014 22:43, Andrea Peri ha scritto:

        Prova a modificare la view definendo la geometria in quesot modo:

        .., tabella1.campogeometrico::geometry(Geometry, 3003) As geom

        Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga,
        se è utm usa 25832 o altro codice epsg.

        Il giorno 02 febbraio 2014 21:47, Marco Li Volsi
        <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha
        scritto:

            Buona sera a tutti Voi.
            Ho un comportamento molto strano riguardo al caricamento
            di una vista geografica su PostGIS.
            Ho creato una vista su PostGIS del tipo
            CREATE OR REPLACE VIEW vista1
                SELECT tabella1.campo1,
            tabella2.campo2,tabella1.campo2,..., tabella1.campogeometrico
                FROM tabella1
                LEFT JOIN tabella2 ON ...
                WHERE tabella1.campo2 = valore;
            La vista viene correttamente trovata nella vista
            geometry_columns.
            Ho provato a caricare questo layer dal tasto "Aggiungi
            vettore PostGIS" e mi viene restituito un messaggio di
            alert. Verificando il registro degli eventi il layer
            risulta non valido. Se provo a caricare il layer dal DB
            Manager tutto va come deve andare.
            Il sistema in questione è QGIS 2.0.1-Dufour e
            POSTGIS="2.0.1 r9979" GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel.
            4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released
            2012/10/08" LIBXML="2.7.8" RASTER.
            Qualcuno saprebbe dirmi se sbaglio qualcosa?

            _______________________________________________
            Gfoss@lists.gfoss.it <mailto: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.
            666 iscritti al 22.7.2013

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

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

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

    _______________________________________________
    Gfoss@lists.gfoss.it <mailto: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.
    666 iscritti al 22.7.2013

Andrea_Peri · February 2, 2014, 11:00pm

A quello che ricordo, la regola di qgis è un campo di tipo int4 e bigint non gli va bene.

Inoltre il campo deve essere presente tra quelli esposti nella vista, probabilmente lo è, ma dalla tua risposta sembrerebbe che esso è presente nella tabella LEFT non è in output sulla vista.

In ogni caso almeno fino a qgis 1.8 sicuramente un campo bigint non gli sarebbe andato bene.
Non so se con qgis 2 è cambiato qualcosa, ma non credo…

qgis vuole tra i campi esposti in output nella vista un campo di tipo int4 con valori univoci e un indice unique (una pk va benissimo)

A.

···

Il giorno 02 febbraio 2014 23:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Ragà.
La tabella “LEFT” ha un campo id numerico di tipo bigint ed ha una constraint di PRIMARY KEY.
Per quanto riguarda le varie LEFT JOIN, non fanno altro che collegare chiavi primarie delle tabelle “RIGHT” con le chiavi esterne nella tabella “LEFT”.
Ho fatto eseguire sulla vista la seguente query e non ha dato conteggi maggiori di 1.
SELECT id, COUNT(id)
FROM v_poi_airport
GROUP BY id
ORDER BY COUNT(id) DESC;

Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

Mi ha battuto sul tempo Andrea… io nelle mie view setto sempre la query con Join per evitare tale problema. Se ad un punto corrispondo più record della tabella alfanumerica, puoi provare a dare dentro al provider di postgis come id singolo la chiave primaria e quindi unica della tabella 2.

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.
666 iscritti al 22.7.2013

–

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

2014-02-02 Andrea Peri <aperi2007@gmail.com>:

ok.

Un altro suggerimento:

qgis per il postgres vole disporre di un campo che sia di tipo intero e con una primary-key.
Oppure con un indice di tipo unique.

Verifica che questa condizione sia verificata su uno dei campi che definisci nella vista.
Stai attento che la condizione LEFTJOIN potrebbe falsare questa consizione provocando la ripetizione di records.

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.
666 iscritti al 22.7.2013

Il giorno 02 febbraio 2014 22:58, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Grazie Andrea… ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

fauleman · February 2, 2014, 11:10pm

Il campo PRIMARY KEY (... quello bigint per intenderci) è presente sulla vista, purtroppo ho proprio bisogno di un bigint... mi sono arrivati questi id interi composti da 14 cifre. La tua risposta è coerente... rimane il dubbio del perchè funzioni con DB Manager ?

Il 03/02/2014 00:00, Andrea Peri ha scritto:

A quello che ricordo, la regola di qgis è un campo di tipo int4 e bigint non gli va bene.
Inoltre il campo deve essere presente tra quelli esposti nella vista, probabilmente lo è, ma dalla tua risposta sembrerebbe che esso è presente nella tabella LEFT non è in output sulla vista.

In ogni caso almeno fino a qgis 1.8 sicuramente un campo bigint non gli sarebbe andato bene.
Non so se con qgis 2 è cambiato qualcosa, ma non credo..

qgis vuole tra i campi esposti in output nella vista un campo di tipo int4 con valori univoci e un indice unique (una pk va benissimo)

A.

Il giorno 02 febbraio 2014 23:47, Marco Li Volsi <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha scritto:

    Ciao Ragà.
    La tabella "LEFT" ha un campo id numerico di tipo bigint ed ha una
    constraint di PRIMARY KEY.
    Per quanto riguarda le varie LEFT JOIN, non fanno altro che
    collegare chiavi primarie delle tabelle "RIGHT" con le chiavi
    esterne nella tabella "LEFT".
    Ho fatto eseguire sulla vista la seguente query e non ha dato
    conteggi maggiori di 1.
    SELECT id, COUNT(id)
      FROM v_poi_airport
     GROUP BY id
    ORDER BY COUNT(id) DESC;

    Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

    Mi ha battuto sul tempo Andrea... io nelle mie view setto sempre
    la query con Join per evitare tale problema. Se ad un punto
    corrispondo più record della tabella alfanumerica, puoi provare a
    dare dentro al provider di postgis come id singolo la chiave
    primaria e quindi unica della tabella 2.

    2014-02-02 Andrea Peri <aperi2007@gmail.com
    <mailto:aperi2007@gmail.com>>:

        ok.

        Un altro suggerimento:

        qgis per il postgres vole disporre di un campo che sia di
        tipo intero e con una primary-key.
        Oppure con un indice di tipo unique.
        Verifica che questa condizione sia verificata su uno dei
        campi che definisci nella vista.
        Stai attento che la condizione LEFTJOIN potrebbe falsare
        questa consizione provocando la ripetizione di records.

        Il giorno 02 febbraio 2014 22:58, Marco Li Volsi
        <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha
        scritto:

            Grazie Andrea... ho provato ma non funge

            Il 02/02/2014 22:43, Andrea Peri ha scritto:

            Prova a modificare la view definendo la geometria in
            quesot modo:

            .., tabella1.campogeometrico::geometry(Geometry, 3003)
            As geom

            Io ho scritto 3003 ipotizzando che il dato sia in
            GaussBoaga, se è utm usa 25832 o altro codice epsg.

            Il giorno 02 febbraio 2014 21:47, Marco Li Volsi
            <marco.livolsi@gmail.com
            <mailto:marco.livolsi@gmail.com>> ha scritto:

                Buona sera a tutti Voi.
                Ho un comportamento molto strano riguardo al
                caricamento di una vista geografica su PostGIS.
                Ho creato una vista su PostGIS del tipo
                CREATE OR REPLACE VIEW vista1
                    SELECT tabella1.campo1,
                tabella2.campo2,tabella1.campo2,...,
                tabella1.campogeometrico
                    FROM tabella1
                    LEFT JOIN tabella2 ON ...
                    WHERE tabella1.campo2 = valore;
                La vista viene correttamente trovata nella vista
                geometry_columns.
                Ho provato a caricare questo layer dal tasto
                "Aggiungi vettore PostGIS" e mi viene restituito un
                messaggio di alert. Verificando il registro degli
                eventi il layer risulta non valido. Se provo a
                caricare il layer dal DB Manager tutto va come deve
                andare.
                Il sistema in questione è QGIS 2.0.1-Dufour e
                POSTGIS="2.0.1 r9979" GEOS="3.3.3-CAPI-1.7.4"
                PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2,
                released 2012/10/08" LIBXML="2.7.8" RASTER.
                Qualcuno saprebbe dirmi se sbaglio qualcosa?

                _______________________________________________
                Gfoss@lists.gfoss.it <mailto: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.
                666 iscritti al 22.7.2013

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

            _______________________________________________
            Gfoss@lists.gfoss.it <mailto: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.
            666 iscritti al 22.7.2013

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

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

    _______________________________________________
    Gfoss@lists.gfoss.it <mailto: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.
    666 iscritti al 22.7.2013

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

Andrea_Peri · February 2, 2014, 11:32pm

Su db-manager non so che dirti.

Pero’ puoi fare una controprova.

definisci sulla tabella principale un campo di tipo “serial” il quale si auto-riempira’ con dei progressivi.

alter table tabella1 add column id_2 serial;

definisci su tale colonna un indice unique:

create unique index idx-1 on tabella1(id_2);

Poi ridefinisci la vista aggiungendovi tale campo nuovo.

E infine prova a riaggiungere la vista a qgis.

A quel punto qgis trova il campo di tipo int4 che cercava con tantodi indice unique e se accetta di aggiungerla alla canvas, almeno
hai trovato dove sta’ il problema.
Altrimenti è da una altra parte.

A.

···

Il giorno 03 febbraio 2014 00:10, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Il campo PRIMARY KEY (… quello bigint per intenderci) è presente sulla vista, purtroppo ho proprio bisogno di un bigint… mi sono arrivati questi id interi composti da 14 cifre. La tua risposta è coerente… rimane il dubbio del perchè funzioni con DB Manager ?

Il 03/02/2014 00:00, Andrea Peri ha scritto:

A quello che ricordo, la regola di qgis è un campo di tipo int4 e bigint non gli va bene.

Inoltre il campo deve essere presente tra quelli esposti nella vista, probabilmente lo è, ma dalla tua risposta sembrerebbe che esso è presente nella tabella LEFT non è in output sulla vista.

In ogni caso almeno fino a qgis 1.8 sicuramente un campo bigint non gli sarebbe andato bene.
Non so se con qgis 2 è cambiato qualcosa, ma non credo…

qgis vuole tra i campi esposti in output nella vista un campo di tipo int4 con valori univoci e un indice unique (una pk va benissimo)

A.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 23:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Ragà.
La tabella “LEFT” ha un campo id numerico di tipo bigint ed ha una constraint di PRIMARY KEY.
Per quanto riguarda le varie LEFT JOIN, non fanno altro che collegare chiavi primarie delle tabelle “RIGHT” con le chiavi esterne nella tabella “LEFT”.
Ho fatto eseguire sulla vista la seguente query e non ha dato conteggi maggiori di 1.
SELECT id, COUNT(id)
FROM v_poi_airport
GROUP BY id
ORDER BY COUNT(id) DESC;

Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

Mi ha battuto sul tempo Andrea… io nelle mie view setto sempre la query con Join per evitare tale problema. Se ad un punto corrispondo più record della tabella alfanumerica, puoi provare a dare dentro al provider di postgis come id singolo la chiave primaria e quindi unica della tabella 2.

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.
666 iscritti al 22.7.2013

–

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

2014-02-02 Andrea Peri <aperi2007@gmail.com>:

ok.

Un altro suggerimento:

qgis per il postgres vole disporre di un campo che sia di tipo intero e con una primary-key.
Oppure con un indice di tipo unique.

Verifica che questa condizione sia verificata su uno dei campi che definisci nella vista.
Stai attento che la condizione LEFTJOIN potrebbe falsare questa consizione provocando la ripetizione di records.

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.
666 iscritti al 22.7.2013

Il giorno 02 febbraio 2014 22:58, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Grazie Andrea… ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

fauleman · February 3, 2014, 6:54pm

Ciao Andrea.
Provato come dici tu... ma continua a dare errore.

Il 03/02/2014 00:32, Andrea Peri ha scritto:

Su db-manager non so che dirti.

Pero' puoi fare una controprova.

definisci sulla tabella principale un campo di tipo "serial" il quale si auto-riempira' con dei progressivi.

alter table tabella1 add column id_2 serial;

definisci su tale colonna un indice unique:

create unique index idx-1 on tabella1(id_2);

Poi ridefinisci la vista aggiungendovi tale campo nuovo.

E infine prova a riaggiungere la vista a qgis.
A quel punto qgis trova il campo di tipo int4 che cercava con tantodi indice unique e se accetta di aggiungerla alla canvas, almeno
hai trovato dove sta' il problema.
Altrimenti è da una altra parte.

A.

Il giorno 03 febbraio 2014 00:10, Marco Li Volsi <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha scritto:

    Il campo PRIMARY KEY (... quello bigint per intenderci) è presente
    sulla vista, purtroppo ho proprio bisogno di un bigint... mi sono
    arrivati questi id interi composti da 14 cifre. La tua risposta è
    coerente... rimane il dubbio del perchè funzioni con DB Manager ?

    Il 03/02/2014 00:00, Andrea Peri ha scritto:

    A quello che ricordo, la regola di qgis è un campo di tipo int4 e
    bigint non gli va bene.
    Inoltre il campo deve essere presente tra quelli esposti nella
    vista, probabilmente lo è, ma dalla tua risposta sembrerebbe che
    esso è presente nella tabella LEFT non è in output sulla vista.
    :)

    In ogni caso almeno fino a qgis 1.8 sicuramente un campo bigint
    non gli sarebbe andato bene.
    Non so se con qgis 2 è cambiato qualcosa, ma non credo..

    qgis vuole tra i campi esposti in output nella vista un campo di
    tipo int4 con valori univoci e un indice unique (una pk va benissimo)

    A.

    Il giorno 02 febbraio 2014 23:47, Marco Li Volsi
    <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha
    scritto:

        Ciao Ragà.
        La tabella "LEFT" ha un campo id numerico di tipo bigint ed
        ha una constraint di PRIMARY KEY.
        Per quanto riguarda le varie LEFT JOIN, non fanno altro che
        collegare chiavi primarie delle tabelle "RIGHT" con le chiavi
        esterne nella tabella "LEFT".
        Ho fatto eseguire sulla vista la seguente query e non ha dato
        conteggi maggiori di 1.
        SELECT id, COUNT(id)
          FROM v_poi_airport
         GROUP BY id
        ORDER BY COUNT(id) DESC;

        Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

        Mi ha battuto sul tempo Andrea... io nelle mie view setto
        sempre la query con Join per evitare tale problema. Se ad un
        punto corrispondo più record della tabella alfanumerica,
        puoi provare a dare dentro al provider di postgis come id
        singolo la chiave primaria e quindi unica della tabella 2.

        2014-02-02 Andrea Peri <aperi2007@gmail.com
        <mailto:aperi2007@gmail.com>>:

            ok.

            Un altro suggerimento:

            qgis per il postgres vole disporre di un campo che sia
            di tipo intero e con una primary-key.
            Oppure con un indice di tipo unique.
            Verifica che questa condizione sia verificata su uno dei
            campi che definisci nella vista.
            Stai attento che la condizione LEFTJOIN potrebbe falsare
            questa consizione provocando la ripetizione di records.

            Il giorno 02 febbraio 2014 22:58, Marco Li Volsi
            <marco.livolsi@gmail.com
            <mailto:marco.livolsi@gmail.com>> ha scritto:

                Grazie Andrea... ho provato ma non funge

                Il 02/02/2014 22:43, Andrea Peri ha scritto:

                Prova a modificare la view definendo la geometria
                in quesot modo:

                .., tabella1.campogeometrico::geometry(Geometry,
                3003) As geom

                Io ho scritto 3003 ipotizzando che il dato sia in
                GaussBoaga, se è utm usa 25832 o altro codice epsg.

                Il giorno 02 febbraio 2014 21:47, Marco Li Volsi
                <marco.livolsi@gmail.com
                <mailto:marco.livolsi@gmail.com>> ha scritto:

                    Buona sera a tutti Voi.
                    Ho un comportamento molto strano riguardo al
                    caricamento di una vista geografica su PostGIS.
                    Ho creato una vista su PostGIS del tipo
                    CREATE OR REPLACE VIEW vista1
                        SELECT tabella1.campo1,
                    tabella2.campo2,tabella1.campo2,...,
                    tabella1.campogeometrico
                        FROM tabella1
                        LEFT JOIN tabella2 ON ...
                        WHERE tabella1.campo2 = valore;
                    La vista viene correttamente trovata nella
                    vista geometry_columns.
                    Ho provato a caricare questo layer dal tasto
                    "Aggiungi vettore PostGIS" e mi viene
                    restituito un messaggio di alert. Verificando
                    il registro degli eventi il layer risulta non
                    valido. Se provo a caricare il layer dal DB
                    Manager tutto va come deve andare.
                    Il sistema in questione è QGIS 2.0.1-Dufour e
                    POSTGIS="2.0.1 r9979" GEOS="3.3.3-CAPI-1.7.4"
                    PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL
                    1.9.2, released 2012/10/08" LIBXML="2.7.8" RASTER.
                    Qualcuno saprebbe dirmi se sbaglio qualcosa?

                    _______________________________________________
                    Gfoss@lists.gfoss.it <mailto: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.
                    666 iscritti al 22.7.2013

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

                _______________________________________________
                Gfoss@lists.gfoss.it <mailto: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.
                666 iscritti al 22.7.2013

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

            _______________________________________________
            Gfoss@lists.gfoss.it <mailto: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.
            666 iscritti al 22.7.2013

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

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

    _______________________________________________
    Gfoss@lists.gfoss.it <mailto: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.
    666 iscritti al 22.7.2013

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

Andrea_Peri · February 3, 2014, 7:30pm

puoi postare l’errore che ti da’ ?

···

Il giorno 03 febbraio 2014 19:54, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Andrea.
Provato come dici tu… ma continua a dare errore.

Il 03/02/2014 00:32, Andrea Peri ha scritto:

Su db-manager non so che dirti.

Pero’ puoi fare una controprova.

definisci sulla tabella principale un campo di tipo “serial” il quale si auto-riempira’ con dei progressivi.

alter table tabella1 add column id_2 serial;

definisci su tale colonna un indice unique:

create unique index idx-1 on tabella1(id_2);

Poi ridefinisci la vista aggiungendovi tale campo nuovo.

E infine prova a riaggiungere la vista a qgis.

A quel punto qgis trova il campo di tipo int4 che cercava con tantodi indice unique e se accetta di aggiungerla alla canvas, almeno
hai trovato dove sta’ il problema.
Altrimenti è da una altra parte.

A.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 03 febbraio 2014 00:10, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Il campo PRIMARY KEY (… quello bigint per intenderci) è presente sulla vista, purtroppo ho proprio bisogno di un bigint… mi sono arrivati questi id interi composti da 14 cifre. La tua risposta è coerente… rimane il dubbio del perchè funzioni con DB Manager ?

Il 03/02/2014 00:00, Andrea Peri ha scritto:

A quello che ricordo, la regola di qgis è un campo di tipo int4 e bigint non gli va bene.

Inoltre il campo deve essere presente tra quelli esposti nella vista, probabilmente lo è, ma dalla tua risposta sembrerebbe che esso è presente nella tabella LEFT non è in output sulla vista.

In ogni caso almeno fino a qgis 1.8 sicuramente un campo bigint non gli sarebbe andato bene.
Non so se con qgis 2 è cambiato qualcosa, ma non credo…

qgis vuole tra i campi esposti in output nella vista un campo di tipo int4 con valori univoci e un indice unique (una pk va benissimo)

A.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 23:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Ragà.
La tabella “LEFT” ha un campo id numerico di tipo bigint ed ha una constraint di PRIMARY KEY.
Per quanto riguarda le varie LEFT JOIN, non fanno altro che collegare chiavi primarie delle tabelle “RIGHT” con le chiavi esterne nella tabella “LEFT”.
Ho fatto eseguire sulla vista la seguente query e non ha dato conteggi maggiori di 1.
SELECT id, COUNT(id)
FROM v_poi_airport
GROUP BY id
ORDER BY COUNT(id) DESC;

Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

Mi ha battuto sul tempo Andrea… io nelle mie view setto sempre la query con Join per evitare tale problema. Se ad un punto corrispondo più record della tabella alfanumerica, puoi provare a dare dentro al provider di postgis come id singolo la chiave primaria e quindi unica della tabella 2.

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.
666 iscritti al 22.7.2013

–

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

2014-02-02 Andrea Peri <aperi2007@gmail.com>:

ok.

Un altro suggerimento:

qgis per il postgres vole disporre di un campo che sia di tipo intero e con una primary-key.
Oppure con un indice di tipo unique.

Verifica che questa condizione sia verificata su uno dei campi che definisci nella vista.
Stai attento che la condizione LEFTJOIN potrebbe falsare questa consizione provocando la ripetizione di records.

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.
666 iscritti al 22.7.2013

Il giorno 02 febbraio 2014 22:58, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Grazie Andrea… ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

fauleman · February 3, 2014, 9:39pm

Il log non è molto parlante
dbname='miodb' host=192.168.1.4 port=5432 user='postgres' password='xxxx' sslmode=disable key='addrpid' srid=4326 type=POINT table="public"."v_poi_airport" (geom) sql= è un layer non valido; non caricato

Il 03/02/2014 20:30, Andrea Peri ha scritto:

puoi postare l'errore che ti da' ?

Il giorno 03 febbraio 2014 19:54, Marco Li Volsi <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha scritto:

    Ciao Andrea.
    Provato come dici tu... ma continua a dare errore.

    Il 03/02/2014 00:32, Andrea Peri ha scritto:

    Su db-manager non so che dirti.

    Pero' puoi fare una controprova.

    definisci sulla tabella principale un campo di tipo "serial" il
    quale si auto-riempira' con dei progressivi.

    alter table tabella1 add column id_2 serial;

    definisci su tale colonna un indice unique:

    create unique index idx-1 on tabella1(id_2);

    Poi ridefinisci la vista aggiungendovi tale campo nuovo.

    E infine prova a riaggiungere la vista a qgis.
    A quel punto qgis trova il campo di tipo int4 che cercava con
    tantodi indice unique e se accetta di aggiungerla alla canvas,
    almeno
    hai trovato dove sta' il problema.
    Altrimenti è da una altra parte.

    A.

    Il giorno 03 febbraio 2014 00:10, Marco Li Volsi
    <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha
    scritto:

        Il campo PRIMARY KEY (... quello bigint per intenderci) è
        presente sulla vista, purtroppo ho proprio bisogno di un
        bigint... mi sono arrivati questi id interi composti da 14
        cifre. La tua risposta è coerente... rimane il dubbio del
        perchè funzioni con DB Manager ?

        Il 03/02/2014 00:00, Andrea Peri ha scritto:

        A quello che ricordo, la regola di qgis è un campo di tipo
        int4 e bigint non gli va bene.
        Inoltre il campo deve essere presente tra quelli esposti
        nella vista, probabilmente lo è, ma dalla tua risposta
        sembrerebbe che esso è presente nella tabella LEFT non è in
        output sulla vista.
        :)

        In ogni caso almeno fino a qgis 1.8 sicuramente un campo
        bigint non gli sarebbe andato bene.
        Non so se con qgis 2 è cambiato qualcosa, ma non credo..

        qgis vuole tra i campi esposti in output nella vista un
        campo di tipo int4 con valori univoci e un indice unique
        (una pk va benissimo)

        A.

        Il giorno 02 febbraio 2014 23:47, Marco Li Volsi
        <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>>
        ha scritto:

            Ciao Ragà.
            La tabella "LEFT" ha un campo id numerico di tipo bigint
            ed ha una constraint di PRIMARY KEY.
            Per quanto riguarda le varie LEFT JOIN, non fanno altro
            che collegare chiavi primarie delle tabelle "RIGHT" con
            le chiavi esterne nella tabella "LEFT".
            Ho fatto eseguire sulla vista la seguente query e non ha
            dato conteggi maggiori di 1.
            SELECT id, COUNT(id)
              FROM v_poi_airport
             GROUP BY id
            ORDER BY COUNT(id) DESC;

            Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

            Mi ha battuto sul tempo Andrea... io nelle mie view
            setto sempre la query con Join per evitare tale
            problema. Se ad un punto corrispondo più record della
            tabella alfanumerica, puoi provare a dare dentro al
            provider di postgis come id singolo la chiave primaria
            e quindi unica della tabella 2.

            2014-02-02 Andrea Peri <aperi2007@gmail.com
            <mailto:aperi2007@gmail.com>>:

                ok.

                Un altro suggerimento:

                qgis per il postgres vole disporre di un campo che
                sia di tipo intero e con una primary-key.
                Oppure con un indice di tipo unique.
                Verifica che questa condizione sia verificata su
                uno dei campi che definisci nella vista.
                Stai attento che la condizione LEFTJOIN potrebbe
                falsare questa consizione provocando la ripetizione
                di records.

                Il giorno 02 febbraio 2014 22:58, Marco Li Volsi
                <marco.livolsi@gmail.com
                <mailto:marco.livolsi@gmail.com>> ha scritto:

                    Grazie Andrea... ho provato ma non funge

                    Il 02/02/2014 22:43, Andrea Peri ha scritto:

                    Prova a modificare la view definendo la
                    geometria in quesot modo:

                    ..,
                    tabella1.campogeometrico::geometry(Geometry,
                    3003) As geom

                    Io ho scritto 3003 ipotizzando che il dato sia
                    in GaussBoaga, se è utm usa 25832 o altro
                    codice epsg.

                    Il giorno 02 febbraio 2014 21:47, Marco Li
                    Volsi <marco.livolsi@gmail.com
                    <mailto:marco.livolsi@gmail.com>> ha scritto:

                        Buona sera a tutti Voi.
                        Ho un comportamento molto strano riguardo
                        al caricamento di una vista geografica su
                        PostGIS.
                        Ho creato una vista su PostGIS del tipo
                        CREATE OR REPLACE VIEW vista1
                            SELECT tabella1.campo1,
                        tabella2.campo2,tabella1.campo2,...,
                        tabella1.campogeometrico
                            FROM tabella1
                            LEFT JOIN tabella2 ON ...
                            WHERE tabella1.campo2 = valore;
                        La vista viene correttamente trovata nella
                        vista geometry_columns.
                        Ho provato a caricare questo layer dal
                        tasto "Aggiungi vettore PostGIS" e mi
                        viene restituito un messaggio di alert.
                        Verificando il registro degli eventi il
                        layer risulta non valido. Se provo a
                        caricare il layer dal DB Manager tutto va
                        come deve andare.
                        Il sistema in questione è QGIS
                        2.0.1-Dufour e POSTGIS="2.0.1 r9979"
                        GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel. 4.8.0,
                        6 March 2012" GDAL="GDAL 1.9.2, released
                        2012/10/08" LIBXML="2.7.8" RASTER.
                        Qualcuno saprebbe dirmi se sbaglio qualcosa?

                        _______________________________________________
                        Gfoss@lists.gfoss.it
                        <mailto: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.
                        666 iscritti al 22.7.2013

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

                    _______________________________________________
                    Gfoss@lists.gfoss.it <mailto: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.
                    666 iscritti al 22.7.2013

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

                _______________________________________________
                Gfoss@lists.gfoss.it <mailto: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.
                666 iscritti al 22.7.2013

            _______________________________________________
            Gfoss@lists.gfoss.it <mailto: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.
            666 iscritti al 22.7.2013

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

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

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

    _______________________________________________
    Gfoss@lists.gfoss.it <mailto: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.
    666 iscritti al 22.7.2013

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

Andrea_Peri · February 3, 2014, 11:43pm

In effetti dice veramente poco.

A lume di naso, direi che probabilmente hai qualcosa di malfunzionante sul tuo qgis, ma dire cosa e come risolvere è difficile.
Prova a sentire sulla ML di qgis se sanno darti qualche maggiore informazione.
E’ veramente curioso questo fatto che con DB-Manager non dia problemi mentre con il provider di qgis li dia.

spiacente di non esserti di maggiore aiuto.

A.

···

Il giorno 03 febbraio 2014 22:39, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Il log non è molto parlante
dbname=‘miodb’ host=192.168.1.4 port=5432 user=‘postgres’ password=‘xxxx’ sslmode=disable key=‘addrpid’ srid=4326 type=POINT table=“public”.“v_poi_airport” (geom) sql= è un layer non valido; non caricato

Il 03/02/2014 20:30, Andrea Peri ha scritto:

puoi postare l’errore che ti da’ ?

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.
666 iscritti al 22.7.2013

–

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

Il giorno 03 febbraio 2014 19:54, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Andrea.
Provato come dici tu… ma continua a dare errore.

Il 03/02/2014 00:32, Andrea Peri ha scritto:

Su db-manager non so che dirti.

Pero’ puoi fare una controprova.

definisci sulla tabella principale un campo di tipo “serial” il quale si auto-riempira’ con dei progressivi.

alter table tabella1 add column id_2 serial;

definisci su tale colonna un indice unique:

create unique index idx-1 on tabella1(id_2);

Poi ridefinisci la vista aggiungendovi tale campo nuovo.

E infine prova a riaggiungere la vista a qgis.

A quel punto qgis trova il campo di tipo int4 che cercava con tantodi indice unique e se accetta di aggiungerla alla canvas, almeno
hai trovato dove sta’ il problema.
Altrimenti è da una altra parte.

A.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 03 febbraio 2014 00:10, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Il campo PRIMARY KEY (… quello bigint per intenderci) è presente sulla vista, purtroppo ho proprio bisogno di un bigint… mi sono arrivati questi id interi composti da 14 cifre. La tua risposta è coerente… rimane il dubbio del perchè funzioni con DB Manager ?

Il 03/02/2014 00:00, Andrea Peri ha scritto:

A quello che ricordo, la regola di qgis è un campo di tipo int4 e bigint non gli va bene.

Inoltre il campo deve essere presente tra quelli esposti nella vista, probabilmente lo è, ma dalla tua risposta sembrerebbe che esso è presente nella tabella LEFT non è in output sulla vista.

In ogni caso almeno fino a qgis 1.8 sicuramente un campo bigint non gli sarebbe andato bene.
Non so se con qgis 2 è cambiato qualcosa, ma non credo…

qgis vuole tra i campi esposti in output nella vista un campo di tipo int4 con valori univoci e un indice unique (una pk va benissimo)

A.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 23:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Ragà.
La tabella “LEFT” ha un campo id numerico di tipo bigint ed ha una constraint di PRIMARY KEY.
Per quanto riguarda le varie LEFT JOIN, non fanno altro che collegare chiavi primarie delle tabelle “RIGHT” con le chiavi esterne nella tabella “LEFT”.
Ho fatto eseguire sulla vista la seguente query e non ha dato conteggi maggiori di 1.
SELECT id, COUNT(id)
FROM v_poi_airport
GROUP BY id
ORDER BY COUNT(id) DESC;

Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

Mi ha battuto sul tempo Andrea… io nelle mie view setto sempre la query con Join per evitare tale problema. Se ad un punto corrispondo più record della tabella alfanumerica, puoi provare a dare dentro al provider di postgis come id singolo la chiave primaria e quindi unica della tabella 2.

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.
666 iscritti al 22.7.2013

–

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

2014-02-02 Andrea Peri <aperi2007@gmail.com>:

ok.

Un altro suggerimento:

qgis per il postgres vole disporre di un campo che sia di tipo intero e con una primary-key.
Oppure con un indice di tipo unique.

Verifica che questa condizione sia verificata su uno dei campi che definisci nella vista.
Stai attento che la condizione LEFTJOIN potrebbe falsare questa consizione provocando la ripetizione di records.

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.
666 iscritti al 22.7.2013

Il giorno 02 febbraio 2014 22:58, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Grazie Andrea… ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

Francesco1 · February 4, 2014, 7:12am

ciao,

adesso non so se sia il tuo caso, ma spesso questo problema è dato dal fatto che il campo chiave della vista geometrica risultante non è univoco.

prova a fare:

select gid, count() from tabella1 group by gid having count() >1;

dove gid per me è il campo chiave della tabella che contiene le geometrie.

qGis ha bisogno che questo campo sia univoco e come dice giustamente Andrea,
un LEFT JOIN (in funzione dei dati) non mantiene (giustamente) l’univocità.

ad esempio, mapserver non ha questo “limite”, e puo’ mostrare un layer da una vista senza avere una chiave primaria univoca.

ma per qGis è ben diverso perche’ per aprire la tabella degli attributi ha bisogno di riferirsi ai singoli record e questo è dato solamente dalla presenza di un campo i cui valori indentifichino univocamente i singoli record.

in questi casi io risolvo creando questo campo univoco per la vista risultante, semplicemente con il numero del record:

select row_number() OVER ()::integer AS gid, etc…

ovviamente se ti puoi permettere il lusso di non avere nella vista risultante il campo gid originario della tabella geometrica.

spero di essere stato utile (e chiaro).

saluti,
francesco

···

Il giorno 04 febbraio 2014 00:43, Andrea Peri <aperi2007@gmail.com> ha scritto:

In effetti dice veramente poco.

A lume di naso, direi che probabilmente hai qualcosa di malfunzionante sul tuo qgis, ma dire cosa e come risolvere è difficile.
Prova a sentire sulla ML di qgis se sanno darti qualche maggiore informazione.
E’ veramente curioso questo fatto che con DB-Manager non dia problemi mentre con il provider di qgis li dia.

spiacente di non esserti di maggiore aiuto.

A.

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.
666 iscritti al 22.7.2013

Il giorno 03 febbraio 2014 22:39, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Il log non è molto parlante
dbname=‘miodb’ host=192.168.1.4 port=5432 user=‘postgres’ password=‘xxxx’ sslmode=disable key=‘addrpid’ srid=4326 type=POINT table=“public”.“v_poi_airport” (geom) sql= è un layer non valido; non caricato

Il 03/02/2014 20:30, Andrea Peri ha scritto:

puoi postare l’errore che ti da’ ?

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.
666 iscritti al 22.7.2013

–

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

Il giorno 03 febbraio 2014 19:54, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Andrea.
Provato come dici tu… ma continua a dare errore.

Il 03/02/2014 00:32, Andrea Peri ha scritto:

Su db-manager non so che dirti.

Pero’ puoi fare una controprova.

definisci sulla tabella principale un campo di tipo “serial” il quale si auto-riempira’ con dei progressivi.

alter table tabella1 add column id_2 serial;

definisci su tale colonna un indice unique:

create unique index idx-1 on tabella1(id_2);

Poi ridefinisci la vista aggiungendovi tale campo nuovo.

E infine prova a riaggiungere la vista a qgis.

A quel punto qgis trova il campo di tipo int4 che cercava con tantodi indice unique e se accetta di aggiungerla alla canvas, almeno
hai trovato dove sta’ il problema.
Altrimenti è da una altra parte.

A.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 03 febbraio 2014 00:10, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Il campo PRIMARY KEY (… quello bigint per intenderci) è presente sulla vista, purtroppo ho proprio bisogno di un bigint… mi sono arrivati questi id interi composti da 14 cifre. La tua risposta è coerente… rimane il dubbio del perchè funzioni con DB Manager ?

Il 03/02/2014 00:00, Andrea Peri ha scritto:

A quello che ricordo, la regola di qgis è un campo di tipo int4 e bigint non gli va bene.

Inoltre il campo deve essere presente tra quelli esposti nella vista, probabilmente lo è, ma dalla tua risposta sembrerebbe che esso è presente nella tabella LEFT non è in output sulla vista.

In ogni caso almeno fino a qgis 1.8 sicuramente un campo bigint non gli sarebbe andato bene.
Non so se con qgis 2 è cambiato qualcosa, ma non credo…

qgis vuole tra i campi esposti in output nella vista un campo di tipo int4 con valori univoci e un indice unique (una pk va benissimo)

A.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 23:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Ciao Ragà.
La tabella “LEFT” ha un campo id numerico di tipo bigint ed ha una constraint di PRIMARY KEY.
Per quanto riguarda le varie LEFT JOIN, non fanno altro che collegare chiavi primarie delle tabelle “RIGHT” con le chiavi esterne nella tabella “LEFT”.
Ho fatto eseguire sulla vista la seguente query e non ha dato conteggi maggiori di 1.
SELECT id, COUNT(id)
FROM v_poi_airport
GROUP BY id
ORDER BY COUNT(id) DESC;

Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

Mi ha battuto sul tempo Andrea… io nelle mie view setto sempre la query con Join per evitare tale problema. Se ad un punto corrispondo più record della tabella alfanumerica, puoi provare a dare dentro al provider di postgis come id singolo la chiave primaria e quindi unica della tabella 2.

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.
666 iscritti al 22.7.2013

–

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

2014-02-02 Andrea Peri <aperi2007@gmail.com>:

ok.

Un altro suggerimento:

qgis per il postgres vole disporre di un campo che sia di tipo intero e con una primary-key.
Oppure con un indice di tipo unique.

Verifica che questa condizione sia verificata su uno dei campi che definisci nella vista.
Stai attento che la condizione LEFTJOIN potrebbe falsare questa consizione provocando la ripetizione di records.

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.
666 iscritti al 22.7.2013

Il giorno 02 febbraio 2014 22:58, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Grazie Andrea… ho provato ma non funge

Il 02/02/2014 22:43, Andrea Peri ha scritto:

Prova a modificare la view definendo la geometria in quesot modo:

…, tabella1.campogeometrico::geometry(Geometry, 3003) As geom

Io ho scritto 3003 ipotizzando che il dato sia in GaussBoaga, se è utm usa 25832 o altro codice epsg.

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.
666 iscritti al 22.7.2013

–

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

Il giorno 02 febbraio 2014 21:47, Marco Li Volsi <marco.livolsi@gmail.com> ha scritto:

Buona sera a tutti Voi.
Ho un comportamento molto strano riguardo al caricamento di una vista geografica su PostGIS.
Ho creato una vista su PostGIS del tipo
CREATE OR REPLACE VIEW vista1
SELECT tabella1.campo1, tabella2.campo2, tabella1.campo2, …, tabella1.campogeometrico
FROM tabella1
LEFT JOIN tabella2 ON …
WHERE tabella1.campo2 = valore;
La vista viene correttamente trovata nella vista geometry_columns.
Ho provato a caricare questo layer dal tasto “Aggiungi vettore PostGIS” e mi viene restituito un messaggio di alert. Verificando il registro degli eventi il layer risulta non valido. Se provo a caricare il layer dal DB Manager tutto va come deve andare.
Il sistema in questione è QGIS 2.0.1-Dufour e POSTGIS=“2.0.1 r9979” GEOS=“3.3.3-CAPI-1.7.4” PROJ=“Rel. 4.8.0, 6 March 2012” GDAL=“GDAL 1.9.2, released 2012/10/08” LIBXML=“2.7.8” RASTER.
Qualcuno saprebbe dirmi se sbaglio qualcosa?

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.
666 iscritti al 22.7.2013

–

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

Paolo_Corti · February 4, 2014, 8:22am

2014-02-03 Marco Li Volsi <marco.livolsi@gmail.com>:

Il log non è molto parlante
dbname='miodb' host=192.168.1.4 port=5432 user='postgres' password='xxxx'
sslmode=disable key='addrpid' srid=4326 type=POINT
table="public"."v_poi_airport" (geom) sql= è un layer non valido; non
caricato

ciao Marco
cosa ti restituisce ogrinfo?

$ ogrinfo PG:"dbname='miodb' host='192.168.1.4' user='postgres'
password='xxxx'" v_poi_airport -so

p

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

fauleman · February 4, 2014, 9:33am

Ciao.
Ho fatto la prova di eseguire la seguente query:
SELECT id, COUNT(id)
FROM v_poi_airport
GROUP BY id
ORDER BY COUNT(id) DESC;
Ma non ho avuto risultati maggiori di 1.
A questo punto penso di avere qualche problema sulla mia installazione

Il 04/02/2014 08:12, francesco marucci ha scritto:

ciao,
adesso non so se sia il tuo caso, ma spesso questo problema è dato dal fatto che il campo chiave della vista geometrica risultante non è univoco.

prova a fare:
select gid, count(*) from tabella1 group by gid having count(*) >1;

dove gid per me è il campo chiave della tabella che contiene le geometrie.

qGis ha bisogno che questo campo sia univoco e come dice giustamente Andrea,
un LEFT JOIN (in funzione dei dati) non mantiene (giustamente) l'univocità.
ad esempio, mapserver non ha questo "limite", e puo' mostrare un layer da una vista senza avere una chiave primaria univoca.
ma per qGis è ben diverso perche' per aprire la tabella degli attributi ha bisogno di riferirsi ai singoli record e questo è dato solamente dalla presenza di un campo i cui valori indentifichino univocamente i singoli record.

in questi casi io risolvo creando questo campo univoco per la vista risultante, semplicemente con il numero del record:

select row_number() OVER ()::integer AS gid, etc...

ovviamente se ti puoi permettere il lusso di non avere nella vista risultante il campo gid originario della tabella geometrica.

spero di essere stato utile (e chiaro).

saluti,
francesco

Il giorno 04 febbraio 2014 00:43, Andrea Peri <aperi2007@gmail.com <mailto:aperi2007@gmail.com>> ha scritto:

    In effetti dice veramente poco.
    A lume di naso, direi che probabilmente hai qualcosa di
    malfunzionante sul tuo qgis, ma dire cosa e come risolvere è
    difficile.
    Prova a sentire sulla ML di qgis se sanno darti qualche maggiore
    informazione.
    E' veramente curioso questo fatto che con DB-Manager non dia
    problemi mentre con il provider di qgis li dia.

    spiacente di non esserti di maggiore aiuto.

    A.

    Il giorno 03 febbraio 2014 22:39, Marco Li Volsi
    <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha
    scritto:

        Il log non è molto parlante
        dbname='miodb' host=192.168.1.4 port=5432 user='postgres'
        password='xxxx' sslmode=disable key='addrpid' srid=4326
        type=POINT table="public"."v_poi_airport" (geom) sql= è un
        layer non valido; non caricato

        Il 03/02/2014 20:30, Andrea Peri ha scritto:

        puoi postare l'errore che ti da' ?

        Il giorno 03 febbraio 2014 19:54, Marco Li Volsi
        <marco.livolsi@gmail.com <mailto:marco.livolsi@gmail.com>> ha
        scritto:

            Ciao Andrea.
            Provato come dici tu... ma continua a dare errore.

            Il 03/02/2014 00:32, Andrea Peri ha scritto:

            Su db-manager non so che dirti.

            Pero' puoi fare una controprova.

            definisci sulla tabella principale un campo di tipo
            "serial" il quale si auto-riempira' con dei progressivi.

            alter table tabella1 add column id_2 serial;

            definisci su tale colonna un indice unique:

            create unique index idx-1 on tabella1(id_2);

            Poi ridefinisci la vista aggiungendovi tale campo nuovo.

            E infine prova a riaggiungere la vista a qgis.
            A quel punto qgis trova il campo di tipo int4 che
            cercava con tantodi indice unique e se accetta di
            aggiungerla alla canvas, almeno
            hai trovato dove sta' il problema.
            Altrimenti è da una altra parte.

            A.

            Il giorno 03 febbraio 2014 00:10, Marco Li Volsi
            <marco.livolsi@gmail.com
            <mailto:marco.livolsi@gmail.com>> ha scritto:

                Il campo PRIMARY KEY (... quello bigint per
                intenderci) è presente sulla vista, purtroppo ho
                proprio bisogno di un bigint... mi sono arrivati
                questi id interi composti da 14 cifre. La tua
                risposta è coerente... rimane il dubbio del perchè
                funzioni con DB Manager ?

                Il 03/02/2014 00:00, Andrea Peri ha scritto:

                A quello che ricordo, la regola di qgis è un campo
                di tipo int4 e bigint non gli va bene.
                Inoltre il campo deve essere presente tra quelli
                esposti nella vista, probabilmente lo è, ma dalla
                tua risposta sembrerebbe che esso è presente nella
                tabella LEFT non è in output sulla vista.
                :)

                In ogni caso almeno fino a qgis 1.8 sicuramente un
                campo bigint non gli sarebbe andato bene.
                Non so se con qgis 2 è cambiato qualcosa, ma non
                credo..

                qgis vuole tra i campi esposti in output nella
                vista un campo di tipo int4 con valori univoci e un
                indice unique (una pk va benissimo)

                A.

                Il giorno 02 febbraio 2014 23:47, Marco Li Volsi
                <marco.livolsi@gmail.com
                <mailto:marco.livolsi@gmail.com>> ha scritto:

                    Ciao Ragà.
                    La tabella "LEFT" ha un campo id numerico di
                    tipo bigint ed ha una constraint di PRIMARY KEY.
                    Per quanto riguarda le varie LEFT JOIN, non
                    fanno altro che collegare chiavi primarie delle
                    tabelle "RIGHT" con le chiavi esterne nella
                    tabella "LEFT".
                    Ho fatto eseguire sulla vista la seguente query
                    e non ha dato conteggi maggiori di 1.
                    SELECT id, COUNT(id)
                      FROM v_poi_airport
                     GROUP BY id
                    ORDER BY COUNT(id) DESC;

                    Il 02/02/2014 23:14, Luca Mandolesi ha scritto:

                    Mi ha battuto sul tempo Andrea... io nelle mie
                    view setto sempre la query con Join per
                    evitare tale problema. Se ad un punto
                    corrispondo più record della tabella
                    alfanumerica, puoi provare a dare dentro al
                    provider di postgis come id singolo la chiave
                    primaria e quindi unica della tabella 2.

                    2014-02-02 Andrea Peri <aperi2007@gmail.com
                    <mailto:aperi2007@gmail.com>>:

                        ok.

                        Un altro suggerimento:

                        qgis per il postgres vole disporre di un
                        campo che sia di tipo intero e con una
                        primary-key.
                        Oppure con un indice di tipo unique.
                        Verifica che questa condizione sia
                        verificata su uno dei campi che definisci
                        nella vista.
                        Stai attento che la condizione LEFTJOIN
                        potrebbe falsare questa consizione
                        provocando la ripetizione di records.

                        Il giorno 02 febbraio 2014 22:58, Marco Li
                        Volsi <marco.livolsi@gmail.com
                        <mailto:marco.livolsi@gmail.com>> ha scritto:

                            Grazie Andrea... ho provato ma non
                            funge

                            Il 02/02/2014 22:43, Andrea Peri ha
                            scritto:

                            Prova a modificare la view definendo
                            la geometria in quesot modo:

                            ..,
                            tabella1.campogeometrico::geometry(Geometry,
                            3003) As geom

                            Io ho scritto 3003 ipotizzando che il
                            dato sia in GaussBoaga, se è utm usa
                            25832 o altro codice epsg.

                            Il giorno 02 febbraio 2014 21:47,
                            Marco Li Volsi
                            <marco.livolsi@gmail.com
                            <mailto:marco.livolsi@gmail.com>> ha
                            scritto:

                                Buona sera a tutti Voi.
                                Ho un comportamento molto strano
                                riguardo al caricamento di una
                                vista geografica su PostGIS.
                                Ho creato una vista su PostGIS
                                del tipo
                                CREATE OR REPLACE VIEW vista1
                                    SELECT tabella1.campo1,
                                tabella2.campo2,tabella1.campo2,...,
                                tabella1.campogeometrico
                                    FROM tabella1
                                    LEFT JOIN tabella2 ON ...
                                    WHERE tabella1.campo2 = valore;
                                La vista viene correttamente
                                trovata nella vista geometry_columns.
                                Ho provato a caricare questo
                                layer dal tasto "Aggiungi vettore
                                PostGIS" e mi viene restituito un
                                messaggio di alert. Verificando
                                il registro degli eventi il layer
                                risulta non valido. Se provo a
                                caricare il layer dal DB Manager
                                tutto va come deve andare.
                                Il sistema in questione è QGIS
                                2.0.1-Dufour e POSTGIS="2.0.1
                                r9979" GEOS="3.3.3-CAPI-1.7.4"
                                PROJ="Rel. 4.8.0, 6 March 2012"
                                GDAL="GDAL 1.9.2, released
                                2012/10/08" LIBXML="2.7.8" RASTER.
                                Qualcuno saprebbe dirmi se
                                sbaglio qualcosa?

                                _______________________________________________
                                Gfoss@lists.gfoss.it
                                <mailto: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.
                                666 iscritti al 22.7.2013

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

                            _______________________________________________
                            Gfoss@lists.gfoss.it
                            <mailto: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.
                            666 iscritti al 22.7.2013

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

                        _______________________________________________
                        Gfoss@lists.gfoss.it
                        <mailto: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.
                        666 iscritti al 22.7.2013

                    _______________________________________________
                    Gfoss@lists.gfoss.it <mailto: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.
                    666 iscritti al 22.7.2013

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

                _______________________________________________
                Gfoss@lists.gfoss.it <mailto: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.
                666 iscritti al 22.7.2013

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

            _______________________________________________
            Gfoss@lists.gfoss.it <mailto: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.
            666 iscritti al 22.7.2013

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

        _______________________________________________
        Gfoss@lists.gfoss.it <mailto: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.
        666 iscritti al 22.7.2013

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

    _______________________________________________
    Gfoss@lists.gfoss.it <mailto: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.
    666 iscritti al 22.7.2013

_______________________________________________
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.
666 iscritti al 22.7.2013

[Gfoss] QGis e vista PostGIS

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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