[Gfoss] ST_Union e PostGIS

Mer 13 Dic 2017 16:41:19 CET

Ciao Andrea,
il fatto è proprio questo, vorrei appunto evitare di trovarmi a cose fatte
con un problema da gestire. Credo che ora che tutto è in fase di startup
ancora protrei ovviare a problemi che prevedo ci saranno; per quelli che
non prevedo amen! :D

Il giorno 13 dicembre 2017 16:35, Andrea Peri <aperi2007 a gmail.com> ha
scritto:

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