postgresql/postgis: due colonne geometry stessa tabella

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

postgresql/postgis: due colonne geometry stessa tabella

pigreco
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: [hidden email]
43°51'0.54"N  10°34'27.62"E - EPSG:4326



_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

Andrea Peri
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 <[hidden email]>:

> 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: [hidden email]
> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>
>
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 750 iscritti al 18.3.2015



--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

pigreco
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 <[hidden email]> 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 <[hidden email]>:
> 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: [hidden email]
> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>
>
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 750 iscritti al 18.3.2015



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



--
Salvatore Fiandaca
mobile.:+39 327.493.8955 
m: [hidden email]
43°51'0.54"N  10°34'27.62"E - EPSG:4326



_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

R: postgresql/postgis: due colonne geometry stessa tabella

pietro rossin

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: [hidden email] [mailto:[hidden email]] Per conto di Totò Fiandaca
Inviato: martedì 18 agosto 2015 22:43
A: Andrea Peri <[hidden email]>
Cc: GFOSS <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>:
> 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: [hidden email]
> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>
>
>

> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 750 iscritti al 18.3.2015



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



 

--

Salvatore Fiandaca
mobile.:+39 327.493.8955 
m: [hidden email]

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.
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

Andrea Peri
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]] Per
> conto di Totò Fiandaca
> Inviato: martedì 18 agosto 2015 22:43
> A: Andrea Peri <[hidden email]>
> Cc: GFOSS <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>:
>> 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: [hidden email]
>> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>>
>>
>>
>
>> _______________________________________________
>> [hidden email]
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni
>> dell'Associazione GFOSS.it.
>> 750 iscritti al 18.3.2015
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>
>
>
>
>
> --
>
> Salvatore Fiandaca
> mobile.:+39 327.493.8955
> m: [hidden email]
>
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

R: postgresql/postgis: due colonne geometry stessa tabella

pietro rossin
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:[hidden email]]
Inviato: mercoledì 19 agosto 2015 08:59
A: Rossin Pietro <[hidden email]>
Cc: Totò Fiandaca <[hidden email]>; GFOSS <[hidden email]>
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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]]
> Per conto di Totò Fiandaca
> Inviato: martedì 18 agosto 2015 22:43
> A: Andrea Peri <[hidden email]>
> Cc: GFOSS <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>:
>> 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: [hidden email]
>> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>>
>>
>>
>
>> _______________________________________________
>> [hidden email]
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le
>> posizioni dell'Associazione GFOSS.it.
>> 750 iscritti al 18.3.2015
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
>
>
>
>
>
> --
>
> Salvatore Fiandaca
> mobile.:+39 327.493.8955
> m: [hidden email]
>
> 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.
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

Andrea Peri
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 <[hidden email]> 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:[hidden email]]
> Inviato: mercoledì 19 agosto 2015 08:59
> A: Rossin Pietro <[hidden email]>
> Cc: Totò Fiandaca <[hidden email]>; GFOSS <[hidden email]>
> 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 <[hidden email]> 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: [hidden email] [mailto:[hidden email]]
>> Per conto di Totò Fiandaca
>> Inviato: martedì 18 agosto 2015 22:43
>> A: Andrea Peri <[hidden email]>
>> Cc: GFOSS <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>> 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: [hidden email]
>>> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>>>
>>>
>>>
>>
>>> _______________________________________________
>>> [hidden email]
>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>>> Questa e' una lista di discussione pubblica aperta a tutti.
>>> I messaggi di questa lista non hanno relazione diretta con le
>>> posizioni dell'Associazione GFOSS.it.
>>> 750 iscritti al 18.3.2015
>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -----------------
>>
>>
>>
>>
>>
>> --
>>
>> Salvatore Fiandaca
>> mobile.:+39 327.493.8955
>> m: [hidden email]
>>
>> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

pcav
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
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

R: postgresql/postgis: due colonne geometry stessa tabella

pietro rossin
In reply to this post by Andrea Peri
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:[hidden email]]
Inviato: mercoledì 19 agosto 2015 09:05
A: Rossin Pietro <[hidden email]>
Cc: Totò Fiandaca <[hidden email]>; GFOSS <[hidden email]>
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 <[hidden email]> 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:[hidden email]]
> Inviato: mercoledì 19 agosto 2015 08:59
> A: Rossin Pietro <[hidden email]>
> Cc: Totò Fiandaca <[hidden email]>; GFOSS
> <[hidden email]>
> 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 <[hidden email]> 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: [hidden email]
>> [mailto:[hidden email]]
>> Per conto di Totò Fiandaca
>> Inviato: martedì 18 agosto 2015 22:43
>> A: Andrea Peri <[hidden email]>
>> Cc: GFOSS <[hidden email]>
>> 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 <[hidden email]> 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 <[hidden email]>:
>>> 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: [hidden email]
>>> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>>>
>>>
>>>
>>
>>> _______________________________________________
>>> [hidden email]
>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>>> Questa e' una lista di discussione pubblica aperta a tutti.
>>> I messaggi di questa lista non hanno relazione diretta con le
>>> posizioni dell'Associazione GFOSS.it.
>>> 750 iscritti al 18.3.2015
>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty àèìòù
>> -----------------
>>
>>
>>
>>
>>
>> --
>>
>> Salvatore Fiandaca
>> mobile.:+39 327.493.8955
>> m: [hidden email]
>>
>> 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.
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: R: postgresql/postgis: due colonne geometry stessa tabella

Sandro Santilli
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;
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

Andrea Peri
In reply to this post by pietro rossin
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.
:)

A.


Il 19 agosto 2015 09:37, Rossin Pietro <[hidden email]> 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:[hidden email]]
> Inviato: mercoledì 19 agosto 2015 09:05
> A: Rossin Pietro <[hidden email]>
> Cc: Totò Fiandaca <[hidden email]>; GFOSS <[hidden email]>
> 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 <[hidden email]> 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:[hidden email]]
>> Inviato: mercoledì 19 agosto 2015 08:59
>> A: Rossin Pietro <[hidden email]>
>> Cc: Totò Fiandaca <[hidden email]>; GFOSS
>> <[hidden email]>
>> 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 <[hidden email]> 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: [hidden email]
>>> [mailto:[hidden email]]
>>> Per conto di Totò Fiandaca
>>> Inviato: martedì 18 agosto 2015 22:43
>>> A: Andrea Peri <[hidden email]>
>>> Cc: GFOSS <[hidden email]>
>>> 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 <[hidden email]> 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 <[hidden email]>:
>>>> 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: [hidden email]
>>>> 43°51'0.54"N  10°34'27.62"E - EPSG:4326
>>>>
>>>>
>>>>
>>>
>>>> _______________________________________________
>>>> [hidden email]
>>>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>>>> Questa e' una lista di discussione pubblica aperta a tutti.
>>>> I messaggi di questa lista non hanno relazione diretta con le
>>>> posizioni dell'Associazione GFOSS.it.
>>>> 750 iscritti al 18.3.2015
>>>
>>>
>>>
>>> --
>>> -----------------
>>> Andrea Peri
>>> . . . . . . . . .
>>> qwerty àèìòù
>>> -----------------
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Salvatore Fiandaca
>>> mobile.:+39 327.493.8955
>>> m: [hidden email]
>>>
>>> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

Sandro Santilli
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.
> :)

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;
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: postgresql/postgis: due colonne geometry stessa tabella

Andrea Peri
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 <[hidden email]> 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.
>> :)
>
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

R: postgresql/postgis: due colonne geometry stessa tabella

pietro rossin
In reply to this post by Sandro Santilli
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.
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: R: postgresql/postgis: due colonne geometry stessa tabella

Sandro Santilli
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;
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

R: R: postgresql/postgis: due colonne geometry stessa tabella

pietro rossin
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:[hidden email]] Per conto di Sandro Santilli
Inviato: mercoledì 19 agosto 2015 14:09
A: Rossin Pietro <[hidden email]>
Cc: Andrea Peri <[hidden email]>; GFOSS <[hidden email]>
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.
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: R: postgresql/postgis: due colonne geometry stessa tabella

Andrea Peri
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 <[hidden email]> 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:[hidden email]] Per conto di Sandro Santilli
> Inviato: mercoledì 19 agosto 2015 14:09
> A: Rossin Pietro <[hidden email]>
> Cc: Andrea Peri <[hidden email]>; GFOSS <[hidden email]>
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: R: R: postgresql/postgis: due colonne geometry stessa tabella

Sandro Santilli
In reply to this post by pietro rossin
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 :)

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;
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

Re: R: postgresql/postgis: due colonne geometry stessa tabella

a.furieri
In reply to this post by Andrea Peri
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 :-D

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. ;-)

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
Reply | Threaded
Open this post in threaded view
|

R: R: postgresql/postgis: due colonne geometry stessa tabella

pietro rossin
In reply to this post by Andrea Peri
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:[hidden email]]
Inviato: giovedì 20 agosto 2015 09:00
A: Rossin Pietro <[hidden email]>
Cc: Sandro Santilli <[hidden email]>; GFOSS <[hidden email]>
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 <[hidden email]> 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:[hidden email]] Per conto di
> Sandro Santilli
> Inviato: mercoledì 19 agosto 2015 14:09
> A: Rossin Pietro <[hidden email]>
> Cc: Andrea Peri <[hidden email]>; GFOSS <[hidden email]>
> 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.
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
12