postgresql/postgis: due colonne geometry stessa tabella
Locked
12
12
 
|
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). _______________________________________________ [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 |
Re: postgresql/postgis: due colonne geometry stessa tabella
|
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 |
|
|
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. _______________________________________________ [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 |
R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 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:
-- Salvatore Fiandaca 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 |
Re: 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 àèìòù ----------------- _______________________________________________ [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 |
R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
Re: 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 àèìòù ----------------- _______________________________________________ [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 |
|
|
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 |
R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
Re: R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
Re: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
Re: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
Re: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
Re: 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; _______________________________________________ [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 |
R: R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
Re: 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 àèìòù ----------------- _______________________________________________ [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 |
Re: R: R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
|
|
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 |
R: R: postgresql/postgis: due colonne geometry stessa tabella
|
|
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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |