[Gfoss] domande su dati catastali

[Bud P. Bruegger]

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.delaunay.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