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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss 281 iscritti al 26.11.2007 Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it.
