On Wed, 14 Nov 2018 14:16:06 +0100, a.furi...@lqt.it wrote:
On Wed, 14 Nov 2018 13:10:46 +0100 (CET), falcerisim...@inwind.it
wrote:
La tabella fa il calcolo grazie ai triggers e confronta con epsg
4326 e 32632.
Son graditi pareri o suggerimenti...
perche' mai usi una roba fragile, delicata, lenta, poco efficiente
e poco affidabile come una VirtualShape per importare i dati dallo
Shapefile ?
guarda che da diversi anni ormai esiste un'apposita funzione SQL
per caricare al volo uno Shapefile creando una Spatial Table:
ImportSHP()
http://www.gaia-gis.it/gaia-sins/spatialite-sql-5.0.0.html
seconda valutazione dopo valutazione piu' ponderata.
ma ne vale proprio la pena di mettere in piedi tutto questo
ambaradan di triggers giusto per calcolare le lunghezze 2D/3D ?
in linea di massima i buoni principi alla base dei DBMS relazionali
(le famose regole auree del Dr. Codd) memorizzare in modo statico
e permanente un valore che per sua natura sarebbe facilmente
derivabile in modo dinamico da altri dati non e' mai consigliato.
per almeno due ottime ragioni:
- occorre piu' spazio per memorizzare il dataset; si impone un
forte rallentamento a carico di tutte le INSERT/UPDATE
- a causa di malfunzionamenti o altri difetti piu' o meno
fantasiosi, potresti trovarti alla fine con una situazione
che non e' logicamente consistente.
del tipo che sulla colonna ti risulta una lunghezza X,
mentre invece se calcoli la ST_Length() ti risulta Y.
la regola aurea superiore a tutte e' sempre il principio
KISS (keep it simple, stupid).
hai preso in considerazione l'ipotesi di risolvere il tuo
problema in modo molto piu' canonico, e cioe' tramite la
definizione di una banalissima View ?
create table linee3d
(pk integer primary key autoincrement,
name text,
note text);
select addgeometrycolumn('linee3d','geom',4326,'LINESTRING','XYZ');
ceate view v_linee3d as
select pk as rowid, name as name, note as note, geom as geom,
st_length(geom) as lung_2d_wgs84,
st_3dlength(geom) as lung_3d_wgs84,
st_length(st_transform(geom,32632)) as lung_2d_wgs84utmz32n,
st_3dlength(st_transform(geom,32632)) as lung_3d_wgs84utmz32n;
questa soluzione non incrementa lo spazio di storage, assicura
sempre il perfetto allineamento dei dati, garantisce INSERT/UPDATE
al top della velocita' mentre rallenta sicuramente in lettura,
ma probabilmente non in modo intollerabile.
se non hai problemi molto seri di assoluta criticita' dei tempi
di risposta in lettura questa soluzione e' certamente preferibile,
se non altro perche' rispetta tutte le regole base per la
progettazione normalizzata delle banche dati senza avventurarsi
in funambolismi acrobatici potenzialmente rischiosi.
ciao Sandro
lung_2d_wgs84 double,
lung_3d_wgs84 double,
lung_2d_wgs84utmz32n double,
lung_3d_wgs84utmz32n double,
_______________________________________________
Gfoss@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.
796 iscritti al 28/12/2017
