[Gfoss] Confronto calcolo di aree tra QGIS e POSTGIS con TRIGGER

Ven 27 Dic 2019 17:08:07 CET

Ellissoide e proiezione usata nell'ambito del webGIS si adatta a tutto il mondo, ma per far ciò credo faccia cose brutte ;-)

R

Eng. Roberto Marzocchi, PhD
GIS Project Coordinator
Gter srl (Unige spin-off)
Via Ruffini 9R - 16128 Genova
http://P.IVA/CF 01998770992
ph: 010-0899150 - mob: 349-8786575
E-mail: mailto:roberto.marzocchi a gter.it
http://www.gter.it

--
Gter social
http://www.twitter.com/Gteronline - http://www.facebook.com/Gteronline
http://www.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis

-----------------------------------------------------------------
Please consider the environment before printing this email! 

---- Attivato ven, 27 dic 2019 16:51:50 +0100 Massimiliano Moraca <info a massimilianomoraca.it> ha scritto ----

Si, in effetti impostando 32633 al posto di 3857 il risultato cambia di molto anche se non è comunque identico. Mi trovo un 0.692005 da PostGIS e 0.692478 da QGIS.

So che 3857 non andrebbe usato per il calcolo delle aree(in generale non andrebbe usato) ma essendo un test con in un DB di test era il primo EPSG che mi è venuto in mente e l'ho usato. Certo non mi aspettavo errori così madornali! Fortuna che era un test!

ing.Massimiliano Moraca

Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS
P.IVA: 08700081212 
CELL: 333 59 49 583 (lun - ven 9.00 - 18.00) 
WEB: http://www.massimilianomoraca.it Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1

Il giorno ven 27 dic 2019 alle ore 16:32 Roberto Marzocchi <mailto:roberto.marzocchi a gter.it> ha scritto:

Per prima cosa ti sconsiglio di fare calcoli su aree usando il 3857 che ha delle deformazioni che fanno spavento.. In passato ho fatto delle prove su una griglia 80mx80m e un lato mi risultava di 110m  

Dalle proprietà del progetto di QGIS puoi vedere quale ellissoide usa per fare il calcolo delle aree e tendenzialmente QGIS è in gradi di fare il calcolo di lunghezze e aree sull'ellissoide (volendo puoi dirgli anche di fare misure planimetriche ma usando 3857 come dicevo sopra lo ritengo pericoloso.

PostGIS da quello che si legge sul manuale [1] fa calcoli solo planimetrici usando il SRID che trova. 

Per verificare tutto ciò prova a settare anche QGIS in quel modo (misure planimetriche) e il dato dovrebbe essere simile (ma attento perchè le misure dovrebbero risultare simili, ma sono entrambe fortemente sbagliate!!)

In sintesi differenze ci saranno sempre con i 2 metodi ma almeno cambiando CRS dei dati dovresti ridurre gli errori. 

R

[1] https://postgis.net/docs/ST_Area.html

Eng. Roberto Marzocchi, PhD
GIS Project Coordinator
Gter srl (Unige spin-off)
Via Ruffini 9R - 16128 Genova
http://P.IVA/CF 01998770992
ph: 010-0899150 - mob: 349-8786575
E-mail: mailto:roberto.marzocchi a gter.it
http://www.gter.it

--
Gter social
http://www.twitter.com/Gteronline - http://www.facebook.com/Gteronline
http://www.linkedin.com/company/gter-srl-innovazione-in-geomatica-gnss-e-gis

-----------------------------------------------------------------
Please consider the environment before printing this email! 

---- Attivato Fri, 27 Dec 2019 15:56:23 +0100 Umberto Minora <mailto:umbertofilippo a tiscali.it> ha scritto ----

solo un'ipotesi, ma in QGIS il progetto è impostato sul sistema di riferimento del dato ovvero 3857?

Il 27/dic/2019 15:48 Massimiliano Moraca <mailto:info a massimilianomoraca.it> ha scritto:
>
> Salve a tutti e buon Natale passato.
> Sto sperimentando i TRIGGER usando PostGIS ed ho creato un semplice vettore
> poligonale in cui è presente una colonna area che deve riempirsi
> automaticamente dopo la creazione del poligono. L'area deve essere in
> ettari.
>
> Ho quindi creato il mio vettore:
>
> > CREATE TABLE buffer
> > (
> > id INTEGER PRIMARY KEY,
> > area_ha DECIMAL
> > );
> > SELECT AddGeometryColumn(
> > 'buffer',
> > 'geom',
> > 3857,
> > 'POLYGON',
> > 2
> > );
>
> Ed i TRIGGER associati:
>
> > CREATE FUNCTION areabuffer_trigger_function() RETURNS trigger AS $$
> > BEGIN
> >  NEW.area_ha = ST_AREA(NEW.geom)/10000;
> >  RETURN NEW;
> > END;
> > $$ language plpgsql;
> >
> > CREATE TRIGGER areabuffer_trigger
> >  BEFORE INSERT OR UPDATE
> >  ON buffer
> >  FOR EACH ROW
> >  EXECUTE PROCEDURE areabuffer_trigger_function();
>
> Creando il poligono o i poligoni in QGIS e salvando l'editing, il campo
> *area_ha* viene effettivamente riempito con un valore. Come test ho creato
> un field virtuale nel calcolatore di campi usando la funzione `*$area/10000*`
> ma noto che i valori di area calcolati in QGIS sono diversi da quelli che
> calcola PostGIS usando il TRIGGER.
> Ad esempo il poligono 1 ha un valore di area da TRIGGER pari a 36,6917
> mentre il corrispettivo da QGIS è 20,9879.
>
> Come mai?
>
> *ing.Massimiliano Moraca*
> *Analisi, progettazione e sviluppo di soluzioni GIS e WebGIS*
> *P.IVA*: 08700081212
> *CELL*: 333 59 49 583 (*lun - ven 9.00 - 18.00*)
> *WEB*: http://www.massimilianomoraca.it
> * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1*
> _______________________________________________
> mailto: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.
> 764 iscritti al 23/08/2019
_______________________________________________
mailto: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.
764 iscritti al 23/08/2019