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*: www.massimilianomoraca.it * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1* _______________________________________________ [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. 764 iscritti al 23/08/2019
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
|
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 <[hidden email]> 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*: www.massimilianomoraca.it > * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1* > _______________________________________________ > [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. > 764 iscritti al 23/08/2019 [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. 764 iscritti al 23/08/2019 |
In reply to this post by Massimiliano Moraca
Visto che era un test con un solo layer l'ho caricato direttamente in QGIS
e lui ha settato il SR del progetto in 3857. Comunque ho appena creato un progetto di test presettando il SR in 3857 ed anche in questo caso il calcolo dell'area è diverso dal risultato di PostGIS. La versione di QGIS in uso è la 3.4 mentre PostgreSQL/PostGIS è in versione 12.1/3.0 *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*: www.massimilianomoraca.it * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1* Il giorno ven 27 dic 2019 alle ore 15:56 Umberto Minora < [hidden email]> 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 <[hidden email]> 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*: www.massimilianomoraca.it > > * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1* > > _______________________________________________ > > [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. > > 764 iscritti al 23/08/2019 [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. 764 iscritti al 23/08/2019
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
|
In reply to this post by Massimiliano Moraca
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:[hidden email] 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:[hidden email]> 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:[hidden email]> 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:[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. > 764 iscritti al 23/08/2019 mailto:[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. 764 iscritti al 23/08/2019 _______________________________________________ [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. 764 iscritti al 23/08/2019 |
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*: 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 < [hidden email]> 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 GenovaP.IVA/CF 01998770992 > ph: 010-0899150 - mob: 349-8786575 > E-mail: [hidden email] > > -- > Gter socialwww.twitter.com/Gteronline - www.facebook.com/Gteronlinewww.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 > <[hidden email] <[hidden email]>>* 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 <[hidden email]> 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*: www.massimilianomoraca.it > > * Attività svolta ai sensi della Legge 4 del 14 gennaio 2013, art.1* > > _______________________________________________ > > [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. > > 764 iscritti al 23/08/2019 > _______________________________________________ > [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. > 764 iscritti al 23/08/2019 > > > > [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. 764 iscritti al 23/08/2019
Consulente GIS, Formatore, Blogger e Ciclista Urbano
email: info@massimilianomoraca.it
cell: 333 5949583 (lun-ven, 9.00-18.00)
website: massimilianomoraca.it
|
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:[hidden email] 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 <[hidden email]> 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:[hidden email]> 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:[hidden email] 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:[hidden email]> 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:[hidden email]> 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:[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. > 764 iscritti al 23/08/2019 mailto:[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. 764 iscritti al 23/08/2019 _______________________________________________ [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. 764 iscritti al 23/08/2019 |
Free forum by Nabble | Edit this page |