postgresql/postgis: due colonne geometry stessa tabella

[Andrea Peri]

Questi giochetti sono tipici dei sistemi wms dedicati.
Li trovi disponibili in mapserver o in geoserver.
Cioe' trovi soluzioni che ti permettono di modifiacare i comportamenti
a seconda della scala e quindi anche cambiare il tipo di dataset
esposto, il tutto in maniera trasparente all'utente che usa il dato.
Io ne faccio un uso continuo di questi meccanismi.
Non so' pero' se lizmap e' compatibile con mapserver o geoserver.
Sospetto di no.

A.


Il 20 agosto 2015 12:01, Rossin Pietro <[hidden email]> ha scritto:

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

--
-----------------
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

[pcav]

Il 20/08/2015 13:35, Andrea Peri ha scritto:

> Non so' pero' se lizmap e' compatibile con mapserver o geoserver.

Lizmap usa QGIS come backend, ma puo' includere anche WMS da altri server.
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

[pietro rossin]

Da: Andrea Peri [mailto:[hidden email]]
Inviato: giovedì 20 agosto 2015 13:35

>Questi giochetti sono tipici dei sistemi wms dedicati.
>Li trovi disponibili in mapserver o in geoserver.
>Cioe' trovi soluzioni che ti permettono di modifiacare i comportamenti a seconda della scala e quindi anche cambiare il tipo di dataset esposto, il tutto in maniera trasparente all'utente che usa il dato.
>Io ne faccio un uso continuo di questi meccanismi.
>Non so' pero' se lizmap e' compatibile con mapserver o geoserver.
>Sospetto di no.

Ok, ma credo sia un altro discorso.
Non mi interessa fornire dei WMS al pubblico per il momento.
Mi interessa scaricare il povero qgis-server da del lavoro inutile.
Il flusso del dato è postgis>qgis-server>web
Credo che metterci in mezzo un geoserver o un mapserver che prepara dei wms da dare a qgis-server sia un passo in più.

Non credo si guadagni un gran chè in termini di prestazioni.
I dati non sono molto dinamici, anzi.
Quindi, per non complicarmi la vita, piuttosto andrei di colonne geometrie multiple a densità di vertici/nodi differente, possibilmente in una singola tabella.
Su questa andrei a fare "n" viste materializzate una per colonna geometria.

Aspetto che mi aggiornino il server postgres alla versione >9.2 poiché quel tipo di viste non esistono sulla nostra attale, la 9.1.x.

Per il momento in lizmap stiamo facendo prove con il caro vecchio shp, con geometrie a diversi gradi di semplificazione e sembra funzionare bene.
Un gruppo di layer tutti tematizzati nella stessa maniera (comodissino il copia/incolla stile di qgis) raggruppati e accesi/spenti a scala diversa..
pietro

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