[Gfoss] catasto e aree fabbricabili: calcolo area differente in Postgis e Qgis

Amedeo_Fadini · October 21, 2012, 5:35pm

Ciao a tutti,
in tempi di start-up, visto che non riesco a stare dietro a lavoro e università, ho pensato anch’io di partire con un nuovo progetto e sto cercando di mettere a punto un metodo efficace per il calcolo delle aree fabbricabili… spero possa diventare presto un plugin di qgis, se qualcuno vuole dare una mano, specie i dipendenti pubblici che conoscono bene la materia è il benvenuto.

finora:

import dei cxf in postgis secondo le indicazioni del wiki [0]: FATTO
script python per importare i dati alfanumerici dell’agenzia del territorio in un db postgres: FATTO
decodifica dei tracciati record documentati qui [1] in modo: FATTO
query per collegare le particella alla rendita, anno per anno e ai proprietari: FATTO
reperire le tabelle di corrispondenza dei fogli urbano/terreno per tutta la provincia di TV: FATTO

Ora ci sarebbe da affrontare il problema del calcolo della percentuale fabbricabile di un mappale che ho scelto di fare in una apposita vista:

ST_area(particelle.the_geom) as area_mappale
ST_area(ST_intersection(particelle.the_geom, zone.the_geom) as area_edificabile

e poi:

area_edificabile/area_mappale*100 as perc_edificabile

Tra i dati alfanumerici del catasto c’è la superficie in ettari, are, centiare che io trasformo in mq
Quindi la superificie edificabile che farà testo sarà

superficie_catastale * perc_edificabile

Il problema è che le aree calcolate in POSTGIS sono differenti da quelle che Qgis calcola nel campo derivato, pensavo dipendesse dal sistema di riferimento (qgis usa 3003 con +twgs84 e postgis senza) ma anche andando a impostare la stessa stringa proj4 in qgis trovo risultati discordanti:

ad esempio:

id:1095616
area_calcolata: 2929.05078125 (postgis)
derivato>area: 2.925,565 m²

id:1005647
area_calcolata: 12342.7646484375
derivato>area: 1,233 ha

id:1556723
area_calcolata: 46504.70703125
derivato>area:4,645 ha

So bene che parliamo circa di 10 mq ogni ettaro, cioè lo 0,1% ma vorrei sapere se qualcuno mi spiega perché il calcolo è differente…
Disabilitando la priezione al volo sembra che la differenza svanisca, ma non è chiaro perché il campo in ettari ha solo tre decimali… c’è modo di mostrare sempre in metri quadri?

[0] http://wiki.gfoss.it/index.php/Catasto
[1] http://www.agenziaterritorio.it/sites/territorio/files/servizi/ServiziComuniIstituzioni/PortalePerComuni/ES-23-IS-05_100909.pdf

madi · October 21, 2012, 6:22pm

Ciao Ame,

2012/10/21 Amedeo Fadini <fame@libero.it>

Il problema è che le aree calcolate in POSTGIS sono differenti da quelle che Qgis calcola nel campo derivato, pensavo dipendesse dal sistema di riferimento (qgis usa 3003 con +twgs84 e postgis senza) ma anche andando a impostare la stessa stringa proj4 in qgis trovo risultati discordanti:

Guarda non sono un geografo e spero che ti risponda qualcuno piu esperto, pero a naso io non userei una proiezione conforme per il catasto, direi che ti serve una proiezione equivalente, cioe` che mantiene i rapporti tra le superfici.

ciao madi

–
Margherita DI LEO

Postdoctoral Researcher
European Commission - DG JRC
Forest Resources and Climate
I-21020 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-leo@jrc.ec.europa.eu

Marco_Guiducci1 · October 21, 2012, 8:16pm

Inviato da iPod

Il giorno 21/ott/2012, alle ore 19:35, Amedeo Fadini <fame@libero.it> ha scritto:

Tra i dati alfanumerici del catasto c'è la superficie in ettari, are, centiare che io trasformo in mq

La superficie è un attributo che deriva dai rilievi diretti sul terreno e non ha niente a che vedere con quella che puoi calcolare dalla geometria della mappa che, com'è noto, subisce "aggiustamenti" ad ogni aggiornamento (tipo mappale o tipo di frazionamento).
Questa è la ragione principale. Aggiungo per completezza che qualsiasi superficie calcolata sul piano di proiezione di gauss, come nel caso del 3003, va divisa due volte per il fattore di contrazione 0.9996, per avere quella del terreno.
Saluti
Marco

Amedeo_Fadini · October 21, 2012, 10:00pm

Grazie mille per le info preziose che conoscevo in parte non mancherò di approfondire, ma il problema è molto più semplice:
la stessa geometria, indipendentemente dalla proiezione, mi da un valore di area diverso in qgis rispetto a postgis, mi interessava capire il perché…

Amefad

strk · October 22, 2012, 6:43am

On Mon, Oct 22, 2012 at 12:00:53AM +0200, Amedeo Fadini wrote:

Grazie mille per le info preziose che conoscevo in parte non mancherò di
approfondire, ma il problema è molto più semplice:
la stessa geometria, indipendentemente dalla proiezione, mi da un valore di
area diverso in qgis rispetto a postgis, mi interessava capire il perché...

Stabilita' numerica, immagino.
Di recente PostGIS ha migliorato la precisione a discapito della rapidita',
traslando ogni segmento verso l'origine per avere piu' bit di precisione
sul calcolo delle aree dei triangoli costruiti su ogni segmento.
Non so che versione tu abbia (ne di postgis ne di qgis) ma so che piccole
differenze di area possono dipendere da questo tipo di differente algoritmo.

--strk;

http://www.cartodb.com - Map, analyze and build applications with your data

~~ http://strk.keybit.net

a.furieri · October 22, 2012, 7:16am

On Mon, 22 Oct 2012 08:43:48 +0200, Sandro Santilli wrote:

On Mon, Oct 22, 2012 at 12:00:53AM +0200, Amedeo Fadini wrote:

Grazie mille per le info preziose che conoscevo in parte non mancherò di
approfondire, ma il problema è molto più semplice:
la stessa geometria, indipendentemente dalla proiezione, mi da un valore di
area diverso in qgis rispetto a postgis, mi interessava capire il perché...

Stabilita' numerica, immagino.
Di recente PostGIS ha migliorato la precisione a discapito della rapidita',
traslando ogni segmento verso l'origine per avere piu' bit di precisione
sul calcolo delle aree dei triangoli costruiti su ogni segmento.
Non so che versione tu abbia (ne di postgis ne di qgis) ma so che piccole
differenze di area possono dipendere da questo tipo di differente algoritmo.

Era proprio il medesimo sospetto che nutrivo anche io.
come ho avuto occasione di toccare direttamente con mano con la
test coverage di SpatiaLite, versioni diverse delle GEOS di regola
producono risultati diversi da quelli calcolati dalle versioni
precedenti.

ma in genere si tratta di scostamenti abbastanza lievi; quelli segnalati
da Amedeo sembrerebbero piu' consistenti.
direi che a questo punto diventa indispensabile stabilire:
- su quale sistema operativo lavora Amedeo
- quali distribuzioni sw ha installato

se usa Linux, dovrebbe dipendere sempre tutto dalla medesima shared
library GEOS, e quindi direi che il problema "versioni spaiate" non
sembra molto verosimile.

viceversa se usa Windows e' molto facile che QGIS e PostGIS stiano
usando due diverse GEOS DLL, magari di due versioni diverse.
ed in questo caso la probabilita' di ottenere risultati diversi
diventa praticamente una certezza.

ciao Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

strk · October 22, 2012, 7:24am

On Mon, Oct 22, 2012 at 09:16:00AM +0200, a.furieri@lqt.it wrote:

On Mon, 22 Oct 2012 08:43:48 +0200, Sandro Santilli wrote:
>On Mon, Oct 22, 2012 at 12:00:53AM +0200, Amedeo Fadini wrote:
>>Grazie mille per le info preziose che conoscevo in parte non
>>mancherò di
>>approfondire, ma il problema è molto più semplice:
>>la stessa geometria, indipendentemente dalla proiezione, mi da
>>un valore di
>>area diverso in qgis rispetto a postgis, mi interessava capire
>>il perché...
>
>Stabilita' numerica, immagino.
>Di recente PostGIS ha migliorato la precisione a discapito della
>rapidita',
>traslando ogni segmento verso l'origine per avere piu' bit di
>precisione
>sul calcolo delle aree dei triangoli costruiti su ogni segmento.
>Non so che versione tu abbia (ne di postgis ne di qgis) ma so che
>piccole
>differenze di area possono dipendere da questo tipo di differente
>algoritmo.
>

Era proprio il medesimo sospetto che nutrivo anche io.
come ho avuto occasione di toccare direttamente con mano con la
test coverage di SpatiaLite, versioni diverse delle GEOS di regola
producono risultati diversi da quelli calcolati dalle versioni
precedenti.

ma in genere si tratta di scostamenti abbastanza lievi; quelli
segnalati
da Amedeo sembrerebbero piu' consistenti.
direi che a questo punto diventa indispensabile stabilire:
- su quale sistema operativo lavora Amedeo
- quali distribuzioni sw ha installato

se usa Linux, dovrebbe dipendere sempre tutto dalla medesima shared
library GEOS, e quindi direi che il problema "versioni spaiate" non
sembra molto verosimile.

Ma la ST_Area di PostGIS non usa GEOS.
Non so QGIS.
C'e' pure da vedere se la radice quadrata viene calcolata su ogni
segmento o solo alla fine. Scostamenti abbastanza lievi * numero
di segmenti = scostamenti abbastanza consistenti...

--strk;

http://www.cartodb.com - Map, analyze and build applications with your data

~~ http://strk.keybit.net

Amedeo_Fadini · October 22, 2012, 8:13am

2012/10/22 <a.furieri@lqt.it>

direi che a questo punto diventa indispensabile stabilire:

su quale sistema operativo lavora Amedeo

quali distribuzioni sw ha installato

Groan, sapevo che mi dimenticavo qualcosa…

Il server di test è una macchina virtuale win xp 32 bit con postgres 9.0 e
POSTGIS=“1.5.3” GEOS=“3.3.1-CAPI-1.7.1” PROJ=“Rel. 4.6.1, 21 August 2008” LIBXML=“2.7.8” USE_STATS

I due client sono windows 7 64 bit con Qgis 1.8 standalone installer (Versione GEOS 3.2.2, Versione client PostgreSQL 8.3.10)

Appena ho tempo ovviamente userò un server linux, e proverò a vedere se con la stessa versione di Geos lo scostamento scompare.
Confermo comunque che disabilitando la proiezione al volo (che mi serve per i layer WMS) gli scostamenti sono abbastanza lievi (< 5 mq per ettaro)

All’atto pratico, come è già stato fatto notare, il problema non ha grosse ricadute perché la superficie catastale ufficiale è in un campo a se e deriva dai rilievi topografici e si discosta sempre parecchio dai valori calcolati (ottimo cmq il consiglio sul fattore di scala che avevo scordato).

grazie a tutti

amefad

Geo_DrinX · October 22, 2012, 8:15am

C'e' pure da vedere se la radice quadrata viene calcolata su ogni
segmento o solo alla fine. Scostamenti abbastanza lievi * numero
di segmenti = scostamenti abbastanza consistenti...

Temo che l'unico sistema per "dipanare la matassa" sia quello di prendere un poligono di partenza e vedere cosa accade con i vari metodi.
Puoi inviarne uno in lista?

Altra domanda: i tuoi CXF sono gauss-boaga?

giuliano · October 22, 2012, 8:15am

On Sun, 21 Oct 2012 19:35:49 +0200
Amedeo Fadini <fame@libero.it> wrote:

Ciao a tutti,
in tempi di start-up, ......
....... per il calcolo delle aree
fabbricabili... spero possa diventare presto un plugin di qgis, se qualcuno
vuole dare una mano, specie i dipendenti pubblici che conoscono bene la
materia è il benvenuto.

non sono un dipendente pubblico, ma interessa anche a me :-)))

finora:

......
ST_area(particelle.the_geom) as area_mappale
ST_area(ST_intersection(particelle.the_geom, zone.the_geom) as
area_edificabile
......
area_edificabile/area_mappale*100 as perc_edificabile
......
superficie_catastale * perc_edificabile

1) scusa, non capisco questi ultimi passaggi: hai già l'area
edificabile: che senso ha calcolare la percentuale sull'area catastale
per poi ricalcolare la prima? o forse vuoi stimare la percentuale su
dati non ufficiali, ma conguenti, e poi applicarla a un dato non
congruente con i primi, ma ufficile (la superficie catastale fornita
dall'ente)? mi sfugge qulcosa?

2) tieni conto, come ti ha (parzialmente) detto Marco, che esistono due
"superfici" quella nominale (presumo quella nel DB storico dell'ente)
e quella "reale" rilevata sul terreno nel corso di frazionamenti,
inserimenti in mappa, ecc.; le due sono significativamente diverse; te
lo segnalo per evitarti di inseguire una "perfezione" che non esiste

3) ti basta la sup.calcolo area differente in Postgis e Qgisedificabile o ti interessa la volumetria? in tale
eventualità hai bisogno dei dati della pianificazione locale;

4) scusa se non so intervenire sul topic della tua mail (calcolo area
differente in Postgis e Qgis);

ciao,
giuliano

Amedeo_Fadini · October 22, 2012, 8:35am

2012/10/22 giuliano su Tiscali <giulianc@tiscali.it>

non sono un dipendente pubblico, ma interessa anche a me :-)))

Ottimo, ti scrivo in privato senza allungare il thread e appena ho qualcosa di più strutturato e dei dati di esempio creo una pagina su qualche blog…

af

Amedeo_Fadini · October 22, 2012, 9:22am

2012/10/22 Geodrinx <geodrinx@gmail.com>

Puoi inviarne uno in lista?

Allego i tre poligoni di cui sopra SR 3003, ovviamente li ho traslati perché non posso mandare in giro dati reali

Altra domanda: i tuoi CXF sono gauss-boaga?

No, qui in provincia di treviso i CXF hanno coordinate catastali cassini soldner (con molte incongruenze da foglio a foglio), sono stati riproiettati in base alle coordinate dell’origine catastale e poi aggiustati con una trasformazione affine per ottenere una sovrapposizione accettabile con il PRG.

amefad

catasto.zip (2.07 KB)

giohappy · October 22, 2012, 9:23am

Se non ci sono questioni di privatezza, ti sarei grate se mantenessi il thread pubblico. Non riesco a partecipare in questo momento, ma la questione interessa anche me…

giovanni

Il giorno 22 ottobre 2012 10:35, Amedeo Fadini <fame@libero.it> ha scritto:

2012/10/22 giuliano su Tiscali <giulianc@tiscali.it>

non sono un dipendente pubblico, ma interessa anche a me :-)))

Ottimo, ti scrivo in privato senza allungare il thread e appena ho qualcosa di più strutturato e dei dati di esempio creo una pagina su qualche blog…

af

Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
605 iscritti al 10.7.2012

Amedeo_Fadini · October 22, 2012, 9:43am

2012/10/22 G. Allegri <giohappy@gmail.com>

Se non ci sono questioni di privatezza, ti sarei grate se mantenessi il thread pubblico. Non riesco a partecipare in questo momento, ma la questione interessa anche me…

Le questioni a questo punto sono due, entrambe verranno affrontate con la massima pubblicità:

uno è fare luce sul calcolo delle aree differenti per lo stesso poligono, che ormai è abbastanza sviscerata nel presente thread, ma benevngano contributi aggiuntivi
la seconda è l’attività di mettere a punto uno strumento e una metodologia per l’individuazione delle aree fabbricabili e la gestione dei dati alfanumerici del catasto, è un progetto che vorrei condividere con la comunità e mi auguro nel volgere di un paio di settimane di poter pubblicare gli script e e le query fatti finora,
poiché ho lavorato su dati reali non condivisibili, devo prima mettere a punto dei dati fittizi (a partire dai file CXF, FAB, TER, TIT, SUP) che ci consentano di lavorare insieme… stay tuned!

Qualche idea su dove pubblicare gli script?

amefad

giohappy · October 22, 2012, 12:54pm

Qualche idea su dove pubblicare gli script?

Forse nel wiki GFOSS.it?

giovanni

amefad

lucadelu · October 22, 2012, 12:55pm

Il 22 ottobre 2012 14:54, G. Allegri <giohappy@gmail.com> ha scritto:

Qualche idea su dove pubblicare gli script?

Forse nel wiki GFOSS.it?

+1,
oppure ti apri un profilo su github, gitorius, sourceforge ecc ecc

giovanni

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Iacopo_Zetti · October 22, 2012, 2:24pm

1) scusa, non capisco questi ultimi passaggi: hai già l'area
edificabile: che senso ha calcolare la percentuale sull'area catastale
per poi ricalcolare la prima? o forse vuoi stimare la percentuale su
dati non ufficiali, ma conguenti, e poi applicarla a un dato non
congruente con i primi, ma ufficile (la superficie catastale fornita
dall'ente)? mi sfugge qulcosa?

Io invece sono un dipendente pubblico e anche se adesso mi occupo di
altro ho partecipato a un grosso lavoro che si occupava proprio di
percentuali edificabili di particelle del catasto terreni.
Il software utilizzato all'epoca era un gis commerciale con dati in
(oggi inorridirei) access, ma per il calcolo delle aree alla fine del
lavoro avevo iniziato ad utilizzare postgis.
Ho aperto i vecchi dati oggi e fatto un controllo a caso su qualche area
(ma non si tratta di catasto bensì di aree di piano regolatore), stesso
problema con 'abilita la proiezione al volo' attivo, anche se i dati
sono sempre in gauss boaga e misure corrette disabilitando.

Per quanto riguarda la procedura invece avevamo utilizzato esattamente
gli stessi passaggi, anche se con software diverso e il motivo, anche se
a senso sembra assurdo, è semplice, almeno nel mio caso: le tasse si
pagano sulla superficie edificabile che è la percentuale della
particella che ricade in una precisa area di piano regolatore. Se si
tratta del 100% ok, altrimenti si deve far così, percentuale misurata
sulla mappa come moltiplicatore della superficie censita al catasto.
Come metodo scientifico magari fa schifo, ma fiscalmente regge anche
davanti alle commissioni tributarie.

Saluti

Iacopo

Amedeo_Fadini · October 22, 2012, 3:51pm

2012/10/22 Iacopo Zetti <gis@controgeografie.net>

[…].
Come metodo scientifico magari fa schifo, ma fiscalmente regge anche
davanti alle commissioni tributarie.

Ottima notizia, non credo che scientificamente faccia proprio schifo, in quanto la mappa catastale nasce con una funzione più “analogica” ovvero serve per identificare una parcella tramite le parcelle confinanti piuttosto che riprodurre effettivamente dimensioni e quantità (Ok, geometri e topografi non inveite, conosco l’affidabilità dei vostri rilievi, il punto è come poi negli anni sono stati trascritti…)

Sw commerciali ce ne sono parecchi e alcuni funzionano anche molto bene, mi auguro che nessuno si offenda se cerchiamo di costruire una alternativa open source.

af

a.furieri · October 22, 2012, 3:59pm

On Mon, 22 Oct 2012 11:22:54 +0200, Amedeo Fadini wrote:

Allego i tre poligoni di cui sopra SR 3003, ovviamente li ho traslati
perché non posso mandare in giro dati reali

giusto per quel che puo' servire; queste sotto sono le misure
calcolate da spatialite:

id=31501
area=46504.707899
perimetro=1477.314591

id=7510
area=2929.048302
perimetro=332.636648

id=6551
area=12342.766240
perimetro=500.712112

n.b.: ho verificato con diverse versioni, che vanno dalla GEOS
3.1.1 fino alla recentissima 3.4.0-devel non ancora rilasciata.
e sono rimasto piacevolmente sopreso nello scoprire che in
questo caso specifico si ottengono esattamente sempre i soliti
valori a prescindere dalla versione GEOS utilizzata

my 2 cents
Sandro

--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.

PJ_Hooker · October 22, 2012, 5:17pm

Ho proprio davanti un'applicazione (non so come chiamarla) con cui vorrei
gestire destinazioni d'uso del PGT (il nuovo PRG) e i dati sia geometrici
che alfanumerici delle particelle catastali ...

Sto facendo tutto in php ed interrogo un database postgis ... non sono
entrato nei particolari di aggiustamenti di calcoli ... ma l'idea di
gestione è veramente buona e anche rivoluzionaria ...

cmq seguo la discussione perchè interessato ... anzi imbrigliato!

-----

il boom dei dati geografici è in corso, aspettiamoci quello delle informazioni spaziali #Local Intelligent Marketing#

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/catasto-e-aree-fabbricabili-calcolo-area-differente-in-Postgis-e-Qgis-tp7579812p7579844.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.