[Gfoss] ST_Union e PostGIS

[Massimiliano Moraca]

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