[Gfoss] domande su dati catastali

Guglielmo R. Raimondi g.raimondi a glasic.it
Gio 6 Dic 2007 17:30:30 CET



Ciao Bud.
La scelta del formato CXF e' dettata principalmente da due
motivi:

1)- il file in questo formato possiede tutto il contenuto
informativo gestito dall'Agenzia del Territorio, sia per la
ricostruzione topologica degli oggetti (poligoni delle
particelle "bucate" dalle eventuali isole, con associato il
numero di particella e layer di appartenenza (confine,
particella, fabbricato, acqua, strada, quadro di unione e
altro). Mi risulta difficile pensare alla procedura per
ricostruire poligoni "bucati" a partire da un file DXF.

2)- Il formato CXF e' quello scaricabile dal "Portale per i
Comuni", gestito dall'Agenzia del Territorio (AdT),
utilizzabile dalle Pubbliche Amministrazioni (PA) che
sottoscrivono una specifica convenzione con l'AdT. Il
servizio e' finalizzato espressamente all'integrazione del
dato catastale all'interno dei sistemi informativi
territoriali delle PA. Al momento sono considerate PA i
Comuni, le Province, Le Regioni e le Comunita' Montane. I
Consorzi di Bonifica (per i quali mi sto adoperando) non
sono propriamente PA, ma dovrebbe essere riconosciuto loro
il diritto di accedere comunque al servizio (e' una delle
attivita' che sto svolgendo per il Ministero delle Politiche
Agricole - MiPAAF).

Con Paolo Cavallini avevamo gia' discusso della possibilita'
di far migrare Dxf2PostGIS verso un'applicazione
multipiattaforma (in Python appunto), ma come potrai
immaginare il tempo da dedicare a queste cose lo trovi solo
quando devi raggiungere un risultato e la via piu' breve per
raggiungerlo e' normalmente quella che viene seguita.
Quindi ho preferito modificare Dxf2PostGIS in VisualBasic
piuttosto che riprogettare una nuova applicazione in Python.
I risultati sono stati rapidi e incoraggianti (metteremo per
Natale, sull'area di download del nostro sito, la versione
Beta per gli amici che vorranno valutarla ed aiutarci a
migliorarla).

Poiche' la trasformazione del formato da CXF a PostGIS e'
un'attivita' da pianificare con frequenza non troppo alta,
potremmo anche sopportare (per il momento) di eseguirla su
una macchina windows, visto che il prodotto finale puo'
essere caricato da un server di database open source su
Linux (PostgreSQL + PostGIS).

Suggerisco di concentrare gli sforzi comuni sulla
possibilita' di:
1)- dichiarare il sistema di riferimento catastale come uno
dei tanti SRID della tabella "spatial_ref_sys" per
consentire la riproiezione al volo nei sistemi di
riferimento abitualmente utilizzati nei SIT (Roma40 est e
ovest, WGS84 Lat/Lon, WGS84 UTM 32 e 33, ED50 UTM 32 e 33).
I sistemi di riferimento catastali adottati in Italia sono
centinaia (magari sempre Cassini-Soldner, ma con diversi
punti di emanazione). C'e' la possibilita' di razionalizzare
questa raccolta di parametri?

2)- Poiche' questo primo passo potrebbe non garantire
un'accuratezza posizionale accettabile (per motivi che non
sto a raccontare), procedere ad una trasformazione di
Helmert a sei parametri (che e' ancora una funzione
disponibile in PostGIS), preventiva o in alternativa alla
triangolazione che suggerisci nella tua ultima mail, basata
sulla conoscenza di un congruo numero di punti di controllo.

Se si riuscisse a redarre una procedura per queste ultime
due attivita', potremmo essere tentati di integrarla nel
software applicativo di trasformazione (Dxf2PostGIS) oppure
di scrivere un plug-in per QGis (in Python) o per altri
software open source.

Avrei altre considerazioni, ma mi sono gia' dilungato
abbastanza.

Guglielmo

Guglielmo Raimondi
g.raimondi at glasic.it

----- Original Message -----
Da : "Bud P. Bruegger" <bud at comune.grosseto.it>
A : "Guglielmo R. Raimondi" <g.raimondi at glasic.it>
Cc: gfoss at faunalia.com
Oggetto : Re: [Gfoss] domande su dati catastali
Data : Thu, 6 Dec 2007 16:16:41 +0100

> Ciao Guglielmo,
> 
> certamente vorrei collaborare e penso che come comunita'
> riusciamo di fare belle cose.  
> 
> Anche, oltre il catasto avro' anche la necessita' di
> integrare dati in DWG/DXF da diversi nostri uffici--e mi
> sembra che voi gia' fate queste cose..  
> 
> Ho nel passato discusso un po con Frank Warmerdam su come
> si potrebbe fare e come potrebbe interfacciarsi con
> OGR--ma poi non ho fatto ancora niente e sembra che in
> AutoCAD ci siano tanti modi di attaccare attributi che non
> ci sia un modo per convertire ma piuttosto si ha bisogno
> di scripts ad-hoc.  (Frank mi ha puntato sul manuale di
> FME che e' lo stato dell'arte per conversione da DWG/DXF a
> formati GIS).  
> 
> Ho guardato velociemente dxf2postgis e mi sembra che sia
> scritto solo per piattaforma Windows?  Io avrei bisogno di
> una cosa che gira anche su Linux, al meno la parte senza
> GUI.  Vedi questo come ostacolo alla collaborazione oppure
> pensi si puo trovare un modo?  Forse e' utile di notare
> che ultimamente ho fatto quasi tutte le mie cose in
> Python...
> 
> Nel seguito penso un po a voce alta (the ultimate way of
> releasing early ;-).
> 
> Magari miscolo un po concetti (definizione del problema)
> con idee di come si potrebbe implementarlo...  
> 
> Un punto da decidere e' da quale formato iniziare (dai CXF
> , DXF, CML che sono disponibile dal catasto). Mi poi dire
> cosa ti ha motivato a usare CXF invece di DXF; non sono
> strutturalmente equivalente?  Se si, perche' non usare il
> parser di DXF gia' esistente.  
> 
> Poi per tutto l'integrazione di dati catastali vedo i
> seguenti passi:
> 
> (1) parser del formato originale (CXF, DXF, CML).  
> Potrebbe valere la pena di riusare un parser esistente. 
> Per DXF e DWG c'e' un buon parser in pythoncad
> (http://www.pythoncad.org/),  CML e' xml e si trovano
> tanti parsers esistenti...
> 
> (2) poi gli elementi devono essere rappresentati in un
> formato (sempre a livello di spaghetti) per poter
> facilmente lavorare.  PostGIS e' una possibilita' (forse
> anche una interessante), ma anche interfaccarsi con OGR
> per poi flessibilmente sceglere il formato di output
> potrebbe essere interessante.  Nel secondo caso penso che
> Frank potrebbe dare una mano se e' necessario.  
> 
> (3) la prima cosa da fare poi e' andare da spaghetti a
> veri poligoni. Io personalmente sono maggiormente
> interessato ai dati, non a una rappresentazione visiva che
> riproduce il foglio catastale.  Forse qui abbiamo diversi
> requisiti?
> 
> In modo naivo, farei il seguente algoritmo:
> 
> (i) eliminazione delle "linee di anchoraggio": Per questo
> si deve trovare il testo vicino al punto di inizio (con un
> buffer?) per poi spostarlo al punto di fine della linea. 
> Mi chiedo se l'orientamento delle linee di anchoraggio e'
> sempre consistente nei files.
> 
> (ii) a questo punto un "point in polygon" dovrebbe
> associare l'attributo al poligono.  
> 
> Le domande che ho sono:
> - se un poligono segue i bordi del foglio, sono ripetuti
> tutti i vertici lungo il bordo?
> - c'e' solo il numero di particella nei testi, oppure ci
> sono altri tipi di testi in un poligono che potrebbero non
> funzionare col algoritmo sopra?
> 
> (4) dove necessario, applicare una trasformazione globale
> per andare dal sistema di riferimento iniziale (spesso
> Cassini Soldner) a quello desiderato (GaussBoaga o
> UTM32/WGS84).   Se si avesse tutti i parametri necessari
> (penso la nostra Regione gli abbia..), allora Proj4
> (magari chiamato da OGR) potrebbe farlo.  
> 
> C'e' qualcuno che ha fatto questa trasformazione con Proj4
> e ha i parametri e sa dire quanto combacia alla fine?
> 
> (5) Opzionalmente, si puo poi correggere le coordinate
> catastali ulteriomente basato su un "correspondence file"
> che provviene da una digitalizzazione manuale e contiene
> coppie di coordinate dopo la trasformazione globale e
> coordinate finale.  Questi ultimi potrebbero ad sempio nel
> nostro caso provvenire dalla CTR dove si possono
> identificare punti anche presenti nel catasto (angoli di
> edifici etc.).  
> 
> L'algorithmo che avevo implementato io iniziava con una
> triangulazione dei correspondence points.  Grass ha una
> funziona v.delaunay
> (http://grass.itc.it/grass62/manuals/html62_user/v.delauna
> y.html) che potrebbe essere usato per questo.  Avendo
> questo, per ogni punto nei dati catastali, si deve fare il
> seguente: * cercare il triangolo in quale sta
> * trasformandolo usando un'algorithmo semplice e velocie
> basato su "linear coordinates".  Penso l'articolo che ho
> usato e' 
> 
> Piecewise Linear Rubber-Sheet Map Transformation, Marvin
> S. White, Jr. and Patricia Griffin, The American
> Cartographer, vol. 12, No. 2, 1985, pp. 123-131.  
> 
> oppure 
> 
> Saalfeld, A. 1985. A fast-rubber sheeting transformation
> using simplicial coordinates. The American Cartographer
> 12(2): 169-173.
> 
> Che sembra Marvin o Alan o il Bureau of the Census abbiano
> poi patentati
> (http://www.patentstorm.us/patents/5546107.html).  
> 
> Hmmm. che e' implementato in JUMP!  (vedi
> www.vividsolutions.com/JUMP/bin/JUMP%20Technical%20Report.
> pdf su pagina 16 sezione 9.2. 
> 
> Esiste anche in
> 
> JTS:
>
http://www.vividsolutions.com/JUMP/javadoc/com/vividsolutions/jump/warp/BilinearInterpolatedTransform.html
> 
> Ma non sono certo se anche in GEOS e se magari e' oppure
> usabile da PostGIS???
> 
> Ma sembra che tutta la funzionalita' di base gia' esiste!
> 
> Fatemi sapere che ne pensate delle idee sopra..
> 
> saluti
> -b

^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ing. Guglielmo R. Raimondi
Glasic S.r.l.
www.glasic.it
g.raimondi at glasic.it
cell.: 347 6720673
tel.: 06 83502893
^^^^^^^^^^^^^^^^^^^^^^^^^^^



Maggiori informazioni sulla lista Gfoss