[Gfoss] ST_Union e PostGIS

[Andrea Peri]

Infatti queste cose non sono facili per niente.
Però il tuo approccio è sano.
Ovvero hai d lle specifiche e stai valutando come fare per ottenere il
sistema nell'ansia completezza.
Ora che conosci meglio i limiti di un determinato stack tecnologico puoi
decidere se introdurre nel tuo sistema infrastrutturale dei cambiamenti che
superino i limiti identificati oppure cambi qualcosa nellonstack.

Sempre meglio che partire mettendo in piedi un sistema che abbozza il
funzionamento rimandando certi studi a quando non è più differisce e solo a
quel momento scoprire i limiti e non sapere come fare a risolverli.


Il 13 Dic 2017 3:19 PM, "Massimiliano Moraca" <massimilianomoraca a gmail.com>
ha scritto:

> La facevo facile quindi io Sandro.. :|
>
> hint: ma perche' vuoi usare proprio una Spatial View ?
> > nel tuo caso, se ho capito bene il problema, sarebbe molto
> > piu' opportuno materializzare ancora un'altra tavola, p.es.:
>
>
> Voglio creare una view in virtù del fatto che si autoaggiorna...in pratica
> ogni tanto capita che mi venga chiesto di spostare un villaggio da una
> categoria all'altra e rifare la tabella ogni volta è scocciante. Mi spiego
> meglio. Il file in questione è solo un estratto depurato di tutta una serie
> di informazioni(per motivi di privacy relativa al progetto) che rientrano
> in una decina di colonne. Ad esempio:
>
> Nome|Colore|tipo|area
> A|rosso|tipo1|10
> B|verde|tipo2|100
> C|blu|tipo1|3
> D|rosso|tipo1|450
> E|blu|tipo3|753
>
> Se per qualche motivo B deve diventare tipo3 ed io ho un raggruppamento per
> tipo con una sommatoria delle aree per tipo, con la view mi basta cambiare
> il dato nella tabella sorgente per avere attivo l'automatismo; altrimenti
> dovrei creare una nuova tabella ogni volta.
>
> Il giorno 13 dicembre 2017 14:56, <a.furieri a lqt.it> ha scritto:
>
> > On Wed, 13 Dec 2017 13:56:20 +0100, Massimiliano Moraca wrote:
> >
> >> Come ho detto a Marco ogc_fid è chiave primaria. Avevo notato
> >> un po' di tempo fa che nel creare le VIEW SpatiaLite ti chiede
> >> comunque un id dalla tabella sorgente, id assegnato poi random.
> >>
> >>
> > Massimiliano,
> >
> > stai ben attento perche' qua rischi di combinare un bell'arrosto.
> >
> > 1. "nel creare le VIEW SpatiaLite ti chiede comunque un id dalla
> >    tabella sorgente"
> >
> >    esatto, e' proprio cosi': per la precisione ti chiede di
> >    specificare quale sia il nome della colonna-VIEW che riporta
> >    il ROWID che identifica la riga della tavola-input che
> >    fornisce la geometria presente nella View.
> >    Corollario: una Spatial View di SpatiaLite non puo' mai
> >    fornire una geometria che sia il risultato di una funzione
> >    o il frutto di una aggregazione.
> >    _DEVE_ necessariamente essere una geometria presa tal
> >    quale da una delle tavole di input della View, senza che
> >    intervenga nessuna manipolazione di sorta.
> >   e la colonna "rowid" presente nella Spatial View deve
> >   consentire di tenere coerentemente in synchro le righe
> >   della tavola-madre con il suo eventuale Spatial Index.
> >
> >
> > 2. "id assegnato poi random"
> >
> >    assolutamene _NO_ !!!!
> >    non puo' essere random, _DEVE_ identificare esattamente
> >    la riga della tavola che fornisce la geometria (ergo, o
> >    si tratta di una PK oppure in forma piu' geerica di un
> >    ROWID).
> >    e c'e' un motivo assolutamente stringente per imporre
> >    questo vincolo: altrimenti lo Spatial Index (che e' sempre
> >    basato sulla tavola primaria e non sulla View) impazzisce,
> >    e fornira' risultati padellati di pura fantasia con
> >    risultati folli e potenzialmete devastanti.
> >    in buona sostanza, se nella colonna ROWID della Spatial
> >    View fai in modo che ci finiscano "valori random" stai
> >    facendo tutto il possibile per massacrare la logica di
> >    funzionamento dello Spatial Index.
> >    per inciso, ti ricordo che su SQLite/SpatiaLite lo
> >    Spatial Index R*TRee non e' affatto un "indice", ma e'
> >    semplicemente un'ulteriore tavola, anzi per l'esattezza
> >    e' una VirtualTable.
> >    funziona, e funziona pure in modo molto efficiente, ma
> >    esige  lo scrupoloso rispetto di tutta una serie di vincoli
> >    basati sullo scrupoloso rispetto dei JOIN relazionale
> >    basati sul ROWID, altrimenti salta tutto per aria.
> >
> > hint: ma perche' vuoi usare proprio una Spatial View ?
> > nel tuo caso, se ho capito bene il problema, sarebbe molto
> > piu' opportuno materializzare ancora un'altra tavola, p.es.:
> >
> > CREATE TABLE dipart2 AS
> > SELECT cd_diparti, dipartimen, ST_Union(geom) AS geometry
> > FROM dipartimenti
> > GROUP BY cd_diparti;
> > SELECT RecoverGeometryColumn('dipart2', 'geometry', ......);
> > SELECT CreateSpatialIndex('dipart2', 'geometry');
> >
> > ciao Sandro
> >
> >
> _______________________________________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 801 iscritti al 19/07/2017