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@glasic.it
----- Original Message -----
Da : "Bud P. Bruegger" <bud@comune.grosseto.it>
A : "Guglielmo R. Raimondi" <g.raimondi@glasic.it>
Cc: gfoss@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:
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@glasic.it
cell.: 347 6720673
tel.: 06 83502893
^^^^^^^^^^^^^^^^^^^^^^^^^^^