[Gfoss] postgresql/postgis: due colonne geometry stessa tabella

CREATE TABLE shp_polyg_dati
(
id serial NOT NULL,
geom geometry(MultiPolygon,3003),
frazione character varying(100),
sigla character varying(3),
stato character varying(10),
centroid geometry(Point,3003),
CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
OWNER TO postgres;

​questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate (come logica impone).

···

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326

Si, in una tabella di un DBMS e' possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e' un campo
al pari degli altri solo con il tipo "geometria" (polygon, linestring,
etc..).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
  id serial NOT NULL,
  geom geometry(MultiPolygon,3003),
  frazione character varying(100),
  sigla character varying(3),
  stato character varying(10),
  centroid geometry(Point,3003),
  CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
  OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate (come
logica impone).

--
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51'0.54"N 10°34'27.62"E - EPSG:4326

_______________________________________________
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.
750 iscritti al 18.3.2015

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

ottima casa direi, avere ‘n’ campi geometry in una stessa tabella può far risparmiare tempo, si evita di creare ‘n’ tabelle distinte.

grazie!!!

···

Il giorno 18 agosto 2015 22:39, Andrea Peri <aperi2007@gmail.com> ha scritto:

Si, in una tabella di un DBMS e’ possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e’ un campo
al pari degli altri solo con il tipo “geometria” (polygon, linestring,
etc…).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
id serial NOT NULL,
geom geometry(MultiPolygon,3003),
frazione character varying(100),
sigla character varying(3),
stato character varying(10),
centroid geometry(Point,3003),
CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate (come
logica impone).


Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326


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.
750 iscritti al 18.3.2015

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

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326

Buon giorno

Unico problema è che se in QGis carichi il layer centroid la tabella associata tra le colonne avrà anche la colonna geom, che essendo mutlipolygon può essere pesantuccia……

Era un problema che avevo evidenziato tempo addietro, non so se sia stato poi risolto…

Pietro

Inviato: martedì 18 agosto 2015 22:43

···

ottima casa direi, avere ‘n’ campi geometry in una stessa tabella può far risparmiare tempo, si evita di creare ‘n’ tabelle distinte.

grazie!!!

Il giorno 18 agosto 2015 22:39, Andrea Peri <aperi2007@gmail.com> ha scritto:

Si, in una tabella di un DBMS e’ possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e’ un campo
al pari degli altri solo con il tipo “geometria” (polygon, linestring,
etc…).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
id serial NOT NULL,
geom geometry(MultiPolygon,3003),
frazione character varying(100),
sigla character varying(3),
stato character varying(10),
centroid geometry(Point,3003),
CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate (come
logica impone).


Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51’0.54"N 10°34’27.62"E - EPSG:4326


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.
750 iscritti al 18.3.2015

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

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com

43°51’0.54"N 10°34’27.62"E - EPSG:4326

Per me questo e' un bug.

Se qgis sa gestire solo una colonna geometrica per volta, non serve
che si carichi le altre colonne geometriche.
Avevi aperto un ticket a tale riguardo ?

A.

Il 19 agosto 2015 08:39, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Buon giorno

Unico problema è che se in QGis carichi il layer centroid la tabella
associata tra le colonne avrà anche la colonna geom, che essendo
mutlipolygon può essere pesantuccia……

Era un problema che avevo evidenziato tempo addietro, non so se sia stato
poi risolto..

Pietro

Da: gfoss-bounces@lists.gfoss.it [mailto:gfoss-bounces@lists.gfoss.it] Per
conto di Totò Fiandaca
Inviato: martedì 18 agosto 2015 22:43
A: Andrea Peri <aperi2007@gmail.com>
Cc: GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa tabella

ottima casa direi, avere 'n' campi geometry in una stessa tabella può far
risparmiare tempo, si evita di creare 'n' tabelle distinte.

grazie!!!!

Il giorno 18 agosto 2015 22:39, Andrea Peri <aperi2007@gmail.com> ha
scritto:

Si, in una tabella di un DBMS e' possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e' un campo
al pari degli altri solo con il tipo "geometria" (polygon, linestring,
etc..).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
  id serial NOT NULL,
  geom geometry(MultiPolygon,3003),
  frazione character varying(100),
  sigla character varying(3),
  stato character varying(10),
  centroid geometry(Point,3003),
  CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
  OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate (come
logica impone).

--
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51'0.54"N 10°34'27.62"E - EPSG:4326

_______________________________________________
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.
750 iscritti al 18.3.2015

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

--

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com

43°51'0.54"N 10°34'27.62"E - EPSG:4326

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel
messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential
information may be contained in this message or in its attachments. If you
are not the addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in error,
you may not transcribe, copy or deliver this message to anyone. In that
case, you should delete this message and its attachments. Thank you.

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

E' un problema che mi si era posto diverso tempo fa.
Ne avevo parlato con Paolo Cavallini che sicuramente mi avrà detto di aprire un ticket..

Ma sono pigro :-/

Devo vedere se la cosa è ancora così..
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: mercoledì 19 agosto 2015 08:59
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Totò Fiandaca <pigrecoinfinito@gmail.com>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa tabella

Per me questo e' un bug.

Se qgis sa gestire solo una colonna geometrica per volta, non serve che si carichi le altre colonne geometriche.
Avevi aperto un ticket a tale riguardo ?

A.

Il 19 agosto 2015 08:39, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Buon giorno

Unico problema è che se in QGis carichi il layer centroid la tabella
associata tra le colonne avrà anche la colonna geom, che essendo
mutlipolygon può essere pesantuccia……

Era un problema che avevo evidenziato tempo addietro, non so se sia
stato poi risolto..

Pietro

Da: gfoss-bounces@lists.gfoss.it [mailto:gfoss-bounces@lists.gfoss.it]
Per conto di Totò Fiandaca
Inviato: martedì 18 agosto 2015 22:43
A: Andrea Peri <aperi2007@gmail.com>
Cc: GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa
tabella

ottima casa direi, avere 'n' campi geometry in una stessa tabella può
far risparmiare tempo, si evita di creare 'n' tabelle distinte.

grazie!!!!

Il giorno 18 agosto 2015 22:39, Andrea Peri <aperi2007@gmail.com> ha
scritto:

Si, in una tabella di un DBMS e' possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e' un campo
al pari degli altri solo con il tipo "geometria" (polygon, linestring,
etc..).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
  id serial NOT NULL,
  geom geometry(MultiPolygon,3003),
  frazione character varying(100),
  sigla character varying(3),
  stato character varying(10),
  centroid geometry(Point,3003),
  CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
  OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate
(come logica impone).

--
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51'0.54"N 10°34'27.62"E - EPSG:4326

_______________________________________________
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.
750 iscritti al 18.3.2015

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

--

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com

43°51'0.54"N 10°34'27.62"E - EPSG:4326

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati
nel messaggio, o responsabili per la sua consegna alla persona, o se
avete ricevuto il messaggio per errore, siete pregati di non
trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo
a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY
NOTICE Confidential information may be contained in this message or in
its attachments. If you are not the addressee indicated in this
message, or responsible for message delivering to that person, or if
you have received this message in error, you may not transcribe, copy
or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Vabbeh.
Non e' detto che non tu abbia avuto ragione te.
Ci sta che alla fine la trattino piu' come una evoluzione che come un bug.

Per cui forse non vale neanche la pena porsi il problema.

Per risolvere, basta che ti definisci delle viste che sono tali e
quali le tabelle, ma senza la colonna geometrica che non vuoi.

Ed esponi quelle a qgis.

A.

Il 19 agosto 2015 09:01, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

E' un problema che mi si era posto diverso tempo fa.
Ne avevo parlato con Paolo Cavallini che sicuramente mi avrà detto di aprire un ticket..

Ma sono pigro :-/

Devo vedere se la cosa è ancora così..
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: mercoledì 19 agosto 2015 08:59
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Totò Fiandaca <pigrecoinfinito@gmail.com>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa tabella

Per me questo e' un bug.

Se qgis sa gestire solo una colonna geometrica per volta, non serve che si carichi le altre colonne geometriche.
Avevi aperto un ticket a tale riguardo ?

A.

Il 19 agosto 2015 08:39, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Buon giorno

Unico problema è che se in QGis carichi il layer centroid la tabella
associata tra le colonne avrà anche la colonna geom, che essendo
mutlipolygon può essere pesantuccia……

Era un problema che avevo evidenziato tempo addietro, non so se sia
stato poi risolto..

Pietro

Da: gfoss-bounces@lists.gfoss.it [mailto:gfoss-bounces@lists.gfoss.it]
Per conto di Totò Fiandaca
Inviato: martedì 18 agosto 2015 22:43
A: Andrea Peri <aperi2007@gmail.com>
Cc: GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa
tabella

ottima casa direi, avere 'n' campi geometry in una stessa tabella può
far risparmiare tempo, si evita di creare 'n' tabelle distinte.

grazie!!!!

Il giorno 18 agosto 2015 22:39, Andrea Peri <aperi2007@gmail.com> ha
scritto:

Si, in una tabella di un DBMS e' possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e' un campo
al pari degli altri solo con il tipo "geometria" (polygon, linestring,
etc..).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
  id serial NOT NULL,
  geom geometry(MultiPolygon,3003),
  frazione character varying(100),
  sigla character varying(3),
  stato character varying(10),
  centroid geometry(Point,3003),
  CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
  OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate
(come logica impone).

--
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51'0.54"N 10°34'27.62"E - EPSG:4326

_______________________________________________
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.
750 iscritti al 18.3.2015

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

--

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com

43°51'0.54"N 10°34'27.62"E - EPSG:4326

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute
nel messaggio o nei suoi allegati. Se non siete i destinatari indicati
nel messaggio, o responsabili per la sua consegna alla persona, o se
avete ricevuto il messaggio per errore, siete pregati di non
trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo
a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY
NOTICE Confidential information may be contained in this message or in
its attachments. If you are not the addressee indicated in this
message, or responsible for message delivering to that person, or if
you have received this message in error, you may not transcribe, copy
or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

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

Il 19/08/2015 09:04, Andrea Peri ha scritto:

Vabbeh.
Non e' detto che non tu abbia avuto ragione te.
Ci sta che alla fine la trattino piu' come una evoluzione che come un bug.

Confermo, ticket aperto. Credo sia stato sistemato in master,
controllate il bugtracker per dettagli.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

Confermo, fatta prova adesso sia con qgis 2.8 LTR che qgis 2.11 aggiornato all'altro ieri

Aggiunta colonna punti alla tabella dei limiti di provincia FVG e calcolati i centroidi

In QGis DB Manager vede due layer, uno punti ed uno poligoni
Carico i punti e nella tabella vi è la colonna dei poligoni
Esempio per Trieste
id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876,390013.531182121....
..... ,390009.366919483 5072955.68976876))) Trieste

La tabella impiega un tempo infinito per caricare e tutto il sistema rallenta brutalmente

Per il discorso della vista, si, ok, può andar bene per me che sono un po' skillato, ma volendo distribuire i contenuti ad un'ampia platea la cosa si complica..
Dovrei fare una vista per ogni colonna, possibilmente materializzata (non ho ancora ben capito se in questo caso funzionano gli indici..) e nascondere (o mettere in uno schema non accessibile) le colonne della tabella di origine..

Mh..
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: mercoledì 19 agosto 2015 09:05
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Totò Fiandaca <pigrecoinfinito@gmail.com>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa tabella

Vabbeh.
Non e' detto che non tu abbia avuto ragione te.
Ci sta che alla fine la trattino piu' come una evoluzione che come un bug.

Per cui forse non vale neanche la pena porsi il problema.

Per risolvere, basta che ti definisci delle viste che sono tali e quali le tabelle, ma senza la colonna geometrica che non vuoi.

Ed esponi quelle a qgis.

A.

Il 19 agosto 2015 09:01, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

E' un problema che mi si era posto diverso tempo fa.
Ne avevo parlato con Paolo Cavallini che sicuramente mi avrà detto di aprire un ticket..

Ma sono pigro :-/

Devo vedere se la cosa è ancora così..
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: mercoledì 19 agosto 2015 08:59
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Totò Fiandaca <pigrecoinfinito@gmail.com>; GFOSS
<gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa
tabella

Per me questo e' un bug.

Se qgis sa gestire solo una colonna geometrica per volta, non serve che si carichi le altre colonne geometriche.
Avevi aperto un ticket a tale riguardo ?

A.

Il 19 agosto 2015 08:39, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Buon giorno

Unico problema è che se in QGis carichi il layer centroid la tabella
associata tra le colonne avrà anche la colonna geom, che essendo
mutlipolygon può essere pesantuccia……

Era un problema che avevo evidenziato tempo addietro, non so se sia
stato poi risolto..

Pietro

Da: gfoss-bounces@lists.gfoss.it
[mailto:gfoss-bounces@lists.gfoss.it]
Per conto di Totò Fiandaca
Inviato: martedì 18 agosto 2015 22:43
A: Andrea Peri <aperi2007@gmail.com>
Cc: GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa
tabella

ottima casa direi, avere 'n' campi geometry in una stessa tabella può
far risparmiare tempo, si evita di creare 'n' tabelle distinte.

grazie!!!!

Il giorno 18 agosto 2015 22:39, Andrea Peri <aperi2007@gmail.com> ha
scritto:

Si, in una tabella di un DBMS e' possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e' un campo
al pari degli altri solo con il tipo "geometria" (polygon,
linestring, etc..).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
  id serial NOT NULL,
  geom geometry(MultiPolygon,3003),
  frazione character varying(100),
  sigla character varying(3),
  stato character varying(10),
  centroid geometry(Point,3003),
  CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
  OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate
(come logica impone).

--
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51'0.54"N 10°34'27.62"E - EPSG:4326

_______________________________________________
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.
750 iscritti al 18.3.2015

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

--

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com

43°51'0.54"N 10°34'27.62"E - EPSG:4326

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

On Wed, Aug 19, 2015 at 07:37:15AM +0000, Rossin Pietro wrote:

Confermo, fatta prova adesso sia con qgis 2.8 LTR che qgis 2.11 aggiornato all'altro ieri

Aggiunta colonna punti alla tabella dei limiti di provincia FVG e calcolati i centroidi

In QGis DB Manager vede due layer, uno punti ed uno poligoni
Carico i punti e nella tabella vi è la colonna dei poligoni
Esempio per Trieste
id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876,390013.531182121....
..... ,390009.366919483 5072955.68976876))) Trieste

La tabella impiega un tempo infinito per caricare e tutto il sistema rallenta brutalmente

Per il discorso della vista, si, ok, può andar bene per me che sono un po' skillato, ma volendo distribuire i contenuti ad un'ampia platea la cosa si complica..
Dovrei fare una vista per ogni colonna, possibilmente materializzata (non ho ancora ben capito se in questo caso funzionano gli indici..) e nascondere (o mettere in uno schema non accessibile) le colonne della tabella di origine..

Consiglio di aprire un "enhancement" ticket, se non c'e' gia'.

Una miglioria potrebbe essere nel non caricare automaticamente i campi
possibilmente "grossi", ma consentire all'utente di farlo in maniera
esplicita (tipo: "click to open").

--strk;

Lo immagino benissimo che la cosa si possa complicare.
Anche perche' .
Se dovesse cambiare la struttura della tabella, dovrebbe essere
rivisitata la vista.

Questo per me' e' una specie di incubo che spesso si materializza.
:slight_smile:

A.

Il 19 agosto 2015 09:37, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Confermo, fatta prova adesso sia con qgis 2.8 LTR che qgis 2.11 aggiornato all'altro ieri

Aggiunta colonna punti alla tabella dei limiti di provincia FVG e calcolati i centroidi

In QGis DB Manager vede due layer, uno punti ed uno poligoni
Carico i punti e nella tabella vi è la colonna dei poligoni
Esempio per Trieste
id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876,390013.531182121....
..... ,390009.366919483 5072955.68976876))) Trieste

La tabella impiega un tempo infinito per caricare e tutto il sistema rallenta brutalmente

Per il discorso della vista, si, ok, può andar bene per me che sono un po' skillato, ma volendo distribuire i contenuti ad un'ampia platea la cosa si complica..
Dovrei fare una vista per ogni colonna, possibilmente materializzata (non ho ancora ben capito se in questo caso funzionano gli indici..) e nascondere (o mettere in uno schema non accessibile) le colonne della tabella di origine..

Mh..
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: mercoledì 19 agosto 2015 09:05
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Totò Fiandaca <pigrecoinfinito@gmail.com>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa tabella

Vabbeh.
Non e' detto che non tu abbia avuto ragione te.
Ci sta che alla fine la trattino piu' come una evoluzione che come un bug.

Per cui forse non vale neanche la pena porsi il problema.

Per risolvere, basta che ti definisci delle viste che sono tali e quali le tabelle, ma senza la colonna geometrica che non vuoi.

Ed esponi quelle a qgis.

A.

Il 19 agosto 2015 09:01, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

E' un problema che mi si era posto diverso tempo fa.
Ne avevo parlato con Paolo Cavallini che sicuramente mi avrà detto di aprire un ticket..

Ma sono pigro :-/

Devo vedere se la cosa è ancora così..
p

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: mercoledì 19 agosto 2015 08:59
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Totò Fiandaca <pigrecoinfinito@gmail.com>; GFOSS
<gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa
tabella

Per me questo e' un bug.

Se qgis sa gestire solo una colonna geometrica per volta, non serve che si carichi le altre colonne geometriche.
Avevi aperto un ticket a tale riguardo ?

A.

Il 19 agosto 2015 08:39, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Buon giorno

Unico problema è che se in QGis carichi il layer centroid la tabella
associata tra le colonne avrà anche la colonna geom, che essendo
mutlipolygon può essere pesantuccia……

Era un problema che avevo evidenziato tempo addietro, non so se sia
stato poi risolto..

Pietro

Da: gfoss-bounces@lists.gfoss.it
[mailto:gfoss-bounces@lists.gfoss.it]
Per conto di Totò Fiandaca
Inviato: martedì 18 agosto 2015 22:43
A: Andrea Peri <aperi2007@gmail.com>
Cc: GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] postgresql/postgis: due colonne geometry stessa
tabella

ottima casa direi, avere 'n' campi geometry in una stessa tabella può
far risparmiare tempo, si evita di creare 'n' tabelle distinte.

grazie!!!!

Il giorno 18 agosto 2015 22:39, Andrea Peri <aperi2007@gmail.com> ha
scritto:

Si, in una tabella di un DBMS e' possibile avere N campi geometrici.
Ognuno di essi puo avere un sistema di riferimento differente.

La spiegazione , in astratto, è che un campo geometrico e' un campo
al pari degli altri solo con il tipo "geometria" (polygon,
linestring, etc..).

A.

2015-08-18 21:48 GMT+02:00 Totò Fiandaca <pigrecoinfinito@gmail.com>:

CREATE TABLE shp_polyg_dati
(
  id serial NOT NULL,
  geom geometry(MultiPolygon,3003),
  frazione character varying(100),
  sigla character varying(3),
  stato character varying(10),
  centroid geometry(Point,3003),
  CONSTRAINT shp_polyg_dati_pkey PRIMARY KEY (id_0)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE shp_polyg_dati
  OWNER TO postgres;

questa tabella è possibile crearla, come mai?
ma se la carico in QGIS come vettore PostGIS ho due tabelle separate
(come logica impone).

--
Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com
43°51'0.54"N 10°34'27.62"E - EPSG:4326

_______________________________________________
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.
750 iscritti al 18.3.2015

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

--

Salvatore Fiandaca
mobile.:+39 327.493.8955
m: pigrecoinfinito@gmail.com

43°51'0.54"N 10°34'27.62"E - EPSG:4326

AVVISO DI RISERVATEZZA Informazioni riservate possono essere
contenute nel messaggio o nei suoi allegati. Se non siete i
destinatari indicati nel messaggio, o responsabili per la sua
consegna alla persona, o se avete ricevuto il messaggio per errore,
siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In
tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati.
Grazie. CONFIDENTIALITY NOTICE Confidential information may be
contained in this message or in its attachments. If you are not the
addressee indicated in this message, or responsible for message
delivering to that person, or if you have received this message in
error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

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

On Wed, Aug 19, 2015 at 10:07:09AM +0200, Andrea Peri wrote:

Lo immagino benissimo che la cosa si possa complicare.
Anche perche' .
Se dovesse cambiare la struttura della tabella, dovrebbe essere
rivisitata la vista.

Questo per me' e' una specie di incubo che spesso si materializza.
:slight_smile:

Una prova che potresti fare, per aiutare nella risoluzione dell'incubo
(a parte aprire un ticket, o commentare su uno gia' esistente) e'
costruire la vista in modo da includere ancora il campo geometrico MA
attraverso una funzione di riduzione dell'output, tipo...
GeometryType.

In quel modo si potrebbe capire se il costo ("tempo infinito", lo
chiamava qualcuno) e' nel caricare la geometria dal disco o nel
presentarla al client.

--strk;

No, non mi sono spiegato.

Per me l'incubo che si materializza spesso e' che la struttura delle
tabelle dei vari sistemi GIS che gestisco possono cambiare (in alcun
casi anche a ogni rilascio) per varie ragioni e tutte le volte
conseguenzialmente devo rivedere le configurazioni di tutti i sistemi
e viste che su di esse insistono per rimetterle in sync.

Poiche' non sempre e' dato sapere cosa sia cambiato tra il prima e il
dopo. Uno quando rileva che un campo ha cambiat nome, o ne e'comparos
uno nuovo o ne e' scomparso un altro.
Deve cominciare a rivedere sempre tutti i settaggi sulle applicazioni
webgis, progetti , etc... perwms, wfs, etc..
Per rimettere sempre tutto in sync.

Per questo dicevo che lo comprendo. E? come per le viste. Se cambia
qualcsa va sempre rimesso le cose a posto e questo in un ambiente dove
le cose possono cambiare spesso e' un parametro da soppesare nelle
valutazioni di impeigo di una vista al posto di una tabella.

Invece il tuo suggerimento e' sicuramente pertinente per il problema di Rossin.

A.

Il 19 agosto 2015 10:16, Sandro Santilli <strk@keybit.net> ha scritto:

On Wed, Aug 19, 2015 at 10:07:09AM +0200, Andrea Peri wrote:

Lo immagino benissimo che la cosa si possa complicare.
Anche perche' .
Se dovesse cambiare la struttura della tabella, dovrebbe essere
rivisitata la vista.

Questo per me' e' una specie di incubo che spesso si materializza.
:slight_smile:

Una prova che potresti fare, per aiutare nella risoluzione dell'incubo
(a parte aprire un ticket, o commentare su uno gia' esistente) e'
costruire la vista in modo da includere ancora il campo geometrico MA
attraverso una funzione di riduzione dell'output, tipo...
GeometryType.

In quel modo si potrebbe capire se il costo ("tempo infinito", lo
chiamava qualcuno) e' nel caricare la geometria dal disco o nel
presentarla al client.

--strk;

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

Ciao Sandro
Con quanto scrivi sotto Intendi creare una vista in cui sostituisco la geometria col tipo di geometria?

Allora, la tabella postgis in questione sono 4 geometrie, i poligoni delle province (geom) ed i centroidi (geom_point)
La connessione al server è lentuccia (non ho i dati in locale ma su un server di agenzia)

In pgadmin questa query

SELECT id, geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 20666ms

questa
SELECT id, GeometryType(geom) as geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 346ms

nel primo i valori della colonna geom sono di tipo geometry binario (credo) nel secondo vi è la stringa "multipolygon"

In qgis se carico i punti (centroidi) e provo ad aprire la tabella, dal momento in cui clicco su "apri tabella attributi" alla sua apertura passano cronometrati 27 secondi. La geometria da binaria è convertita in testo, tipo

id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876, .........., ,390009.366919483 5072955.68976876))) Trieste

Creando questa vista
CREATE OR REPLACE VIEW temp.provageomtype AS
SELECT prov3045.id, geometrytype(prov3045.geom) AS geom, prov3045.provincia, prov3045.geom_point
   FROM temp.prov3045;

e caricandola in qgis la resa nell'apertura della tabella attributi è nettamente più veloce, circa 2 secondi.

Va bene questo tipo di informazioni??

Pietro

********************
Una prova che potresti fare, per aiutare nella risoluzione dell'incubo (a parte aprire un ticket, o commentare su uno gia' esistente) e'
costruire la vista in modo da includere ancora il campo geometrico MA attraverso una funzione di riduzione dell'output, tipo...
GeometryType.

In quel modo si potrebbe capire se il costo ("tempo infinito", lo chiamava qualcuno) e' nel caricare la geometria dal disco o nel presentarla al client.

--strk;
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

On Wed, Aug 19, 2015 at 11:22:20AM +0000, Rossin Pietro wrote:

Ciao Sandro
Con quanto scrivi sotto Intendi creare una vista in cui sostituisco la geometria col tipo di geometria?

Allora, la tabella postgis in questione sono 4 geometrie, i poligoni delle province (geom) ed i centroidi (geom_point)
La connessione al server è lentuccia (non ho i dati in locale ma su un server di agenzia)

In pgadmin questa query

SELECT id, geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 20666ms

questa
SELECT id, GeometryType(geom) as geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 346ms

Sicuro che i numeri non siano inquinati da cache varie ?
Puoi provare a ri-lanciare la prima (piu' lenta) query dopo
aver lanciato la seconda ?

In qgis se carico i punti (centroidi) e provo ad aprire la tabella, dal momento in cui clicco su "apri tabella attributi" alla sua apertura passano cronometrati 27 secondi. La geometria da binaria è convertita in testo, tipo

id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876, .........., ,390009.366919483 5072955.68976876))) Trieste

Creando questa vista
CREATE OR REPLACE VIEW temp.provageomtype AS
SELECT prov3045.id, geometrytype(prov3045.geom) AS geom, prov3045.provincia, prov3045.geom_point
   FROM temp.prov3045;

e caricandola in qgis la resa nell'apertura della tabella attributi è nettamente più veloce, circa 2 secondi.

Va bene questo tipo di informazioni??

Ottima.
Nel tuo caso il tempo di caricamento dal disco della geometria sembra
trascurabile rispetto al trasferimento e la presentazione (da 20 a 27
secondo, anche se non e' chiaro quanto dovuto al trasferimento e
quanto alla presentazione).

Se apri un ticket su qgis puoi scriverci queste informazioni.

--strk;

Rifatte le prove, appena arrivato, nessuno (spero) che è a scaricare video o ascoltare radio...

SELECT id, GeometryType(geom) as geom, provincia, geom_point
FROM temp.prov3045;
Tempo medio 31ms

SELECT id, geom, provincia, geom_point
FROM temp.prov3045;
Tempo medio 5447ms

In qgis 2.8.x la vista con la prima query apre in circa 0.6 secondi

L'apertura della tabella dei centroidi, che visualizza la colonna geom dei poligoni, un disastro..
18 secondi circa dal click apri tabella alla visualizzazione dei dati...

Che faccio?
Apro un ticket per problema o chiedo un enhacement?
Ciao

-----Messaggio originale-----
Da: Sandro Santilli [mailto:sandro.santilli@gmail.com] Per conto di Sandro Santilli
Inviato: mercoledì 19 agosto 2015 14:09
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Andrea Peri <aperi2007@gmail.com>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] R: postgresql/postgis: due colonne geometry stessa tabella

On Wed, Aug 19, 2015 at 11:22:20AM +0000, Rossin Pietro wrote:

Ciao Sandro
Con quanto scrivi sotto Intendi creare una vista in cui sostituisco la geometria col tipo di geometria?

Allora, la tabella postgis in questione sono 4 geometrie, i poligoni
delle province (geom) ed i centroidi (geom_point) La connessione al
server è lentuccia (non ho i dati in locale ma su un server di
agenzia)

In pgadmin questa query

SELECT id, geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 20666ms

questa
SELECT id, GeometryType(geom) as geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 346ms

Sicuro che i numeri non siano inquinati da cache varie ?
Puoi provare a ri-lanciare la prima (piu' lenta) query dopo aver lanciato la seconda ?

In qgis se carico i punti (centroidi) e provo ad aprire la tabella,
dal momento in cui clicco su "apri tabella attributi" alla sua
apertura passano cronometrati 27 secondi. La geometria da binaria è
convertita in testo, tipo

id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876, .........., ,390009.366919483 5072955.68976876))) Trieste

Creando questa vista
CREATE OR REPLACE VIEW temp.provageomtype AS SELECT prov3045.id,
geometrytype(prov3045.geom) AS geom, prov3045.provincia, prov3045.geom_point
   FROM temp.prov3045;

e caricandola in qgis la resa nell'apertura della tabella attributi è nettamente più veloce, circa 2 secondi.

Va bene questo tipo di informazioni??

Ottima.
Nel tuo caso il tempo di caricamento dal disco della geometria sembra trascurabile rispetto al trasferimento e la presentazione (da 20 a 27 secondo, anche se non e' chiaro quanto dovuto al trasferimento e quanto alla presentazione).

Se apri un ticket su qgis puoi scriverci queste informazioni.

--strk;
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Io lo segnerei come difetto visto che rende qgis inutilizzabile in
determinati contesti di dati.

Poi nel frattempo che aspetti che venga risolto (forse) l'unica
possibiita' sono mettere 1 sola geometria per tabella, il che vuol
dire abbandonare questa struttura, perche' se uno fa un sistema con 1
sola geometria per tabella, poi non torna certo indietro.
Oppure il ricorso a delle viste con i problemi gia' discussi.

Certo e' un vero peccato che qgis continui a disincentivare un uso
evoluto del dato spaziale e continui a rincorrere arcgis sulla sua
strada. Dovrebbe invece smarcarsi percorrendo strade nuove. Va notato
infatti che arcgis con il suo geodatabase non consente di avere piu'
di 1 geometria su una tabella. QGIS si ma in teoria, perche' in
pratica ne penalizza l'impiego per cui e' come dire , non usarla.

E non escludo che questa sara' il suggerimento che riceverai sulla
lista qgis quando aprirai il ticket.

Il 20 agosto 2015 08:05, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Rifatte le prove, appena arrivato, nessuno (spero) che è a scaricare video o ascoltare radio...

SELECT id, GeometryType(geom) as geom, provincia, geom_point
FROM temp.prov3045;
Tempo medio 31ms

SELECT id, geom, provincia, geom_point
FROM temp.prov3045;
Tempo medio 5447ms

In qgis 2.8.x la vista con la prima query apre in circa 0.6 secondi

L'apertura della tabella dei centroidi, che visualizza la colonna geom dei poligoni, un disastro..
18 secondi circa dal click apri tabella alla visualizzazione dei dati...

Che faccio?
Apro un ticket per problema o chiedo un enhacement?
Ciao

-----Messaggio originale-----
Da: Sandro Santilli [mailto:sandro.santilli@gmail.com] Per conto di Sandro Santilli
Inviato: mercoledì 19 agosto 2015 14:09
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Andrea Peri <aperi2007@gmail.com>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] R: postgresql/postgis: due colonne geometry stessa tabella

On Wed, Aug 19, 2015 at 11:22:20AM +0000, Rossin Pietro wrote:

Ciao Sandro
Con quanto scrivi sotto Intendi creare una vista in cui sostituisco la geometria col tipo di geometria?

Allora, la tabella postgis in questione sono 4 geometrie, i poligoni
delle province (geom) ed i centroidi (geom_point) La connessione al
server è lentuccia (non ho i dati in locale ma su un server di
agenzia)

In pgadmin questa query

SELECT id, geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 20666ms

questa
SELECT id, GeometryType(geom) as geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 346ms

Sicuro che i numeri non siano inquinati da cache varie ?
Puoi provare a ri-lanciare la prima (piu' lenta) query dopo aver lanciato la seconda ?

In qgis se carico i punti (centroidi) e provo ad aprire la tabella,
dal momento in cui clicco su "apri tabella attributi" alla sua
apertura passano cronometrati 27 secondi. La geometria da binaria è
convertita in testo, tipo

id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876, .........., ,390009.366919483 5072955.68976876))) Trieste

Creando questa vista
CREATE OR REPLACE VIEW temp.provageomtype AS SELECT prov3045.id,
geometrytype(prov3045.geom) AS geom, prov3045.provincia, prov3045.geom_point
   FROM temp.prov3045;

e caricandola in qgis la resa nell'apertura della tabella attributi è nettamente più veloce, circa 2 secondi.

Va bene questo tipo di informazioni??

Ottima.
Nel tuo caso il tempo di caricamento dal disco della geometria sembra trascurabile rispetto al trasferimento e la presentazione (da 20 a 27 secondo, anche se non e' chiaro quanto dovuto al trasferimento e quanto alla presentazione).

Se apri un ticket su qgis puoi scriverci queste informazioni.

--strk;
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

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

On Thu, Aug 20, 2015 at 06:05:38AM +0000, Rossin Pietro wrote:

Rifatte le prove, appena arrivato, nessuno (spero) che è a scaricare video o ascoltare radio...

SELECT id, GeometryType(geom) as geom, provincia, geom_point
FROM temp.prov3045;
Tempo medio 31ms

SELECT id, geom, provincia, geom_point
FROM temp.prov3045;
Tempo medio 5447ms

In qgis 2.8.x la vista con la prima query apre in circa 0.6 secondi

L'apertura della tabella dei centroidi, che visualizza la colonna geom dei poligoni, un disastro..
18 secondi circa dal click apri tabella alla visualizzazione dei dati...

Che faccio?
Apro un ticket per problema o chiedo un enhacement?

Apri un ticket per enhancement :slight_smile:

Considera che probabilmente lo stesso problema lo avresti con colonne
grandi di altro genere, tipo raster o non so cos'altro.

Inoltre, conta pure il tempo che ci vuole a visualizzare la colonna
"geom", perche' immagino potrebbe tornare ad essere 18 secondi, almeno
visualizzando l'extent intero.

--strk;

On Thu, 20 Aug 2015 09:00:07 +0200, Andrea Peri wrote:

Certo e' un vero peccato che qgis continui a disincentivare un uso
evoluto del dato spaziale e continui a rincorrere arcgis sulla sua
strada. Dovrebbe invece smarcarsi percorrendo strade nuove. Va notato
infatti che arcgis con il suo geodatabase non consente di avere piu'
di 1 geometria su una tabella. QGIS si ma in teoria, perche' in
pratica ne penalizza l'impiego per cui e' come dire , non usarla.

Andrea,

personalmente trovo particolarmente stimolante questa tua osservazione.

a partire quanto meno dall'ultimo quindicennio lo stato dell'arte delle
tecnologie GeoSpatial e' ormai robustamente disciplinato da numerosi
riferimenti concettuali e normativi dettagliatamente descritti e
minuziosamente formalizzati e standardizzati.

ormai siamo fortunamente ben lontani dalle prime avventurose esperienze
"do it yourself" dei tempi eroici, quando ciascun singolo sw applicativo
era libero di inventarsi con alterne fortune i propri modelli di
riferimento preferiti, con l'ovvio effetto di creare alla fine un caos
ingovernabile che uccideva qualsiasi interoperabilita'.

anche se il modello standard viene poi declinato in numerose varianti
dialettali (SQL/SFS, SQL/MM, WKT, WKB, GML, GeoJSON etc) e' comunque
assolutamente chiaro che esiste un nucleo centrale immutabile e molto
robustamente radicato che si incardina sulle sette classi canoniche:
POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON
e GEOMETRYCOLLECTION, con l'aggiunta dell'ottava classe generica
GEOMETRY.

non c'e' assolutamente nulla nel modello standard che proibisca di
gestire in parallelo un numero arbitrario di geometrie per la medesima
feature; gli esempi pratici in cui una capacita' di questa natura
risulta sicuramente utile non mancano certo:
- localita' abitate rappresentate sia come aree poligonali che come
   punti (da utilizzarsi a seconda della scala di rappresentazione)
- confini amministrativi, fiumi, strade, ferrovie, curve di livello
   etc a diversi livelli di risoluzione e dettaglio (anche qua: da
   utilizzarsi in relazione alla scala di rappresentazione)
- rappresentazioni statiche in diversi SRID alternativi in modo
   tale da evitare il perditempo della riproiezione "al volo"
- etc etc etc

inoltre il modello standard consente esplicitemente di utilizzare
le due classi "fritto misto" GEOMETRYCOLLECTION e GEOMETRY; e pure
questa e' un'opzione che puo' risultare decisamente utile in svariati
casi d'uso concreti (se non altro, per potere ispezionare correttamente
i risultati di operazioni spatial quali p.es. ST_Intersection).

Andrea gia' faceva notare come gestire layers che contangano piu'
di una singola colonna Geometry sia materialmente difficoltoso
quando si utilizzano i piu' diffusi applicativi desktop GIS.
di fatto la situazione per GEOMETRYCOLLECTION e GEOMETRY e' ben
peggiore; visualizzare geometrie che appartengano ad una di queste
due classi non e' semplicemente difficoltoso, e' tassativamente
proibito :smiley:

esistono validi motivi tecnici che giustifichino queste scelte ?
non pare proprio: qualsiasi servizio WebGIS basato su protocolli
standard WMS/WFS riesce tranquillamente a gestire indistintamente
tutte quante le classi geometriche canoniche senza difficolta',
cosi' come riesce facilmente a pubblicare layers multi-geometria
(magari andandosi a pescare automaticamente il livello di
risoluzione e dettaglio piu' adeguato in base alla scala).

e allora perche' mai non ci riescono i desktop-GIS ?
temo che la risposta piu' adeguata sia quella gia' identificata
da Andrea; perche' piu' o meno tutti i desktop-GIS (sia free
che proprietari) aderiscono sostanzialmente ad un unico modello
concettuale che in ultima analisi e' quello di ArcGis.
piu' che sugli standard piu' recenti questo modello continua
invece ancora oggi a basarsi sostanzialmente sulle limitate e
rigide opzioni supportate dal venerabile (ed obsoleto) Shapefile.
il supporto per strutture dati un po' piu' fresche e meno ammuffite
(SQL, WFS, GML etc) e' indubbiamente presente, ma deve comunque
adattarsi alle "maglie strette" imposte dal precedente modello shp;
tutto quel che eccede i limiti intrinseci di quel vecchio modello
viene sacrificato, oppure costringe a contorsioni avventurose.
ed e' veramente un peccato: servirebbe un po' d'aria fresca. :wink:

ciao Sandro

Certo è un peccato che non si riescano a gestire bene più colonne geometria...
Faccio un esempio
Ora per cercare di aumentare le performances su Lizmap pensavo di creare più geometrie a vari gradi di semplificazione da rendere a scale diverse.
Spacchettare la cosa in più tabelle genera sicuramente casini, comunque disagio.
Dovrei mettere gli oggetti in tabelle separate e agganciarli alle tabelle dati con delle viste. Possibilmente materializzate...
Per queste ultime alla fine non ho ben capito se valgono gli indici spaziali creati sulle colonne geometria delle tabelle di origine..

Averli in un'unica tabella, in "n" colonne geometriche, renderebbe più semplice l'operazione..

pietro

-----Messaggio originale-----
Da: Andrea Peri [mailto:aperi2007@gmail.com]
Inviato: giovedì 20 agosto 2015 09:00
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Sandro Santilli <strk@keybit.net>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] R: postgresql/postgis: due colonne geometry stessa tabella

Io lo segnerei come difetto visto che rende qgis inutilizzabile in determinati contesti di dati.

Poi nel frattempo che aspetti che venga risolto (forse) l'unica possibiita' sono mettere 1 sola geometria per tabella, il che vuol dire abbandonare questa struttura, perche' se uno fa un sistema con 1 sola geometria per tabella, poi non torna certo indietro.
Oppure il ricorso a delle viste con i problemi gia' discussi.

Certo e' un vero peccato che qgis continui a disincentivare un uso evoluto del dato spaziale e continui a rincorrere arcgis sulla sua strada. Dovrebbe invece smarcarsi percorrendo strade nuove. Va notato infatti che arcgis con il suo geodatabase non consente di avere piu'
di 1 geometria su una tabella. QGIS si ma in teoria, perche' in pratica ne penalizza l'impiego per cui e' come dire , non usarla.

E non escludo che questa sara' il suggerimento che riceverai sulla lista qgis quando aprirai il ticket.

Il 20 agosto 2015 08:05, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Rifatte le prove, appena arrivato, nessuno (spero) che è a scaricare video o ascoltare radio...

SELECT id, GeometryType(geom) as geom, provincia, geom_point FROM
temp.prov3045; Tempo medio 31ms

SELECT id, geom, provincia, geom_point FROM temp.prov3045; Tempo medio
5447ms

In qgis 2.8.x la vista con la prima query apre in circa 0.6 secondi

L'apertura della tabella dei centroidi, che visualizza la colonna geom dei poligoni, un disastro..
18 secondi circa dal click apri tabella alla visualizzazione dei dati...

Che faccio?
Apro un ticket per problema o chiedo un enhacement?
Ciao

-----Messaggio originale-----
Da: Sandro Santilli [mailto:sandro.santilli@gmail.com] Per conto di
Sandro Santilli
Inviato: mercoledì 19 agosto 2015 14:09
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: Andrea Peri <aperi2007@gmail.com>; GFOSS <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] R: postgresql/postgis: due colonne geometry
stessa tabella

On Wed, Aug 19, 2015 at 11:22:20AM +0000, Rossin Pietro wrote:

Ciao Sandro
Con quanto scrivi sotto Intendi creare una vista in cui sostituisco la geometria col tipo di geometria?

Allora, la tabella postgis in questione sono 4 geometrie, i poligoni
delle province (geom) ed i centroidi (geom_point) La connessione al
server è lentuccia (non ho i dati in locale ma su un server di
agenzia)

In pgadmin questa query

SELECT id, geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 20666ms

questa
SELECT id, GeometryType(geom) as geom, provincia, geom_point
  FROM temp.prov3045;
ci impiega 346ms

Sicuro che i numeri non siano inquinati da cache varie ?
Puoi provare a ri-lanciare la prima (piu' lenta) query dopo aver lanciato la seconda ?

In qgis se carico i punti (centroidi) e provo ad aprire la tabella,
dal momento in cui clicco su "apri tabella attributi" alla sua
apertura passano cronometrati 27 secondi. La geometria da binaria è
convertita in testo, tipo

id geom provincia
1 SRID=3045;MULTIPOLYGON(((390009.366919483 5072955.68976876, .........., ,390009.366919483 5072955.68976876))) Trieste

Creando questa vista
CREATE OR REPLACE VIEW temp.provageomtype AS SELECT prov3045.id,
geometrytype(prov3045.geom) AS geom, prov3045.provincia, prov3045.geom_point
   FROM temp.prov3045;

e caricandola in qgis la resa nell'apertura della tabella attributi è nettamente più veloce, circa 2 secondi.

Va bene questo tipo di informazioni??

Ottima.
Nel tuo caso il tempo di caricamento dal disco della geometria sembra trascurabile rispetto al trasferimento e la presentazione (da 20 a 27 secondo, anche se non e' chiaro quanto dovuto al trasferimento e quanto alla presentazione).

Se apri un ticket su qgis puoi scriverci queste informazioni.

--strk;
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo a nessuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie. CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.