Spatialite - calcolo automatico lunghezze polilinee 3D

[Falz]

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";
_______________________________________________
[hidden email]
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

[a.furieri]

On Wed, 14 Nov 2018 13:10:46 +0100 (CET), [hidden email]
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

_______________________________________________
[hidden email]
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

[a.furieri]

On Wed, 14 Nov 2018 14:16:06 +0100, [hidden email] wrote:

> On Wed, 14 Nov 2018 13:10:46 +0100 (CET), [hidden email]
> 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,
_______________________________________________
[hidden email]
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

[Falz]

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/
_______________________________________________
[hidden email]
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