Re: [Gfoss] Spatialite - calcolo automatico lunghezze polilinee 3D
Ho rifatto come suggerito da Mr. Furieri. Grazie! Risolto :)
L'unico problema ora è solo Qgis 3.4.1, ha le librerie di spatialite ferme a
4.3.0, non accetta la funzione st_3dlength(). In effetti mi crea problemi.
Interrogando la vista con spatialite_gui funziona bene! :)
--sviluppo db per 3D_geo
create table linee3d
(pk integer primary key autoincrement,
name text,
note text);
select addgeometrycolumn('linee3d','geom',4326,'LINESTRING','XYZ');
create view v_linee3d as
select
pk as rowid,
geom,
name,
note,
st_length(st_transform(geom,32632)) as l2d_wgs84utmz32n,
st_3dlength(st_transform(geom,32632)) as l3d_wgs84utmz32n
from linee3d;
insert into views_geometry_columns
(view_name, view_geometry, view_rowid, f_table_name, f_geometry_column,
read_only)
values ('v_linee3d', 'the_geom', 'rowid', 'linee3d', 'geom',1);
--
Sent from:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/
___
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
Re: [Gfoss] Spatialite - calcolo automatico lunghezze polilinee 3D
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
Re: [Gfoss] Spatialite - calcolo automatico lunghezze polilinee 3D
On Wed, 14 Nov 2018 13:10:46 +0100 (CET), falcerisim...@inwind.it wrote: Ciao a tutti, a chi interessa, condivido uno script sql per creare una tabella 3dpolylines in spatialite NEXTGEN con calcolo automatico. Purtroppo Qgis 3.4.1 non è in grado gestire le polilinee 3d spatialite (Errore di SQLite: causa sconosciuta). Solo importando shp-3d da spatialite funziona. Idem per editing della geom. su questo non so proprio cosa dirti, prova a sentire la community di QGIS. pare comunque decisamente strano, visto che il formato binario delle geometrie di spatialite (comprese quelle 3D) non ha subito nessun cambiamento (neppure microscopico), durante gli ultimi otto anni, e per quanto mi risulta con le precedenti versioni di QGIS funzionava tutto correttamente. 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 ciao Sandro ___ 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
[Gfoss] Spatialite - calcolo automatico lunghezze polilinee 3D
Ciao a tutti,
a chi interessa, condivido uno script sql per creare una tabella 3dpolylines in
spatialite NEXTGEN con calcolo automatico. Purtroppo Qgis 3.4.1 non è in grado
gestire le polilinee 3d spatialite (Errore di SQLite: causa sconosciuta). Solo
importando shp-3d da spatialite funziona. Idem per editing della geom. La
tabella fa il calcolo grazie ai triggers e confronta con epsg 4326 e 32632. Son
graditi pareri o suggerimenti...saluti!
--sviluppo db per 3D_geo
create table linee3d
(pk integer primary key autoincrement,
name text,
lung_2d_wgs84 double,
lung_3d_wgs84 double,
lung_2d_wgs84utmz32n double,
lung_3d_wgs84utmz32n double,
note text);
select addgeometrycolumn('linee3d','geom',4326,'LINESTRING','XYZ');
create trigger insert_autocalc_lenghts after insert on linee3d
begin update linee3d set
lung_2d_wgs84= st_length(geom),
lung_3d_wgs84= st_3dlength(geom),
lung_2d_wgs84utmz32n= st_length(st_transform(geom,32632)),
lung_3d_wgs84utmz32n= st_3dlength(st_transform(geom,32632))
where rowid=new.rowid; end;
create trigger update_autocalc_lenghts after update of geom on linee3d
begin update linee3d set
lung_2d_wgs84= st_length(geom),
lung_3d_wgs84= st_3dlength(geom),
lung_2d_wgs84utmz32n= st_length(st_transform(geom,32632)),
lung_3d_wgs84utmz32n= st_3dlength(st_transform(geom,32632))
where rowid=new.rowid; end;
--inserimento massivo di shp in db.
--aggiungere o cancellare i paragafi a seconda del numero di SHP-3D da inserire
in db. Si da per scontato che gli SHP abbiano un campo testo "name" e EPSG:
4326.
create virtual table "1"
using virtualshape('C:\temp\SHP\1','UTF-8',4326);
insert into linee3d ("name", geom)
select "name", geometry from "1";
delete from virts_geometry_columns where virt_name='1';
drop table "1";
create virtual table "2"
using virtualshape('C:\temp\SHP\2','UTF-8',4326);
insert into linee3d ("name", geom)
select "name", geometry from "2";
delete from virts_geometry_columns where virt_name='2';
drop table "2";
___
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
